f



[tao-users] [Event handling] : [deadlock problem with TAO/event handling]

    TAO VERSION: 1.3.1
    ACE VERSION: 5.3.1

    HOST MACHINE and OPERATING SYSTEM: Windows 2000
        If on Windows based OS's, which version of WINSOCK do you
        use?:

    TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
    COMPILER NAME AND VERSION (AND PATCHLEVEL): 
	Visual Studio .NET 2003 (7.1.3088)

    AREA/CLASS/EXAMPLE AFFECTED: Event handling

    DOES THE PROBLEM AFFECT:
        COMPILATION? NO
            If so, what do your $ACE_ROOT/ace/config.h and
            $ACE_ROOT/include/makeinclude/platform_macros.GNU contain?
        LINKING? NO
            On Unix systems, did you run make realclean first?
        EXECUTION? YES
        OTHER (please specify)?


    SYNOPSIS:

    Suspected deadlock when using TAO (using a TP reactor) 
    in conjunction with a WFMO reactor for other event processing.

    DESCRIPTION:

I am facing a suspected deadlock situation and trying to investigate.
I need to do more work to nail down the problem, but I need some help
to know whether I am doing things right. I give some contextual 
information below (which may be skipped for a quick reading)
followed by a set of general questions on TAO event handling.

The context is this:

1. A CORBA application using 3 threads in total: 

   a. one for dispatching CORBA requests (calls ORB::run())

   b. one which runs a reactor event loop primarily 
      to process application socket data 
      (calls ACE_Reactor::instance()->run_event_loop())

   c. one which processes a queue (Q) of application events.

2. Thread (a) does NOT make CORBA client requests.
   Threads (b) and (c) do, however.

3. The process seems to have deadlocked with 

   (a) waiting for the client leader to complete

   (b) which has sent a CORBA request out and is waiting
   for a response seems to have called an event loop
   which resulted in dispatching a CORBA upcall 
   which in turn resulted in a wait on Q

   (c) waiting for a CORBA response (the server has already
   sent the response; but (c) seems to have not read it yet)

Given this context I have a set of questions:

1. Can one use a separate reactor (one returned by 
   ACE_Reactor::instance which happens to be a WFMO
   reactor) in conjunction with TAO which uses a TP
   reactor?
 
2. The WFMO reactor seems to dispatch CORBA calls 
   in addition to the application specific events


3. Are there examples/tests under the TAO build tree
   which depict application event integration with TAO?


4. Is there any way to tell ACE so that ACE_Reacto::instance()
   returns a specific instance (e.g., that used by the ORB)?
   And, in general, how do I specify the reactor type (WFMO or TP) 
   to ACE?


    REPEAT BY:

    SAMPLE FIX/WORKAROUND:

0
1/20/2004 5:44:32 PM
comp.soft-sys.ace 20326 articles. 1 followers. marlow.andrew (167) is leader. Post Follow

1 Replies
386 Views

Similar Articles

[PageSpeed] 9

> Would it be possible for you to upgared to 1.4 and give your test a 
> whirl? Please see

I can do that but if you can answer my general questions below that
would be great.  Thanks!


> > 1. Can one use a separate reactor (one returned by 
> >    ACE_Reactor::instance which happens to be a WFMO
> >    reactor) in conjunction with TAO which uses a TP
> >    reactor?
> >  
> > 2. The WFMO reactor seems to dispatch CORBA calls 
> >    in addition to the application specific events
> > 
> > 
> > 3. Are there examples/tests under the TAO build tree
> >    which depict application event integration with TAO?
> > 
> > 
> > 4. Is there any way to tell ACE so that ACE_Reacto::instance()
> >    returns a specific instance (e.g., that used by the ORB)?
> >    And, in general, how do I specify the reactor type (WFMO or TP) 
> >    to ACE?















-- Sankar

0
1/20/2004 6:10:25 PM
Reply:

Similar Artilces:

