f



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

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
2/4/2005 8:59:58 PM
comp.soft-sys.ace 20326 articles. 1 followers. marlow.andrew (167) is leader. Post Follow

2 Replies
212 Views

Similar Articles

[PageSpeed] 54

Hi Johnny,

   I'm going to finish it this week. I've upgraded to TAO 1.4.4, and
had a lot ot trouble with a deadlock with the orb_core mutex and the
object_adapter one. I'll send a describing email soon explaining where
it occurs and giving suggestion on how to avoid it.
  So, as I've just found the deadlock, I'll return to the regression test.


On Wed, 2 Mar 2005 11:57:12 +0100, Johnny Willemsen
<jwillemsen@remedy.nl> wrote:
> 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
> > >
> >
> 
> 













































































































































































































































-- 
Eider Oliveira
ICQ - 26992792
<img src=http://www.danasoft.com/sig/EiderOliveira.jpg>
http://www.danasoft.com/sig/EiderOliveira.jpg

0
Eider
3/2/2005 2:49:59 PM
------=_Part_392_26265617.1109798782326
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Johnny,

  Renato Lucindo made it, I'm attaching the code. I didn't test it
yet, as I still compiling the cvs code.

[]s


On Wed, 2 Mar 2005 09:38:23 -0300, Eider Oliveira
<eider.oliveira@gmail.com> wrote:
> Hi Johnny,
> 
>    I'm going to finish it this week. I've upgraded to TAO 1.4.4, and
> had a lot ot trouble with a deadlock with the orb_core mutex and the
> object_adapter one. I'll send a describing email soon explaining where
> it occurs and giving suggestion on how to avoid it.
>   So, as I've just found the deadlock, I'll return to the regression test.
> 
> On Wed, 2 Mar 2005 11:57:12 +0100, Johnny Willemsen
> <jwillemsen@remedy.nl> wrote:
> > 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
> > > >
> > >
> >
> >
> 
> --
> 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

------=_Part_392_26265617.1109798782326
Content-Type: application/x-gzip; name="TaoBug.tar.gz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="TaoBug.tar.gz"

