f



RE: [tao-users] Re: Requests arriving between deactivate_object and etherealize #2

Hi,

Do you have an update on the regression test? The new POA implementation is
in cvs, we are handling the last issues but it would be great if we can fix
your problem before the x.4.5 release.

Johnny 

> -----Original Message-----
> From: owner-tao-users@cse.wustl.edu 
> [mailto:owner-tao-users@cse.wustl.edu] On Behalf Of Johnny Willemsen
> Sent: vrijdag 4 februari 2005 20:32
> To: 'Eider Oliveira'
> Cc: tao-users@cs.wustl.edu
> Subject: RE: [tao-users] Re: Requests arriving between 
> deactivate_object and etherealize
> 
> Hi,
> 
> > I'll write the regression test.
> 
> Thanks very much! At the moment you have the regression test 
> ready, can you
> make a bugzilla entry and file it there (see
> http://deuce.doc.wustl.edu/bugzilla/index.cgi). Then the test and the
> problem doesn't get lost in all the hectic work.
> 
> Johnny
> > 
> > 
> > On Thu, 3 Feb 2005 22:49:58 +0100, Johnny Willemsen
> > <jwillemsen@remedy.nl> wrote:
> > > Hi Eider,
> > > 
> > > Thanks for using the PRF form. Would you be able to write a 
> > small regression
> > > test that reproduces this problem. After the upcoming x.4.4 
> > release we will
> > > checkin a complete rewrite of the PortableServer library. 
> > The code you
> > > mentioned has been refactored and already several issues 
> > has been resolved.
> > > When you could send us a regression test it will help us to 
> > fix the problem
> > > then.
> > > 
> > > For a peek at the new ServantActivator handling.
> > > 
> > http://cvs.doc.wustl.edu/cvsweb.cgi/ACE_wrappers/TAO/tao/Porta
> > bleServer/Atti
> > > c/RequestProcessingStrategyServantActivator.cpp
> > > 
> > > Regards,
> > > 
> > > Johnny Willemsen
> > > Remedy IT
> > > Leeghwaterstraat 25
> > > 2811 DT Reeuwijk
> > > The Netherlands
> > > www.theaceorb.nl / www.remedy.nl
> > > 
> > > 
> > > > This still valid for TAO 1.4.3, as I checked in the source code.
> > > >
> > > >
> > > > On Thu, 3 Feb 2005 14:35:58 -0200, Eider Oliveira
> > > > <eider.oliveira@gmail.com> wrote:
> > > > >     TAO VERSION: 1.4.2
> > > > >     ACE VERSION: 5.4.2
> > > > >
> > > > >     HOST MACHINE and OPERATING SYSTEM: Linux
> > > > >
> > > > >     TARGET MACHINE and OPERATING SYSTEM, if different 
> from HOST:
> > > > >     COMPILER NAME AND VERSION (AND PATCHLEVEL): gcc 
> (GCC) 3.3.5
> > > > > (Debian 1:3.3.5-8)
> > > > >
> > > > >     AREA/CLASS/EXAMPLE AFFECTED: Servant Activator
> > > > >
> > > > >     DOES THE PROBLEM AFFECT:
> > > > >         COMPILATION?
> > > > >         LINKING?
> > > > >         EXECUTION? yes, TAO
> > > > >         OTHER (please specify)?
> > > > >
> > > > >     SYNOPSIS:
> > > > > Under high load, requests which arrive to a object
> > > > deactivated object,
> > > > > which still processing the active requests, leads to 
> > incarnation of
> > > > > another object instance, when it should be hold.
> > > > >
> > > > >     DESCRIPTION:
> > > > > In my application, we use ServantActivactors. I logged 
> > a sequence of
> > > > > activation, deactivaction, incarnation and etheralization
> > > > which shows
> > > > > two objects in memory, at the same time, using the same oid
> > > > >
> > > > > This is a syslog excerpt. the first columnt after the PID
> > > > is the thread id.
> > > > >
> > > > > Feb  3 13:49:40 localhost Server[2234]: 2844564400
> > > > incarnate oid teste55
> > > > > Feb  3 13:49:40 localhost Server[2234]: 2844564400 Constructor
> > > > > 0x08238250, oid teste55
> > > > > Feb  3 13:49:41 localhost Server[2234]: 2878176176
> > > > Deactivating oid teste55
> > > > > Feb  3 13:49:46 localhost Server[2234]: 2668219312
> > > > incarnate oid teste55
> > > > > Feb  3 13:49:46 localhost Server[2234]: 2668219312 Constructor
> > > > > 0x082AEDA8, oid teste55
> > > > > ===>Here the code detected the duplicate and refused to
> > > > incarnate the
> > > > > object <===
> > > > > Feb  3 13:49:46 localhost Server[2234]: 2668219312 Destructor
> > > > > 0x082AEDA8, teste55
> > > > > Feb  3 13:49:48 localhost Server[2234]: 2844564400
> > > > etherealize teste55
> > > > > Feb  3 13:49:48 localhost Server[2234]: 2844564400 Destructor
> > > > > 0x08238250, teste55
> > > > >
> > > > >     REPEAT BY:
> > > > > Using the Evictor Pattern on chapter 11.6 Advanced 
> > CORBA Programming
> > > > >
> > > > >     SAMPLE FIX/WORKAROUND:
> > > > >
> > > > > In the Active_Object_Map.cpp file, method
> > > > >
> > > > > 
> > TAO_Persistent_Strategy::find_servant_using_system_id_and_user_id
> > > > > (const PortableServer::ObjectId &system_id,
> > > > >
> > > > > const PortableServer::ObjectId &user_id,
> > > > >
> > > > > PortableServer::Servant &servant,
> > > > >
> > > > > TAO_Active_Object_Map::Map_Entry *&entry)
> > > > > {
> > > > >   int result =
> > > > this->active_object_map_->id_hint_strategy_->find (system_id,
> > > > >
> > > >       entry);
> > > > >   if (result == 0 &&
> > > > >       user_id == entry->user_id_)
> > > > >     {
> > > > >       if (entry->deactivated_)
> > > > >         result = -1;
> > > > >       else if (entry->servant_ == 0)
> > > > >         result = -1;
> > > > >       else
> > > > >         servant = entry->servant_;
> > > > >     }
> > > > >   else
> > > > >     {
> > > > >       result = this->active_object_map_->user_id_map_->find
> > > > (user_id,
> > > > >                                                         
> >      entry);
> > > > >       if (result == 0)
> > > > >         {
> > > > >           if (entry->deactivated_)
> > > > >             result = -1;                    <========== 
> > this should
> > > > > return a different value
> > > > >           else if (entry->servant_ == 0)
> > > > >             result = -1;                    <==== than 
> > this one, so
> > > > > the POA will be able to hold on
> > > > >           else
> > > > >             servant = entry->servant_;
> > > > >         }
> > > > >     }
> > > > >
> > > > >   if (result == -1)
> > > > >     entry = 0;
> > > > >
> > > > >   return result;
> > > > > }
> > > > >
> > > > > This is necessary, for the comment on POA.cpp makes sense:
> > > > >
> > > > > void
> > > > > TAO_POA::deactivate_map_entry 
> (TAO_Active_Object_Map::Map_Entry
> > > > > *active_object_map_entry
> > > > >                                ACE_ENV_ARG_DECL)
> > > > > {
> > > > >   // Decrement the reference count.
> > > > >   CORBA::UShort new_count =
> > > > --active_object_map_entry->reference_count_;
> > > > >
> > > > >   if (new_count == 0)
> > > > >     {
> > > > >       this->cleanup_servant (active_object_map_entry
> > > > >                              ACE_ENV_ARG_PARAMETER);
> > > > >       ACE_CHECK;
> > > > >     }
> > > > >   else
> > > > >     {
> > > > >       // It should be noted that there may be a period of
> > > > time between
> > > > >       // an object's deactivation and the 
> > etherealization (during
> > > > >       // which outstanding requests are being 
> > processed) in which
> > > > >       // arriving requests on that object should not be
> > > > passed to its
> > > > >       // servant. During this period, requests targeted 
> > for such an
> > > > >       // object act as if the POA were in holding state until
> > > > >       // etherealize completes. If etherealize is called as a
> > > > >       // consequence of a deactivate call with a 
> > etherealize_objects
> > > > >       // parameter of TRUE, incoming requests are rejected.
> > > > >
> > > > >       // Else mark entry as closed...
> > > > >       active_object_map_entry->deactivated_ = 1;
> > > > >     }
> > > > > }
> > > > >
> > > > >
> > > > > --
> > > > > Eider Oliveira
> > > > > ICQ - 26992792
> > > > > <img src=http://www.danasoft.com/sig/EiderOliveira.jpg>
> > > > > http://www.danasoft.com/sig/EiderOliveira.jpg
> > > > >
> > > >
> > > >
> > > > --
> > > > Eider Oliveira
> > > > ICQ - 26992792
> > > > <img src=http://www.danasoft.com/sig/EiderOliveira.jpg>
> > > > http://www.danasoft.com/sig/EiderOliveira.jpg
> > > >
> > > 
> > > 
> > 
> > 
> > -- 
> > Eider Oliveira
> > ICQ - 26992792
> > <img src=http://www.danasoft.com/sig/EiderOliveira.jpg>
> > http://www.danasoft.com/sig/EiderOliveira.jpg
> > 
> 












































































































































































































































0
Johnny
3/2/2005 1:04:51 PM
comp.soft-sys.ace 20326 articles. 1 followers. marlow.andrew (167) is leader. Post Follow

0 Replies
238 Views

Similar Articles

[PageSpeed] 45

Reply:

Similar Artilces:

RE: [tao-users] Re: Requests arriving between deactivate_object and etherealize
Hi Eider, Thanks for using the PRF form. Would you be able to write a small regression test that reproduces this problem. After the upcoming x.4.4 release we will checkin a complete rewrite of the PortableServer library. The code you mentioned has been refactored and already several issues has been resolved. When you could send us a regression test it will help us to fix the problem then. For a peek at the new ServantActivator handling. http://cvs.doc.wustl.edu/cvsweb.cgi/ACE_wrappers/TAO/tao/PortableServer/Atti c/RequestProcessingStrategyServantActivator.cpp Regards, Johnny Willemsen Remedy IT Leeghwaterstraat 25 2811 DT Reeuwijk The Netherlands www.theaceorb.nl / www.remedy.nl > This still valid for TAO 1.4.3, as I checked in the source code. > > > On Thu, 3 Feb 2005 14:35:58 -0200, Eider Oliveira > <eider.oliveira@gmail.com> wrote: > > TAO VERSION: 1.4.2 > > ACE VERSION: 5.4.2 > > > > HOST MACHINE and OPERATING SYSTEM: Linux > > > > TARGET MACHINE and OPERATING SYSTEM, if different from HOST: > > COMPILER NAME AND VERSION (AND PATCHLEVEL): gcc (GCC) 3.3.5 > > (Debian 1:3.3.5-8) > > > > AREA/CLASS/EXAMPLE AFFECTED: Servant Activator > > > > DOES THE PROBLEM AFFECT: > > COMPILATION? > > LINKING? > > EXECUTION? yes, TAO > > OTHER (please speci...

Re: [ace-users] Re: [tao-users] Re: difficulties compling TAO with mingw and msys #2
Hi, > > Great, when we get time we will try to upgrade to a newer version of MinGW, > > but it is still a candidate. Just keep an eye on the scoreboard, when we > > upgrade you will see it there. As you can see on the scoreboard, there are > > no issues with the 3.2.3 version > > I have run all but a few of the provided tests, and all looks well. We run all ACE tests, no issues there, we are working on the TAO tests, some of the tests are able to freeze our build system > Out of curiosity, what is required for eliminating the > inline/dlli...

Re: [ace-users] Re: [tao-users] Re: difficulties compling TAO with mingw and msys
Hi, Great, when we get time we will try to upgrade to a newer version of MinGW, but it is still a candidate. Just keep an eye on the scoreboard, when we upgrade you will see it there. As you can see on the scoreboard, there are no issues with the 3.2.3 version Regards, Johnny Willemsen Remedy IT Leeghwaterstraat 25 2811 DT Reeuwijk The Netherlands www.theaceorb.nl / www.remedy.nl "William Lederer" <wgl@localhost.localdomain> wrote in message news:<m3pt4yrtfx.fsf@localhost.localdomain>... > Thanks! > > I followed your advice in your earli...

[tao-users] RE: [ace-users] Re: How to use Any>>=OctetSeq in TAO 1.3.6? #2
Hi, > > Heiko, could you try to add TAO_Export to front of the operators in > > OctetSeqA.h and then rebuild TAO and you app. I think the linker > > errors should be gone. > > this is the solution! Thank you :-) Thanks for the feedback. I have just committed the fix into the repo and this will be in the 1.4 release. Regards, Johnny Willemsen Remedy IT Leeghwaterstraat 25 2811 DT Reeuwijk The Netherlands www.theaceorb.nl / www.remedy.nl ...