Re: [tao-users] [Event handling] : [deadlock problem with TAO/event handling]
Sankar- > TAO VERSION: 1.3.1 > ACE VERSION: 5.3.1 Would it be possible for you to upgared to 1.4 and give your test a whirl? Please see http://deuce.doc.wustl.edu/Download.html for details on how to download. Thanks bala > > HOST MACHINE and OPERATING SYSTEM: Windows 2000 > If on Windows based OS's, which version of WINSOCK do you > use?: > > TARGET MACHINE and OPERATING SYSTEM, if different from HOST: > COMPILER NAME AND VERSION (AND PATCHLEVEL): > Visual Studio .NET 2003 (7.1.3088) > > AREA/CLASS/EXAMPLE AFFECTED: Event handling > > DOES THE PROBLEM AFFECT: > COMPILATION? NO > If so, what do your $ACE_ROOT/ace/config.h and > $ACE_ROOT/include/makeinclude/platform_macros.GNU contain? > LINKING? NO > On Unix systems, did you run make realclean first? > EXECUTION? YES > OTHER (please specify)? > > > SYNOPSIS: > > Suspected deadlock when using TAO (using a TP reactor) > in conjunction with a WFMO reactor for other event processing. > > DESCRIPTION: > > I am facing a suspected deadlock situation and trying to investigate. > I need to do more work to nail down the problem, but I need some help > to know whether I am doing things right. I give some contextual > information below (which may be skipped for a quick reading) > fol...

Re: [tao-users] [Event handling] : [deadlock problem with TAO/event handling] #2
Sankar- > 1. Can one use a separate reactor (one returned by > ACE_Reactor::instance which happens to be a WFMO > reactor) in conjunction with TAO which uses a TP > reactor? The question I would ask is why? You get WFMO since you probably are on Win32 platform. But your application would get an instance of Select_Reactor if you are *nix based platforms. There is no harm in using the reactor returned, but they have limitations, which is why we have carefully chosen to have TP_Reactor as the default. > 2. The WFMO reactor seems to dispatch CORBA calls > in addition to the application specific events It has the capability but it has limitations. > > 3. Are there examples/tests under the TAO build tree > which depict application event integration with TAO? Yes, please see $TAO_ROOT/tests/XtStopwatch for an example of how Xt events are integrated with TAO's reactor event loop. Additionally please see $TAO_ROOT/examples/mfc to achieve something similar for integrating MFC-GUI based events. > > 4. Is there any way to tell ACE so that ACE_Reacto::instance() > returns a specific instance (e.g., that used by the ORB)? > And, in general, how do I specify the reactor type (WFMO or TP) > to ACE? Not directly. You could do the following after you intialize the ORB ACE_Reactor::instance (orb->orb_core ()->reactor ()); Once you do the above, every call to ACE_Reactor::instance () would give t...

[tao-users] Re: [ace-users] How to use c++ native exception handling instead of ACE's while building ACE+TAO
Hi, >> My only guess is that all of the libs you are linking in your >> builds were not compiled with a consistent set of options. Right, my recommendation would be to completely blow away your existing ACE+TAO x.5 directory, download a fresh version, and start from a clean slate. It sounds like you may have things lying around from previous build attempts. Thanks, Doug -- Dr. Douglas C. Schmidt Professor and Associate Chair Electrical Engineering and Computer Science TEL: (615) 343-8197 Institute for Software Integrated Systems WEB: www.dre.vanderbilt.edu/~schmidt Vanderbilt University, Nashville TN, 37203 NET: d.schmidt@vanderbilt.edu ...

[ace-users] [tao-users] Problem linking ACE/TAO
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPart_000_0042_01C67435.B64C4BE0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Hello, I have an application using ACE/TAO and I get a linking error trying to = build executable. ACE/TAO VERSION: 5.5 / 1.5 OPERATING SYSTEM: Win 2000 SP 4 COMPILER NAME and VERSION: VC++ 2005 Standard Edition CONTENTS of $ACE_ROOT/ace/config.h: #define ACE_HAS_STANDARD_CPP_LIBRARY 1 #include "ace/config-win32.h" DOES THE PROBLEM AFFECT: COMPILATION? NO LINKING? YES EXECUTION? N/A (doesn`t get that far) SYNOPSIS: I am getting linking error while I am trying to build executable. DESCRIPTION: In the makefile (win32/debug) the libraries ACED.lib and TAOD.lib are in = the LIBS. The error message is: 1>oe_frontendC.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: int __cdecl ACE_Log_Msg::log(enum ACE_Log_Priority,unsigned short const *,...)" (__imp_?log@ACE_Log_Msg@@QAAHW4ACE_Log_Priority@@PBGZZ) referenced in function "public: void __thiscall TAO::Any_Insert_Policy_AnyTypeCode_Adapter<int>::any_insert(class = CORBA::Any *,int const &)const " (?any_insert@?$Any_Insert_Policy_AnyTypeCode_Adapter@H@TAO@@QBEXPAVAny@CO= RBA @@ABH@Z) T...