H4sIACMuJkIAA+0aa3PbOC5f41/BcSdduXUcO3WaG2ebHdlxUt84TsdyHzdthqPItKOrLPkkKo/L
5r8fQFIv28qjvWRv94SZRBIJgiAIgADokem1w+nW2lNCHWB3Zwefjd2duvhu7LwVTwVrjfp2o9Hc
3q2/aa5B53ZjZ43sPClXCsKAmz4ha74TWrY79vLwjqhlUcd2pyGbUYN+WeyPFhI9/yQwkvsvHzV7
7DzBHCiPt81m/v7v7sj9f9Pc2cH2xi58rpFnEeL/+f6XbJczf2JajEgdKN2U1tcvPHtMAse77JiO
o1X2oqaJGfCo6Xav9EczX8BPQ9b+Z3PrCea4z/6b228i+3+7+1baf6Ow/2eB0tz3/sksrr0KmH/B
/EqLcNOT71V8dewzemnzcwpnA7kpEcKumGvOGHlHJFYJ2gBpbvLzgLx+R7bCwN9yPMt0tqCZEOw3
vNC3GD20HRYIIkQNrlnzOXzelm5LCSeWYzOXS07ke5XMPZ+bZzBcDFtgRCL9ICNycIqRP3pLnhWU
/Se78QRz3G3/YPXN3Sj+e9t8s432v91sFPb/HPDCdi0nHDNSlppg1M7LpVLc+iuY4NbJsF07319o
HOkntIexg2s6y70flLkaQq8WPu9HP9ERJ4UE8cmWYXAf5J8djR19b0qPgxUdI3vG6CfTCdly34mx
MIVjBxwbxmxiu4x09H7fGOnDEdE7XXrQbX880rT+Me0NDk+qpLwxIhu8RTYCAv7FYeOqcGimy6EJ
/Oa5HYBfql9t1P/2hWzuk3b3qDf45parhNJJ6FqUSqTNfXRhtGbRgPtaRY2sVDJsdAcH4Kf+G2wA
pccwEXPRPznSJp4/M8ET12q1CvkmXCe5n62yHFZemPbFC0o/6VQfHhmU4kwlyzGDQMWg1Cat0vo8
PHNsi4AyUNlcTdoy+tJqDdmk44UuN+Ti22bAMI6d+/aFyRnQWkc2O1KBiFgtxrQRPUSIZtYszw04
sc7BK7wSqBXoXW/JUVrUgFEynFlLoTLIzvcuidYBo9FbLeM64GzWvbLYnNueG41cj7UL2VjHP2Qw
0VfCL7SdKqmL0Fv0nRitVuAwNtf4BbRGRGBH9zKsJCH6D7GSoQkhfmZfDD29Lwt7oGSvWxyF7vki
kWBuOCOqx+CwF0E0rUEHJyO9M+p96lbld+bjoCs+9VH3AFtu1XZFGwpfGaokwMfX7VPEW+Ts5Azj
it6YgHwChZNsfbz3hq7FQpHk6qcY5YjXBr6meI6FniMGAn7FBN/ImVKoXKZeAldi0QrIEipawJz7
EAOZQhfv3Nfq0vBDz780/fGQ/StkAY+XmLYI5TQoardQA+5f40Mgrqd7awHjWt5aKPfQhQBFDRZV
ifX3Fv9ZJrfOiZKG4r2tH9AP+lA/Ji8ryXxyfQrlpP33bmeEgqfdLz1jpEUkl9gM3cCeumxMwAre
ZZaEG7lJftF/2csievwcYsl3OOA3Uict0pAI4p89IRp07JNG5X6OxAj0kuWNoFzNTB651coCbalX
ggXQLVQuqVlCEGpJElsSHjNTmhajnpC3thFUypHmZNxWRYuVQ+wGvTD9ysM2LVAcVSpEMbyeZZRk
bFOhgGZu7i8zmKYnMW+TVUnVgtQCtULOYY9PM6u3wI+nja6lFhtjk0RsipP1M5+Z3/cy47ODhTBJ
IkJiOjBkfE0E94z8bgze/060s3BauXsnV86Vkk3uhAwlwkzH/jcjrsfV0U2uGZeTP2La25RSCWlL
ocDrkuEpjYgdBXkJGVTK6gSb7Gr+dSM4BQ7YVY36bA5pnxargjCDlPn5jIe+S1x2GR/cWi7nyRGV
Wv9jnGOuX9x6Bfr3aisXL3LJirUYL3JCnucw0wUyFj5DWLNLIRmd+iwIUmSX0H02M20X7UspPkgV
BpDESWtktZMmD/DCpZ/2vKVHOMXSj3i8hzi8Uq6VS7XLs5tVtpu1+8xZnDWLHMexZIlofdLs77G5
hPZtZmc298FIZt4Fg8dEqyRhk1D0S9/mrHcynNgOy8aV2ILzVEmm2fb8SkmWJQ57/S60eCGfh5wi
Piw6CgQn3py5WkKkfFkWW4I7mBkBwT/I+iaO1oUELNPFhSMNRV/wQyBUFyyjLgLXGL/XSPdKNIB8
ounEKqXp7wnCt6UoERC8QZDm8iwjmBKgmuD69rLYluPBXqWRcSUxr5e+xxmOQ7cEQRWJ6GT4Ad8C
cxI0Rw1fTH9qVZVQ4f3i6ymKVYYLN0InIX0FvR62Wy1IcczQ4TS4sChsxoQyFwxJBKrr2uBjvy8c
ACmj8kHYKy2PgsmCLk6v6SHoj+dfk2/lTSDX8Vwr9H3mWtcYfsO5sjln/ibQdUHn0PIRayR6PjC/
E7dj6A8yIJBA9Qa9UfdbuZydtyPKVHnzjnzTDbBGdhxeRSik+6XT/2iA+hPFGs4V9545nvUdHIPo
E8QTbt6b7tiB0Gj4GfioyHh5PXIGwzbGE8Tzz0AjU43gCjnRpOhR6LDpS2OF6Ynh4LJVmIDnlX+2
uQ/u1nPAkpCObTpoUQwlCdG9Vh56Hgd/HxNcdRYoskBvRW+rBYbto09OZq6BulTuoHhsuuYUNjvi
dya/YQIR8MAxRhMsbWGtHzxIL677Nlj3XLxSrDBoTYGWaqmBFk/5uUaaZLFLJiBiLgs0BgIrx56w
YG7C+SSwtOWVdocGeOjuYLRMrbFIzR5TSO7gfJihauWR/Gh0h7R3sExve5GeL1MMPDxh1wI8GSU+
WTq4gCgFup/0wYge6wP9qDtcov9mkX7kocH5AMOgp7nkh92R3hvIYypPVSBsoVJd0nNAr1YesEtU
tmp614WyVNN7Kcmj14yCq499D3ynjTWXPXj8Spb3mYCekNev7TgCSK/YPsUwGk4e7zo6TFbqpopo
0vo5u4bs/F0qFsN0VjCo1rm5DwFELEK1KA2HRWYgxB+vd3M/Cue1PBOJow/hD+yxvsL0ZFSC8UmE
rZWVGd9Hrv1Acu073AwYuhILzWqq8i3R3QaGTTp4rN5BvyXl12rU6pLwSqrth1Jt51BNCCdJGh5s
euQPpY9KR3awlsRlrRzcvmtwO+PvMsFJ2azBaHmy6gIj232WdLcjAuJ8xuo5j4JX5sulSXceukRq
jkCc2C5G/IuopTh5FFpPtEYVws+YSNyMTWAMIpfJTWVuJMFsSbI7HJ4Mk5okiwZhQCGqktlMR0wE
VEpRdlPf+yvfCan7n+QS7AnmuOf+d6e+E9//NAFD3P/Um8X9z3PA4o2JGXxfvivJvXmRlyg/dBuT
6pyAjTNzlsbHoETeK5UWb6g68obq2W4mziDfJwH35iibhYK4jJuxg7SIqouLQj60/IovxyNq/GPQ
eb+/cB0hUhPMakDvm6fpQyaJrnOuKJI581LKFCksjwApdYWBRLWkF0LicTgH4njGI1aq/D1utWy1
L5B1RamZlsq5RMUg7iH7+7iepNBj+zw0HSLy4LGnis+aKhMBWxURJEmHjSkbpF9J+T1T1115/Mpz
jkJQEwcEKq+XOaYYqWbDIRyTFXUEx5kAjEjFPnDmneNKNEyOow3P1CPlZVmyGn4W1QfGniHuZqIy
588U36oqcwQMkXqDWi+cUqmqeqoMV89W2WKW0qWmzA0Tn81TNYUp4xyT0MnYVMHnijupepVoYmAt
DBhs2KsG+LrKBsFH/mXVqrskqcaHZrBgPotKLgxnpQnEYx9tB0vGmyqlKKybJPjOVWFQqtUayyFy
Sf9ULqMMD9MFHI43tqsLsglNKdgVkjUc7/JHJRuP/Z+UbPZ3iY+WLA5/hGQFj4I8lYeSKDDBq6go
CYpTTzRAX5Vc2o48LZQRB7IwF7kTsDfuh+zBFavUuInpBKIsrNgweke9wahKMswh+1Gd68dLNnnq
EKgXPckXcFP37sNvJwmExM+z5Il6uWeCJfxVE8TM1uI8dvR+SAfdz7T/+UOUZcQs3oGFSX7E2J3E
YnbuJpZwdmnaXFvgI2rLzJogJnMkbQvZ0sOTpTvufBSNbBr0182DCiiggAIKKKCAAgoooIACCiig
gAIKKKCAAgoooIACCiiggAIKKODPDP8BsTzV9ABQAAA=
------=_Part_392_26265617.1109798782326--

0
Eider
3/2/2005 11:02:27 PM
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:37:56 PM