RE: [tao-users] Re: [ace-users] Re: Announcing the release of the new beta (ACE-5.4.10, TAO-1.4.10 and CIAO-0.4.10)
Hi, > > >> We encourage you to download the new beta, use it with your > > >> applications, and let us know soon if you encounter any problems > > >> since we plan to cut the x.5 release by February 28th. > > > > As per Wallace's comments, we have an aggressive schedule > for the x.5 > > release to meet the needs of some major sponsors. If > people can give > > x.4.10 a "test drive" in the next couple of days and report problems > > they encounter we'll try to ensure that we fix any > showstoppers before > > According to bugzilla bug 2323 is not fixed yet. > > http://deuce.doc.wustl.edu/bugzilla/show_bug.cgi?id=2323 > > For us it is a show stopper. We use the OCI version which does not > have problems related to this bug but it would be nice to be able to > use the latest version with more fixes. FYI, the reason that this test now fails is because Ossama added several new test cases which wheren't in the test in the past, this uncovered some bugs which according to our information where already there a long time. Johnny "Johnny Willemsen" <jwillemsen@remedy.nl> writes: > > > >> We encourage you to download the new beta, use it with your > > > >> applications, and let us know soon if you encounter any problems > > > >> sinc...

Re: Re: Re: Re: Re: [ace-users] How to delete the handler object afterdisconnection? #2
Hi, >> As far as I know, on window platform, named event can share between >> processes. So if the server signal the named event, I think the >> named event on the client side should be signaled. Ah, I didn't realize that you were just doing this stuff between processes on the same machine. Why are you using a named event object to synchronize a pipe between a client and server? That seems like unnecessary overhead/complexity. Why don't you just pass messages using ACE_SPIPE* or ACE_SOCK*? Take care, Doug >> Best Regards! >> ����������������He HongFu >> ����������������hhf@eisoo.com >> ��������������������2005-08-10 >> >> ======= Original Message on 2005-08-09 20:52:16 ======= >> >> >Hi, >> > >> >>> Dr. Douglas has told me use the overloaded method ACE_Reactor::register_handler() to implement the SPIPE with ACE_Reactor. I get some clues from Dr. Douglas' instruction: >> >>> >> >>> 1. Uses a named event object to synchronize between pipe client and pipe server. >> >>> 2. On the client side, call ACE_Reactor::register_handler (pipe_handler, named_event_handle) to register the named event. >> >>> 3. When the pipe server send data to client, it will signal the named event on the server side. >> > >> >> > >> >>> 4. The pipe...