[tao-users] [ace-users] Problem linking ACE/TAO
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPart_000_0042_01C67435.B64C4BE0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Hello, I have an application using ACE/TAO and I get a linking error trying to = build executable. ACE/TAO VERSION: 5.5 / 1.5 OPERATING SYSTEM: Win 2000 SP 4 COMPILER NAME and VERSION: VC++ 2005 Standard Edition CONTENTS of $ACE_ROOT/ace/config.h: #define ACE_HAS_STANDARD_CPP_LIBRARY 1 #include "ace/config-win32.h" DOES THE PROBLEM AFFECT: COMPILATION? NO LINKING? YES EXECUTION? N/A (doesn`t get that far) SYNOPSIS: I am getting linking error while I am trying to build executable. DESCRIPTION: In the makefile (win32/debug) the libraries ACED.lib and TAOD.lib are in = the LIBS. The error message is: 1>oe_frontendC.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: int __cdecl ACE_Log_Msg::log(enum ACE_Log_Priority,unsigned short const *,...)" (__imp_?log@ACE_Log_Msg@@QAAHW4ACE_Log_Priority@@PBGZZ) referenced in function "public: void __thiscall TAO::Any_Insert_Policy_AnyTypeCode_Adapter<int>::any_insert(class = CORBA::Any *,int const &)const " (?any_insert@?$Any_Insert_Policy_AnyTypeCode_Adapter@H@TAO@@QBEXPAVAny@CO= RBA @@ABH@Z) T...

[ace-users] RE: [tao-users] Problem with removing event handler
A bit more info. From what I can tell, handle_close is never getting called. Am I understanding correctly that it should be getting called as part of the remove_handler call? Rob. > -----Original Message----- > From: owner-tao-users@cse.wustl.edu > [mailto:owner-tao-users@cse.wustl.edu] On Behalf Of Rob Eger > Sent: Tuesday, September 09, 2003 4:07 PM > To: tao-users@cs.wustl.edu; ace-users@cs.wustl.edu > Subject: [tao-users] Problem with removing event handler > > > TAO VERSION: 1.3 > ACE VERSION: 5.3 > > HOST MACHINE and OPERATING SYSTEM: > RedHat 7.2, I386 > > TARGET MACHINE and OPERATING SYSTEM, if different from HOST: > same > > COMPILER NAME AND VERSION (AND PATCHLEVEL): > gcc (GCC) 3.2.3 > > AREA/CLASS/EXAMPLE AFFECTED: > event_handler, reactor > > DOES THE PROBLEM AFFECT: > COMPILATION? > no > > LINKING? > no > > EXECUTION? > yes > > DESCRIPTION: > Our server forks off a python session and sets up pipes for > communication. > We register an event_handler to handle the output from the > python session > over the pipe. When a user leaves the session it's marked as > a zombie. > When the another session is created, or the server is shut > down, we clean up > zombies. To shut down the python session we first call > remove_handler, then > eventHandl...

[ace-users] reactor handle events and event handlers
Hi, I'm looking for some advice on event handling, Please see below. ACE VERSION: 5.5 =20 HOST MACHINE and OPERATING SYSTEM: Intel P IV 2.8 Ghz, Win XP Prod v 2002, sp2, VC8 =20 TARGET MACHINE and OPERATING SYSTEM, if different from HOST: Same =20 THE $ACE_ROOT/ace/config.h FILE [if you use a link to a platform- specific file, simply state which one]: =20 "#include "ace/config-win32.h" "#define ACE_HAS_STANDARD_CPP_LIBRARY 1" =20 THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE [if you use a link to a platform-specific file, simply state which one (unless this isn't used in this case, e.g., with Microsoft Visual C++)]:=20 =20 CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features (used by MPC when you generate your own makefiles): n/a =20 AREA/CLASS/EXAMPLE AFFECTED: [What example failed? What module failed to compile?] Reactor/Event Handlers. =20 DOES THE PROBLEM AFFECT: COMPILATION? No LINKING? No EXECUTION? Yes OTHER (please specify)? N/A =20 [Please indicate whether ACE, your application, or both are affected.] My application only. =20 SYNOPSIS: Question about reactor event handlers.=20 =20 DESCRIPTION: Are registered event handlers still regis...