Re: [tao-users] Re: ACE/TAO call back problem #2
This is a multipart message in MIME format. --=_alternative 0025F9B5C1256F63_= Content-Type: text/plain; charset="us-ascii" I had a similar problem a long time ago :-). In my case, the IOR passed by the client to the server contained a hostname which was unknown in the server. We did not use a DNS. The server used a hosts file. In our case, using ORBDottedDecimalAddresses 1 was the solution. Best wishes --=_alternative 0025F9B5C1256F63_= Content-Type: text/html; charset="us-ascii" <br><font size=2 face="sans-serif">I had a similar p...

RE: [ace-users] RE: [tao-users] Octet Marshaling/Demarshaling issues #2
Hi, If you marshal a corba sequence of octet then instead of the normal << and >> for each element the methods write_octet_array and read_octet_array on the stream are used, in fact, all corba sequences of basic types to use array methods on the cdr stream. If you handle your own cdr streaming you can of course use these methods also. Regards, Johnny Willemsen Remedy IT Postbus 101 2650 AC Berkel en Rodenrijs The Netherlands www.theaceorb.nl / www.remedy.nl > -----Original Message----- > From: owner-ace-users@cse.wustl.edu > [mailto:owner-ace-users@cse.wustl.edu] On Behalf Of Krishna, Arvind > Sent: woensdag 28 december 2005 19:55 > To: Kobi Cohen-Arazi; ace-users@cs.wustl.edu; tao-users@cs.wustl.edu > Subject: [ace-users] RE: [tao-users] Octet > Marshaling/Demarshaling issues > > > Hi Kobi, > > >It takes 4 bytes to marshal a single Octet. However, when > marshaling an > array of Octet, it takes a single byte for >every element in > the array. > It seems that Octet is an exception comparing the rest of > primitive data > types. What is >the motivation for that? Is it dictated by an > OMG spec? > > I think you might be seeing a type promotion from octet to > long. I just > checked and ACE_CDR provides a read_octet and write_octet methods for > reading/writing octets. However, if you use the insertion/extraction > operator t...