[ace-users] Re: [tao-users] Problem with removing event handler #2
Hi Rob, > A bit more info. From what I can tell, handle_close is never getting > called. Am I understanding correctly that it should be getting called as > part of the remove_handler call? Yes, as long as you don't pass the ACE_Event_Handler::DONT_CALL to remove_hander(), which it appears that you're doing ;-). Please see Chapters 3 and 4 of C++NPv2 <www.cs.wustl.edu/~schmidt/ACE/book2/> for all the gory details. Take care, Doug ...

RE: [ace-users] Re: [tao-users] Problem with removing event handler
Hi Doug, That's what I started looking at after I found the one version worked because that's what looked to be failing in the reactor source code, and my get_handle was indeed the problem. Both versions of remove_handler now work correctly. Thanks! Rob. > -----Original Message----- > From: owner-ace-users@cse.wustl.edu > [mailto:owner-ace-users@cse.wustl.edu] On Behalf Of Douglas C. Schmidt > Sent: Thursday, September 11, 2003 7:50 AM > To: Rob Eger > Cc: tao-users@cs.wustl.edu; ace-users@cs.wustl.edu > Subject: [ace-users] Re: [tao-users] Problem with removing > event handler > > > > Hi Rob, > > > However, the call to remove_handler was returning -1, which in > > looking at the reactor source code explains why handle_close is > > never getting called. > > As usual, you should crank up your debugger and figure out why -1 is > being returned. Chances are you're not overriding the get_handle() > method correctly! > > Take care, > > Doug > ...

[ace-users] RE: [tao-users] Problem with removing event handler #2 #3
Hi Doug, I figured that out, and removed ACE_Event_Handler::DONT_CALL from my remove_handler call this morning. As far as I can tell handle_close is still not getting called. Rob. > -----Original Message----- > From: Douglas C. Schmidt [mailto:schmidt@cse.wustl.edu] > Sent: Wednesday, September 10, 2003 11:47 AM > To: Rob Eger > Cc: tao-users@cs.wustl.edu; ace-users@cs.wustl.edu > Subject: Re: [tao-users] Problem with removing event handler > > > > Hi Rob, > > > A bit more info. From what I can tell, handle_close is > never getting > > called. Am I understanding correctly that it should be > getting called as > > part of the remove_handler call? > > Yes, as long as you don't pass the ACE_Event_Handler::DONT_CALL to > remove_hander(), which it appears that you're doing ;-). Please see > Chapters 3 and 4 of C++NPv2 <www.cs.wustl.edu/~schmidt/ACE/book2/> for > all the gory details. > > Take care, > > Doug > ...

[ace-users] Re: [tao-users] Problem with removing event handler #2 #2
Hi Rob, > I figured that out, and removed ACE_Event_Handler::DONT_CALL from my > remove_handler call this morning. As far as I can tell handle_close is > still not getting called. Perhaps you're not defining handle_close() with the right signature? At any rate, there's no good reason for this not to work, so I recommend you crank up the debugger and figure out what's going on. thanks, doug ...

[ace-users] RE: [tao-users] Problem with removing event handler #2 #4
Ok... Found a fix, but don't know why it works and the original way I was doing it doesn't. The call to register_handler was returning 0, which means all is okay. However, the call to remove_handler was returning -1, which in looking at the reactor source code explains why handle_close is never getting called. So, I tried the version of remove_handler where I pass in the handle that I'm watching events on, and, lo and behold, it all works - handle_close is called, remove_handler returns 0, no crashes, etc. Not sure why int result = orb->orb_core()->reactor()->remove_handler(eventHandler, ACE_Event_Handler::READ_MASK); doesn't work, and int result = orb->orb_core()->reactor()->remove_handler(parentIn, ACE_Event_Handler::READ_MASK); does. Figured I'd pass along what I found out, in case it indicates a problem somewhere in ACE or TAO. Thanks for the help, Rob. > -----Original Message----- > From: owner-tao-users@cse.wustl.edu > [mailto:owner-tao-users@cse.wustl.edu] On Behalf Of Douglas C. Schmidt > Sent: Wednesday, September 10, 2003 1:36 PM > To: Rob Eger > Cc: tao-users@cs.wustl.edu; ace-users@cs.wustl.edu > Subject: Re: [tao-users] Problem with removing event handler > > > > Hi Rob, > > > I figured that out, and removed ACE_Event_Handler::DONT_CALL from my > > remove_handler call this morning. As far as I can tell > handle_close is > > still not gettin...