RE: [ace-users] RE: [tao-users] Octet Marshaling/Demarshaling issues #2
Prof Schmidt, > Right, but Kobi's point (which I believe is correct) is that an octet > is *encoded* into 4 bytes. The original motivation for this was to > maximize performance on RISC machines, where the alignment was > traditionally 32 bit boundaries. I don't think there is any alignment or padding required for an octet unlike a long. This is what I see in the ACE_CDR (de) marshaling operations. I think you can encode the octet directly into CDR_Stream occupying 1 byte in size. This can be done (as I understand) by: .. write_octet defined on ACE_OutputCDR or .. using the from_octet helper struct Thanks, Arvind ...

RE: [ace-users] RE: [tao-users] Octet Marshaling/Demarshaling issues #2
This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C60BE3.C29DC8C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, The padding added after marshalin an octet depends on what comes next in the stream. For this struct foo { long one; octet two; long three; }; there will indeed be 4 total bytes used for the octet, since the type that follows it must be aligned to a 4-byte boundary, and we know that the octet marshaling started on a 4-byte boundary because of the previous member. However this is not always the case. For example, struct bar { long one; octet two; octet three; octet four; octet five; long six; }; will use just 1 byte for each octet, since by the time we get to 'six', we are already aligned to a 4-byte boundary, so no additional padding is necessary. Jeff _____ From: owner-tao-users@cse.wustl.edu [mailto:owner-tao-users@cse.wustl.edu] On Behalf Of Johnny Willemsen Sent: Wednesday, December 28, 2005 1:08 PM To: Krishna, Arvind; Kobi Cohen-Arazi; tao-users@cs.wustl.edu Subject: RE: [ace-users] RE: [tao-users] Octet Marshaling/Demarshaling issues Hi, If you marshal a corba sequence of octet then instead of the normal << and >> for each element the methods write_octet_array and read_octet_array on the stream are used, in fact, all corba sequences of basic types to use array metho...

RE: [ace-users] RE: [tao-users] Octet Marshaling/Demarshaling issues #2
This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C60C02.4B4663D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I'm saying that the question can't be answered until the next basic type is marshaled. The padding is always added just before the next item is marshaled (since the next item determines what size boundary we must align to), but it is logically counted as being part of the previous item, at least the way you are wording the original question. Jeff _____ From: Krishna, Arvind [mailto:arvindkr@qualcomm.com] Sent: Wednesday, December 28, 2005 7:40 PM To: Jeff Parsons; Johnny Willemsen; Kobi Cohen-Arazi; tao-users@cs.wustl.edu Subject: RE: [ace-users] RE: [tao-users] Octet Marshaling/Demarshaling issues Hi Jeff, [....] struct foo { long one; octet two; long three; }; > there will indeed be 4 total bytes used for the octet, since the type that follows > it must be aligned to a 4-byte boundary, and we know that the octet marshaling > started on a 4-byte boundary because of the previous member. However this is > not always the case. So if the struct were: struct foo { long one; octet two; } Then will "two" be 1/4 bytes? I think it will be 1 and always 1. It is while marshaling the long that the ACE_CDR's current alignment is checked to add the appropriate pad...

RE: [ace-users] RE: [tao-users] Octet Marshaling/Demarshaling issues #2
Hi Jeff, [....]� struct foo { � long one; � octet two; � long three; }; � > there will indeed be 4 total bytes used for the octet, since the type that follows > it must be aligned to a 4-byte boundary, and we know that the octet marshaling > started on a 4-byte boundary because of the previous member. However this is > not always the case. So if the struct were: struct foo { long one; octet two; } Then will "two" be 1/4 bytes? I think it will be 1 and always 1. It is while marshaling the long that the ACE_CDR's current alignment is checked to add the appropriate padding to get it to a four byte boundary right? Am I right and is that what you are saying? Thanks, Arvind ...