[tao-users] Integrating ACE/TAO with existing signal-handling code
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I'm adding TAO client logic to an existing suite of C/C++ programs. These = already have handlers for signals such as SIGHUP, and the new CORBA code is= not intended to replace them. What I'd like is simply to prevent ACE from= installing its own signal handlers. =20 As a temporary measure, I've tried saving the SIGHUP handler from right bef= ore ORB::init, and restoring it right after. This doesn't seem to disturb = the CORBA interaction (all my tests pass). Obviously it's a hack, though -= - so what's the correct way to configure ACE here? Vance -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.0 Charset: utf-8 wsBVAwUBRgmEQAcnPbLcWESCAQiB3Qf+P3e1a+TJE0Pp2o89wgyzO9kf2bErnNEv 9DcXThSaSrDlv1LHimxxxklLUSqNZMPPM2vZ9eu53A9zhF13ErBzMgWbb7+TYYBp 4kiICJlSoPSjtcC1VAm6UlquZdxlJ05+TShO+nnxg+cxaJVROUh7bqUdxMbagbJx 2JgaNEG8lEULhv5yYfAbBpc3mikERREdHRxqWJgaUxO9/mf80zeaZpi4jL4kuXZO ZaeGwFJeySFkPiGj24OR7mOrTSlb7kRxPvjE0z0daUDNWhlOyoSFQsr4N+PdaE0T 75ajHXRRISuczYBS0a2xruDyjygnZAPLFmIbry7etxkRusP8NoYIAA=3D=3D =3DPMV2 -----END PGP SIGNATURE----- ...

[tao-users] Problem : TAO CORBA calls trigger Reactor events
TAO VERSION: 1.2.1 ACE VERSION: 5.2.1 HOST MACHINE and OPERATING SYSTEM: Red Hat Linux 7.3 / X86 TARGET MACHINE and OPERATING SYSTEM, if different from HOST: COMPILER NAME AND VERSION (AND PATCHLEVEL): gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-112) AREA/CLASS/EXAMPLE AFFECTED: Application code. DOES THE PROBLEM AFFECT: COMPILATION? No. LINKING? No. EXECUTION? Yes. SYNOPSIS: When invoking TAO CORBA calls, other Reactor events are triggered before the call returns. DESCRIPTION: Our application uses both TAO and its underlying Reactor. The Reactor is used to handle TCP sockets communications and timers. The code is currently single-threaded and the methods are not reentrant. The application basically runs a Reactor event loop and performs various operations when Reactor events are triggered. Part of these operations requires invoking TAO CORBA calls to other processes of our application. When we invoke a TAO CORBA method, TAO seems to be running a second Reactor event loop in order to receive the reply. This Reactor event loops seems to be handling the same events as the first (original) event loop is expected to handle. This causes a mess in our code because we assumed that CORBA invocation is "atomic". What we want to achieve, is blocking the handling of Reactor events in this 2nd loop - i.e. we don't want events to be triggered "unexpectedly" during the CORBA call. We...

[tao-users] Handle CORBA and Non-CORBA events
Hello, We're currently porting our applications to TAO. Everything is going well, except that for the moment the TAO (Notification Service) doesn't support the Pull Model. That means we have to change the philosophy of some of our "processes". These processes mainly are processes which already have a non-CORBA "loop" to handle different types of events: Graphical events, "socket" events and so on. It was simpler to use the Pull model and the ACE_Event_Handler+Reactor->schedule_timer() (yes the original implementations already used the ACE lib). Since the Pull model is not supported we have to change these processes, basically each of them should become a CORBA server. Could someone point me out some examples/tests where this is demonstrated in TAO (handle CORBA and non-CORBA events)? We also bought the books but I cannot find this information. I guess it is possible but I would like to know if there is a "standard" way of doing this using ACE/TAO facilities. Thanks for any help, Cheers, Pierre. Hello Pierre, Pierre Pacchioni wrote: > We're currently porting our applications to TAO. Everything is going well, > except that for the moment the TAO (Notification Service) doesn't support > the Pull Model. Correct. > That means we have to change the philosophy of some of our "processes". > These processes mainly are processes which already have a non-CORBA "loop" > to handle dif...

RE: [tao-users] Handle CORBA and Non-CORBA events
Hello Steve, >> It was simpler to use the Pull model and the >> ACE_Event_Handler+Reactor->schedule_timer() (yes the original >> implementations already used the ACE lib). >I think I see. When the timer fired, your event handler's >handle_timeout() method would pull an event. Is that >right? You're right. >> Since the Pull model is not supported we have to change these processes, >> basically each of them should become a CORBA server. Could someone point me >> out some examples/tests where this is demonstrated in TAO (handle CORBA and >> non-CORBA events)? We also bought the books but I cannot find this >> information. I guess it is possible but I would like to know if there is a >> "standard" way of doing this using ACE/TAO facilities. >There are several ways to interleave CORBA events with >events from other sources: >- Use non-blocking ORB event handling operations (work_pending() >and perform_work()) to implement a polling loop. See >$TAO_ROOT/tests/Explicit_Event_Loop for an example. >- Dedicate separate threads for CORBA request processing and for >processing events from other sources. The thread(s) that >is/are dedicated to the ORB could just call orb->run() like >any CORB server. Other threads could run your existing reactor >event loop. >- Use one of the special resource factory and reactor types >provided by TAO that are designed f...

[tao-users] TAO Event Service : a first-time user
Hello Taoists, I am using TAO for the first time. However, it is TAO's Event Service/Notification Service that I am interested in. I am using a Push/Push model for the purpose. While running the POC, I came across a situation which I don't know, how to solve. If the Consumer crashes suddenly (without disconnecting itself from the channel), the Supplier does not know about it. So, it happily keeps pumping messages into the Channel. What is the best way to inform the Supplier that the Consumer does not exist any more (and hence, he can stop pumping)? Are there any configurable parameters (for the Event Service/Notification Service) which determine how the Channel deals with this problem? Needless to say, any help will be highly appreciated. a_philomath Hi, Please use the PROBLEM-REPORT-FORM (PRF), found in $TAO_ROOT/PROBLEM-REPORT-FORM, for asking questions about or reporting problems with ACE+TAO on this mailing list. Otherwise, we have to guess at things like the version of ACE+TAO you are using and on what platform(s). a_philomath wrote: > Hello Taoists, > > I am using TAO for the first time. However, it is TAO's Event > Service/Notification Service that I am interested in. TAO has more than one Event Service. There is the CosEvent service (based on the OMG spec) and TAO's proprietary Real-Time Event Service. Which one are you using? > I am using a Push/Push model for the purpose. While running the POC, > I came acro...

[tao-users] file handles with ACE/TAO 5.5.0/1.5.0
Hi * We are running a multi-daemon system with a central "dispatcher" ORB connecting to number of decentral ORBs (up to 400). The "dispatcher" also occasionally opens files to write status data to disk. The system is running as 32bit app on Solaris 9. Things went fine as long as we used ACE/TAO 5.4.0/1.4.0 but since we switched to 5.5.0/1.5.0 we have a problem with the number of used file handles. According to the "pfiles" command the number of used filehandles is much larger than before and it seems that every connection to another ORB stays alive as long as the system runs. Since this gets us well beyond 256 file handles the occasional writing to a real file fails. We have tried both uiop and iiop connections to the different ORBs but that didn´t change anything. We also tried "-ORBKeepalive 0" and "-ORBLingerTimeout 10" but that didn ´t help either. Does anyone have any hints for me where the problem could be located or what to try next? Thx heiko On Friday, June 30, 2006 10:04:55 AM UTC+3, Heiko Jansen wrote: > Hi * >=20 > We are running a multi-daemon system with a central "dispatcher" ORB=20 > connecting to number of decentral ORBs (up to 400). The "dispatcher"=20 > also occasionally opens files to write status data to disk. > The system is running as 32bit app on Solaris 9. >=20 > Things went fine as long as we u...