RE: [ace-users] RE: [tao-users] Octet Marshaling/Demarshaling issues #2
This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C60C02.CA0D3950 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, So you're saying that the total size of struct bar on the wire is 24 bytes? I could be wrong, but I don't think so - I think it is 12 bytes. Jeff _____ From: Kobi Cohen-Arazi [mailto:kobi.cohenarazi@gmail.com] Sent: Wednesday, December 28, 2005 7:46 PM To: Jeff Parsons Cc: Johnny Willemsen; Krishna, Arvind; tao-users@cs.wustl.edu Subject: Re: [ace-users] RE: [tao-users] Octet Marshaling/Demarshaling issues Hi Jeff, I'm not sure I see the behavior you describes. When marshaling one octet at a time, 4 bytes are marshaled. When marshaling an octet array, one byte per Octet is marshaled. Thanks, Kobi. On 12/28/05, Jeff Parsons <j.parsons@vanderbilt.edu> wrote: Hi, The padding added after marshalin an octet depends on what comes next in the stream. For this struct foo { long one; octet two; long three; }; there will indeed be 4 total bytes used for the octet, since the type that follows it must be aligned to a 4-byte boundary, and we know that the octet marshaling started on a 4-byte boundary because of the previous member. However this is not always the case. For example, struct bar { long one; octet two; octet three; octet four; octet five; long six; }; will use ju...

[ace-users] Re: [tao-users] Re: A client thread assigned to handle a server request
Hi Ivo, >> Sorry for the comment but as for TAO 1.3a patch level 12 this >> MT_NOUPCALL did not work 100% as expected. I don't remember what >> the problem was, but this was the motivation for us to change our >> code to create 2 ORBs instead of 1 ( one to handle client requests >> and one to handle server requests, in order to decouple >> server/client handling). I'll let the OCI folks handle this since they are the ones who added MT_NOUPCALL. Thanks, Doug >> Regards, >> Ivo >> >> > -----Original Message----- >> > From: owner-tao-users@cse.wustl.edu >> > [mailto:owner-tao-users@cse.wustl.edu]On Behalf Of ronen_yuval >> > Sent: Tuesday, March 14, 2006 6:37 PM >> > To: tao-users@cs.wustl.edu >> > Subject: [tao-users] Re: A client thread assigned to handle a >> > server request >> > >> > >> > > >> According to the documents, I understand that this option will >> > > >> cause the client side of my "Middle Server" to serialize requests >> > > >> for the "End Server". >> > > >> > > No, that's not what it means. >> > > >> > > All "exclusive" means is that a separate connection will be used for >> > > each thread on the client, rather than mux...

[ace-users] RE: [tao-users] Borland Developer Studio 2006 with ACE/TAO #2
Hi, See http://www.remedy.nl/en/borland.html for an overview of the supported Borland products with TAO. Regards, Johnny Willemsen Remedy IT Postbus 101 2650 AC Berkel en Rodenrijs The Netherlands www.theaceorb.nl / www.remedy.nl > -----Original Message----- > From: Espen Harlinn [mailto:espen@harlinn.no] > Sent: donderdag 2 februari 2006 18:06 > To: jwillemsen@remedy.nl > Cc: ace-users@cs.wustl.edu > Subject: RE: [tao-users] Borland Developer Studio 2006 with ACE/TAO > > Hi, > > I'm curious about the current status of ACE/TAO and C++ Builder 2006. > Borland shipped the promised fix/update some time ago, but I > couldn't find > anything about how it works with ACE/TAO. > > Regards > Espen Harlinn > > ...