[tao-users] TAO, Event Channel and multicast
This is a multi-part message in MIME format. ------=_NextPart_000_0087_01C3EAF5.7A859DD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: tao-bugs@cs.wustl.edu Subject: [area]: [synopsis] TAO VERSION: 1.3 ACE VERSION: 5.3 HOST MACHINE and OPERATING SYSTEM: IBM P4 2.6Ghz 512 Mo RDRAM, Windows 2000, Winsock v5.0.2195.4874 = ( Ws32.dll ) TARGET MACHINE and OPERATING SYSTEM, if different from HOST: COMPILER NAME AND VERSION (AND PATCHLEVEL): AREA/CLASS/EXAMPLE AFFECTED: None DOES THE PROBLEM AFFECT: COMPILATION? No LINKING? No EXECUTION? Yes=20 OTHER (please specify)? [Please indicate whether ACE/TAO, your application, or both are = affected.] SYNOPSIS: Infinite loop in event_channel_admin->forConsumers() DESCRIPTION: We have tried RTEC\MCast example. We have written a consumer which = connects to the channel event. But, if we disable the code about federation, the consumer works. And if = we enable it, the consumer blocks in the channel_event_admin->forConsumers() function. Why ? REPEAT BY: [What you did to get the error; include test program or session transcript if at all possible. ] SAMPLE FIX/WORKAROUND: [If available ] ------=_NextPart_000_0087_01C3EAF5.7A859DD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUB...

[tao-users] TAO cannot handle BOM in wstrings
TAO VERSION: 1.3.3 ACE VERSION: 5.3.3 HOST MACHINE and OPERATING SYSTEM: SuSe Linux 8.2 (2.4.20) TARGET MACHINE and OPERATING SYSTEM, if different from HOST: COMPILER NAME AND VERSION (AND PATCHLEVEL): GCC 3.3 DOES THE PROBLEM AFFECT: COMPILATION? no LINKING? On Unix systems, did you run make realclean first? no EXECUTION? yes OTHER (please specify)? SYNOPSIS: TAO cannot handle BOM in wstrings. DESCRIPTION: If a wstring contains a BOM, TAO returns a MARSHAL exception. This is the case when the wstring comes from the jdk 1.4.2 ORB. This is not the case with OCI's 1.3a version. Hi Keith, Keith Thornton wrote: > TAO VERSION: 1.3.3 > ACE VERSION: 5.3.3 > Thanks for using the PRF. > > SYNOPSIS: > TAO cannot handle BOM in wstrings. > > > DESCRIPTION: > > If a wstring contains a BOM, TAO returns a MARSHAL exception. This is the case when the wstring comes from > the jdk 1.4.2 ORB. This is not the case with OCI's 1.3a version. > > As Victor pointed out in another email, a BOM encoded with the wchar data is allowed only with UTF-16. Since the BOM is optional even with UTF-16, TAO does not emit it. There are two possible solutions, and neither is perfect. First, we could make the CDR codeset-aware, so that if UTF-16 is both the native and transmitted wchar codeset, the BOM will st...

[tao-users] Problem linking ACE/TAO
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPart_000_0042_01C67435.B64C4BE0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Hello, I have an application using ACE/TAO and I get a linking error trying to = build executable. ACE/TAO VERSION: 5.5 / 1.5 OPERATING SYSTEM: Win 2000 SP 4 COMPILER NAME and VERSION: VC++ 2005 Standard Edition CONTENTS of $ACE_ROOT/ace/config.h: #define ACE_HAS_STANDARD_CPP_LIBRARY 1 #include "ace/config-win32.h" DOES THE PROBLEM AFFECT: COMPILATION? NO LINKING? YES EXECUTION? N/A (doesn`t get that far) SYNOPSIS: I am getting linking error while I am trying to build executable. DESCRIPTION: In the makefile (win32/debug) the libraries ACED.lib and TAOD.lib are in = the LIBS. The error message is: 1>oe_frontendC.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: int __cdecl ACE_Log_Msg::log(enum ACE_Log_Priority,unsigned short const *,...)" (__imp_?log@ACE_Log_Msg@@QAAHW4ACE_Log_Priority@@PBGZZ) referenced in function "public: void __thiscall TAO::Any_Insert_Policy_AnyTypeCode_Adapter<int>::any_insert(class = CORBA::Any *,int const &)const " (?any_insert@?$Any_Insert_Policy_AnyTypeCode_Adapter@H@TAO@@QBEXPAVAny@CO= RBA @@ABH@Z) T...