RE: [ace-users] Re: what version tao/ace for AIX 5.2 posix aio
Hi Duane, I can't speak for TAO's use of AIO, but ACE 5.4 does support AIO on AIX 5.2. -Steve -- Steve Huston, Riverace Corporation Co-author of "C++ Network Programming" and "The ACE Programmer's Guide" Books, ACE kit and support info at http://www.riverace.com/ > -----Original Message----- > From: owner-ace-users@cse.wustl.edu > [mailto:owner-ace-users@cse.wustl.edu] On Behalf Of Douglas C. Schmidt > Sent: Sunday, July 04, 2004 2:49 PM > To: shuston@riverace.com; ace-users@cs.wustl.edu > Subject: [ace-user...

[ace-users] RE: [tao-users] Borland Developer Studio 2006 with ACE/TAO #2
Hi, The x.4.8 version of ACE/TAO is supported with BCB2006, we have some linker warnings/errors in some configurations, Borland is working on these for Update2, but these are not causing a problem. See ACE_wrappers/ACE-INSTALL.html for info about how to use it. We deliver also commercial support for using BCB2006 with ACE/TAO. See www.theaceorb.nl for our services. Regards, Johnny Willemsen Remedy IT Postbus 101 2650 AC Berkel en Rodenrijs The Netherlands www.theaceorb.nl / www.remedy.nl > -----Original Message----- > From: Espen Harlinn [mailto:espen@harlinn.no] > Sent: donderdag 2 februari 2006 18:06 > To: jwillemsen@remedy.nl > Cc: ace-users@cs.wustl.edu > Subject: RE: [tao-users] Borland Developer Studio 2006 with ACE/TAO > > Hi, > > I'm curious about the current status of ACE/TAO and C++ Builder 2006. > Borland shipped the promised fix/update some time ago, but I > couldn't find > anything about how it works with ACE/TAO. > > Regards > Espen Harlinn > > ...

Re: [ace-bugs] Re: [ace-users] RE: Module->open() #2
Hi, >> I guess I'm just pushing the limits a bit and trying to avoid >> writing a whole bunch of new code. This is a time-honored way in which ACE evolves. >> I view ACE_Stream/Module/Task as a good vehicle for a >> component-based design of network protocol processing that includes >> complex/stateful behaviors. Right, I agree. >> The Streams framework has components and behaviors relevant to >> dynamically configuring services which consist of a set of >> cooperating sub-objects. I understand that the assumption in ...

Re: Re: Re: Re: [ace-users] How to delete the handler object afterdisconnection? #2
Hi, >> Dr. Douglas has told me use the overloaded method ACE_Reactor::register_handler() to implement the SPIPE with ACE_Reactor. I get some clues from Dr. Douglas' instruction: >> >> 1. Uses a named event object to synchronize between pipe client and pipe server. >> 2. On the client side, call ACE_Reactor::register_handler (pipe_handler, named_event_handle) to register the named event. >> 3. When the pipe server send data to client, it will signal the named event on the server side. Don't you mean "it will signal the named event on the *client* side? >> 4. The pipe client read data on the overriden method handle_signal(). >> >> Dr. Douglas, something I'm wrong? That sounds about right to me. >> >Procator works(I never tried but some people mentioned it on this maillist). >> >There is an example(not very clean:)) distributed in ACE's source code. >> >You can serch the mailist(google group) to find some useful information. >> >> On the server side of my application, I have used Proactor pattern with spipe, but still not be tested(client cannot work). >> >> 1. Start a thread which use ACE_SPIPE_ACCEPTOR to accept numbers of pipe client. >> 2. On the pipe handler open() method, call ACE_Asynch_Read_Stream::open() and ACE_Asynch_Write_Stream::open() for Proactor instance. >> 3. On the pipe handler open() method, star...

RE: [ace-users] Re: ACE #2
This is a multi-part message in MIME format. ------_=_NextPart_001_01C6413F.CD2A80C8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Logging_Strategy problems were fixed in 5.4.7. You should definitely upgrade. =20 Howard =20 _____ =20 From: owner-ace-users@cse.wustl.edu [mailto:owner-ace-users@cse.wustl.edu] On Behalf Of Kobi Cohen-Arazi Sent: Thursday, March 02, 2006 12:44 AM To: hileon@gmail.com Cc: ace-users@cs.wustl.edu Subject: Re: [ace-users] Re: ACE =20 Hi, We had bugs in that specific area (Limit the size using Logging_Strategy) in x.4.0. You probably seeing that same bug ... It was fixed year ago. Upgrading may help.=20 Thanks, Kobi. On 3/1/06, Douglas C. Schmidt <schmidt@cse.wustl.edu> wrote: Hi, >> I use ACE 5.4+TAO 1.4. To ensure that we have proper version/platform/compiler information, please make sure you fill out the appropriate problem report form (PRF), which is in $ACE_ROOT/PROBLEM-REPORT-FORM=20 $TAO_ROOT/PROBLEM-REPORT-FORM or in $ACE_ROOT/BUG-REPORT-FORM $TAO_ROOT/BUG-REPORT-FORM in older versions of ACE+TAO. Make sure to include this information when asking any questions about ACE+TAO since otherwise we have to=20 "guess" what version/platform/compiler/options you've using, which is error-prone and slows down our responsiveness. Moreover, please upgrade to ACE+TAO x.4.10, which you can download...

RE: [ace-users] Re: ACE #2
Hi, Somewhere in your app you should run the reactor loop Regards, Johnny Willemsen Remedy IT Postbus 101 2650 AC Berkel en Rodenrijs The Netherlands www.theaceorb.nl / www.remedy.nl > >> I update the ACE version to 5.4.10, but it seems have no help. > >> > >> ACE_Logging_Strategy : the -m option does not work. > >> > >> ACE VERSION: 5.4.10 > >> > >> HOST MACHINE and OPERATING SYSTEM: > >> Windows XP SP2 > >> > >> TARGET MACHINE and OPERATING SYSTEM, if different from HOST: > >> Windows XP SP2 > >> > >> THE $ACE_ROOT/ace/config.h FILE : > >> #include "ace/config-win32.h" > >> > >> 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++)]: > >> Microsoft Visual C++ 6.0 sp6 > >> > >> CONTENTS OF > >> $ACE_ROOT/bin/MakeProjectCreator/config/default.features > >> (used by MPC when you generate your own makefiles): > >> There is no this file. > >> > >> AREA/CLASS/EXAMPLE AFFECTED: > >> APG\Logging\Use_Logging_Strategy.d...

RE: [ace-users] Re: ACE #2
Hi Folks, > Sorry about the wrong message. It does work, I did not wait enough > To roll it over. Ok, great - I'm glad to hear that it works! Thanks, Doug ...

RE: [tao-users] RE: [ace-users] XML service configuration no longer works with ACE/TAO 5.4.5/1.4.5
Hi, > > Hi Lothar > > > > > � � ACE VERSION: 5.4.5 > > > > Thanks for using the PRF form. Could you try to find the > problem and send > > us patches to fix this? > > > > Regards, > > > > Johnny Willemsen > > I have no problem committing some time to the problem. I do > however know as > much as nothing about the ACE XML parser and it's recent > changes. It seems to > me that (some) of the recent changes might have caused the > test failures. So > if someone working actively on ACEXML gives me directions I > am willing to > spend my time investigating the problem. I can't remember that work has been done the last months so I am also amazed things broke. Nobody is actively working on it, so I think there are not much directions at this moment. Regards, Johnny Willemsen Remedy IT Postbus 101 2650 AC Berkel en Rodenrijs The Netherlands www.theaceorb.nl / www.remedy.nl On Wednesday 18 May 2005 11:01, Johnny Willemsen wrote: > Hi, > I can't remember that work has been done the last months so I am also > amazed things broke. Nobody is actively working on it, so I think there are > not much directions at this moment. Well, it did definiteley work with 5.4.4. So any changes that broke it must have been made between 5.4.4 and 5.4.5. I also read in the release email of 5.4.5 in the CIAO...

Web resources about - RE: [tao-users] Re: Requests arriving between deactivate_object and etherealize #2 - comp.soft-sys.ace

Resources last updated: 3/5/2016 6:07:41 PM