[tao-users] TAO Notification + Event Channels
Hi, When the Notification Service is started there is a single Event Channel created that allows suppliers of events to send data to that channel. Is there any reason a supplier would create a new event channel ? Is there performance related reasons for this ? If a supplier does create a new event channel, this is registered with the naming service to allow consumers access the new event channel. When a consumer connects to this channel, is it still connected to the Notification Service ? If the supplier does not register with the naming service, can the consumer connect using the get_all_channels and get_event_channel by ID ? Thanks for your time, Joe ...

[ace-users] [ace-user] problem on building ACE+TAO+CAIO
Dear, all. I have a problem on buliding ACE+TAO+CAIO. ACE VERSION: 5.5 HOST MACHINE and OPERATING SYSTEM: HOST Machine: Intel Pentium D 3.0 1GB OS: Windows XP Professional SP2 TARGET MACHINE and OPERATING SYSTEM Same with the HOST machine and OS THE $ACE_ROOT/ace/config.h FILE #define ACE_HAS_MFC 1 #define ACE_NO_INLINE #define ACE_HAS_STANDARD_CPP_LIBRARY 1 #include "ace/config-win32.h" DOES THE PROBLEM AFFECT: ACE+TAO+CAIO building SYNOPSIS: occurrance of syntax error during building ACE+TAO+CAIO DESCRIPTION: during building ACE+TAO+CAIO, syntax errors occurs at the point of enum definition in the file, options.h. Also, there are bunch of other errors. class ACE_Svc_Export Options { // = TITLE // Singleton that consolidates all Options for a gatewayd. public: // = Options that can be enabled/disabled. enum { // = The types of threading strategies. REACTIVE = 0, OUTPUT_MT = 1, INPUT_MT = 2, VERBOSE = 01, DEBUG = 02, SUPPLIER_ACCEPTOR = 04, CONSUMER_ACCEPTOR = 010, SUPPLIER_CONNECTOR = 020, CONSUMER_CONNECTOR = 040 }; one of them says that '}' is missing in front of '='. Did I misconfigure something? Thanks. - Je...

[tao-bugs] Re: [tao-users] ACE 5.4.0 TAO 1.4 build problems in orbsvcs
Hi Bill, It looks to me like you haven't built Kokyu, which is in $ACE_ROOT/Kokyu/ Please try building this first and then build TAO. Chris/Venkita/Bala/Don, can we please figure out a way to keep the lack of Kokyu being built from causing the rest of orbsvcs from failing?! Thanks, Doug > Makefile: > /export/home/bcassan/ACE_wrappers/TAO/orbsvcs/orbsvcs/Makefile.RTKokyuEvent > > g++ -W -Wall -Wpointer-arith -pipe -O3 -D_REENTRANT > -I/export/home/bcassan/ACE_wrappers -I/export/home/bcassan/ACE_wrappers/TAO > -DACE_NDEBUG -DACE_USE_RCSID=0 -DACE_HAS_EXCEPTIONS -D__ACE_INLINE__ > -I/export/home/bcassan/ACE_wrappers/TAO > -I/export/home/bcassan/ACE_wrappers/TAO/orbsvcs > -I/export/home/bcassan/ACE_wrappers/TAO/orbsvcs/orbsvcs/ESF > -DTAO_RTKOKYUEVENT_BUILD_DLL -c -fPIC -o .shobj/EC_Kokyu_Filter.o > Event/EC_Kokyu_Filter.cpp > g++ -W -Wall -Wpointer-arith -pipe -O3 -D_REENTRANT > -I/export/home/bcassan/ACE_wrappers -I/export/home/bcassan/ACE_wrappers/TAO > -DACE_NDEBUG -DACE_USE_RCSID=0 -DACE_HAS_EXCEPTIONS -D__ACE_INLINE__ > -I/export/home/bcassan/ACE_wrappers/TAO > -I/export/home/bcassan/ACE_wrappers/TAO/orbsvcs > -I/export/home/bcassan/ACE_wrappers/TAO/orbsvcs/orbsvcs/ESF > -DTAO_RTKOKYUEVENT_BUILD_DLL -c -fPIC -o .shobj/EC_Kokyu_Filter_Builder.o > Event/EC_Kokyu_Filter_Builder.cpp > g++ -W -Wall -Wpointer-arith -pipe -O3 -D_REENTRANT > -I/export/home/bcassan/ACE_wrappers -I/...

Web resources about - [tao-users] [Event handling] : [deadlock problem with TAO/event handling] - comp.soft-sys.ace

Resources last updated: 3/22/2016 10:00:33 PM