f



Re: [tao-users] Reactive/Concurrency: Difference between different ORBReactorType

Hi Abhi,

>     DESCRIPTION:
>     What is the difference between the following ReactorTypes:
> 
>     - select_st (Guess it is a select based reactor in a single thread)

Right - you generally don't want to use this unless you know you'll
only ever have a single thread.

>     - select_mt (Is it a Worker thread pool architecture, where a I/O
>     thread selects on the ORB endpoints (& also the connection endpoints),
>     reads new client requests, and queues them into the tail of a
>     request queue. A worker thread in the pool then dequeues the next
>     request from the head of the queue. How many threads are
>     configured in the worker threadpool. Is this done by a config
>     value or in application code? )

"No" to all of the above.  The select_mt is simply a reactor that can
be used safely in a multi-threaded configuration, e.g.,
thread-per-connection.

>     - tp (Is it a leader_follower thread pool architecture?

Actually, it just selects the ACE_TP_Reactor, which can be used to
implement a Leader/Followers thread pool architecture.

>      How is the number of threads configured? )

You spawn the threads, so you control them.  Please see the
discussions in

$TAO_ROOT/docs/configurations.html

for more info on this.

>     I guess these values are used by both the client & the server?

Sure, but they are mostly useful for applications that play the role
of a server.

>     Basically how do these types map to the Architectures shown in
>     "Evaluating Architectures for Multi-threaded CORBA Object Request
>     Brokers" by Douglas Schmidt.

These options just select the type of reactor the ORB uses, and as
such are somewhat orthogonal to the discussions in that paper.

>     Also there are 2 ORBConcurrency strategies:
> 
>     - thread-per-connection: Does this work with any of the 3
>     ReactorTypes above.

Yes.

> Is it at all worthwhile to use this with tp ReactorType?

I don't think so, but I'll let Bala answer that in detail.

>     - reactive: I guess this can be used with any of the 3
>       ReactorTypes above.

That's correct.

>     I guess these values are used only by the server?

They are useful for applications that play the role of a server.

BTW, there's more discussion about this stuff in the OCI TAO 1.3
Developer's Guide <www.theaceorb.com/product/>.

Take care,

        Doug
0
schmidt7304 (285)
12/4/2003 7:35:23 AM
comp.soft-sys.ace 20326 articles. 1 followers. marlow.andrew (167) is leader. Post Follow

1 Replies
346 Views

Similar Articles

[PageSpeed] 19

Hi Doug,
    Thanks for your response. Please see my question below:

>
> Hi Abhi,
>
>>     DESCRIPTION:
>>     What is the difference between the following ReactorTypes:
>>
>>     - select_st (Guess it is a select based reactor in a single thread)
>
> Right - you generally don't want to use this unless you know you'll
> only ever have a single thread.

Does this mean, that select_st should only be used with (ORBConcurrency) 
reactive, and never with thread-per-connection. If this is true, then the 
svc.conf file does not make sense under 
$TAO_ROOT/performance-tests/Cubit/TAO/IDL_Cubit

>
>>     - select_mt (Is it a Worker thread pool architecture, where a I/O
>>     thread selects on the ORB endpoints (& also the connection
>>     endpoints), reads new client requests, and queues them into the tail
>>     of a request queue. A worker thread in the pool then dequeues the
>>     next request from the head of the queue. How many threads are
>>     configured in the worker threadpool. Is this done by a config
>>     value or in application code? )
>
> "No" to all of the above.  The select_mt is simply a reactor that can
> be used safely in a multi-threaded configuration, e.g.,
> thread-per-connection.
>
>>     - tp (Is it a leader_follower thread pool architecture?
>
> Actually, it just selects the ACE_TP_Reactor, which can be used to
> implement a Leader/Followers thread pool architecture.
>
>>      How is the number of threads configured? )
>
> You spawn the threads, so you control them.  Please see the
> discussions in
>
> $TAO_ROOT/docs/configurations.html
>
> for more info on this.
>
>>     I guess these values are used by both the client & the server?
>
> Sure, but they are mostly useful for applications that play the role
> of a server.
>
>>     Basically how do these types map to the Architectures shown in
>>     "Evaluating Architectures for Multi-threaded CORBA Object Request
>>     Brokers" by Douglas Schmidt.
>
> These options just select the type of reactor the ORB uses, and as
> such are somewhat orthogonal to the discussions in that paper.
>
>>     Also there are 2 ORBConcurrency strategies:
>>
>>     - thread-per-connection: Does this work with any of the 3
>>     ReactorTypes above.
>
> Yes.
>
>> Is it at all worthwhile to use this with tp ReactorType?
>
> I don't think so, but I'll let Bala answer that in detail.
>
>>     - reactive: I guess this can be used with any of the 3
>>       ReactorTypes above.
>
> That's correct.
>
>>     I guess these values are used only by the server?
>
> They are useful for applications that play the role of a server.
>
> BTW, there's more discussion about this stuff in the OCI TAO 1.3
> Developer's Guide <www.theaceorb.com/product/>.
>
> Take care,
>
>         Doug





































































0
abhi1 (8)
12/4/2003 7:03:46 PM
Reply:

Similar Artilces:

Re: [tao-users] Reactive/Concurrency: Difference between different ORBReactorType #2
Hi Abhi, > Does this mean, that select_st should only be used with (ORBConcurrency) > reactive, and never with thread-per-connection. No, it just means that you need to be REALLY careful when you use select_st with anything other than reactive ORB concurrency... > If this is true, then the svc.conf file does not make sense under > $TAO_ROOT/performance-tests/Cubit/TAO/IDL_Cubit This test is trying to see how fast TAO will run when most of the "safety" options are turned off. It therefore does a number of things that are probably not a good idea unless you know a lot about how your server application behaves wrt concurrency. In particular, the IDL_Cubit operation is completely stateless and idempotent, which is not necessarily representative of a "normal" server. Take care, Doug ...

[tao-users] Reactive/Concurrency: Difference between different ORBReactorType
To: tao-users@cs.wustl.edu Subject: Reactive/Concurrency: Difference between different ORBReactorType TAO VERSION: 1.3.5 ACE VERSION: 5.3.5 HOST MACHINE and OPERATING SYSTEM: Linux Redhat 9 kernel 2.4.20-19.9 SYNOPSIS: Question about the difference between various ORBConcurrency & ReactorType DESCRIPTION: What is the difference between the following ReactorTypes: - select_st (Guess it is a select based reactor in a single thread) - select_mt (Is it a Worker thread pool architecture, where a I/O thread selects on the ORB endpoints (& also the connection endpoints), reads new client requests, and queues them into the tail of a request queue. A worker thread in the pool then dequeues the next request from the head of the queue. How many threads are configured in the worker threadpool. Is this done by a config value or in application code? ) - tp (Is it a leader_follower thread pool architecture? How is the number of threads configured? ) I guess these values are used by both the client & the server? Basically how do these types map to the Architectures shown in "Evaluating Architectures for Multi-threaded CORBA Object Request Brokers" by Douglas Schmidt. Also there are 2 ORBConcurrency strategies: - thread-per-connection: Does this work with any of the 3 ReactorTypes above. Is it at all worthwhile to use this with tp ReactorType? ...

Re: [tao-users] Is it possible to use two different versions of the ACE/TAO in the same application?
Hi, >> I'm developing an application (Intel Pentium 4 - Linux Red Hat 2.4.21-4.EL - >> g++ 3.2.3) that uses two different "third party" libraries. >> The first one was compiled and linked with ACE-TAO 5.4/1.4. The second one with >> ACE-TAO 5.4.8/1.4.8. The second library was compiled enabling >> ACE_HAS_VERSIONED_NAMESPACE and TAO_HAS_VERSIONED_NAMESPACE to avoid >> symbolic ambiguity. >> >> The following ld warnings appear when I compile my application: >> >> "/usr/bin/ld: warning: libTAO_IORTable.so.1.4.8, needed by ... may conflict >> with libTAO_IORTable.so.1.4.0 >> /usr/bin/ld: warning: libTAO_CosNaming.so.1.4.8, needed by ... may conflict >> with libTAO_CosNaming.so.1.4.0 >> /usr/bin/ld: warning: libTAO_Messaging.so.1.4.8, needed by ... may conflict >> with libTAO_Messaging.so.1.4.0 >> /usr/bin/ld: warning: libTAO_Valuetype.so.1.4.8, needed by ... may conflict >> with libTAO_Valuetype.so.1.4.0 >> /usr/bin/ld: warning: libTAO_CosNotification.so.1.4.8, needed by ... may >> conflict with libTAO_CosNotification.so.1.4.0 >> /usr/bin/ld: warning: libTAO_PortableServer.so.1.4.8, needed by ... may >> conflict with libTAO_PortableServer.so.1.4.0 >> /usr/bin/ld: warning: libTAO.so.1.4.8, needed by ... may conflict with >> libTAO.so.1.4.0 >> /usr/bin/ld: warning: libACE.so.5.4.8, needed by .....

[ace-users] Re: Difference between version of Ace
Hi Dale, >> Have just picked up some work developed by someone who has >> left. The code uses ACE V 5.09 and I would like to know what the >> differnces between it and the latest version are? I recommend that you check out the release notes that Riverace has put out for the ACE 5.2 and ACE 5.3 releases <http://www.riverace.com/ACE_Kits/ace_kits.html>. These give a summary of the changes. Naturally, the DETAILED discussions of all the differences are available in $ACE_ROOT/ChangeLogs/ Take care, Doug -- Dr. Douglas C. Schmidt, Professor TEL: (615) 343-8197 Electrical Engineering and Computer Science FAX: (615) 343-7440 Vanderbilt University WEB: www.cs.wustl.edu/~schmidt/ Nashville, TN 37203 NET: d.schmidt@vanderbilt.edu ...

[tao-users] RE: [ace-users] ACE/TAO on Solaris 10
Hi, There have been some replies. People do have things working on Solaris and there have been made fixes in ACE/TAO. Could you wait another week or so and try the x.4.8 or try cvs, see http://cvs.doc.wustl.edu Regards, Johnny Willemsen Remedy IT Postbus 101 2650 AC Berkel en Rodenrijs The Netherlands www.theaceorb.nl / www.remedy.nl > Dear list members, > > (I sent this message couple of days ago and am unsure if it > was distributed, > thus re-sending it again. I apologize if you received it more > than once) > > I would like to give feedback regarding availability of > ACE/TAO (versions > 5.4.7 and 1.4.7 respectively) on OpenSolaris (Solaris 10) > Intel platform. > > Sun is selectively releasing source code of the Solaris 10 under an > open-source license. Details of this project and installable Solaris > binaries can be found on here: > http://www.opensolaris.org > > Sun has also released Forte compiler set in binary form to > the OpenSolaris > community. A Quote from their website: "Sun Studio 10 > software is freely > available to participants in the OpenSolaris community for > development on > both OpenSolaris and Solaris[tm] Operating Systems on > SPARC-based systems > and x86-based systems, as well as on Linux." You can get > access to Forte > compilers from the OpenSolaris website as well but you should register...

RE: [tao-users] Communication between different TAO versions
Hello Phil, thank you very much for the detailed information! > The FEFF you see is what is known as the Byte Order Marker, or BOM. Actually I did recognize the BOM, because the false result of the CORBA call was converted to UTF-8 and written to a log file. I just didn't think it was intentional. > A third way around this would require a configuration change on the > older clients. I assume that your older clients are not particularly > modifiable, otherwise you could just redeploy them using TAO 1.4.4. Fortunately we have not sent out a client yet, so the time to switch to 1.4.4 seems perfect. I just hope no other incompatibilities arise. Thanks again for your help! Kerry ...

[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 ...

[tao-users] RE: [ace-users] Tao_idl core dumps during ACE/TAO build
Hi, Please upgrade to ACE+TAO x.4.7, which you can download from http://deuce.doc.wustl.edu/Download.html under the heading "latest beta kit". The DOC groups at Washington University, UC Irvine, and Vanderbilt University only provide "best effort" support for non-sponsors for the latest beta kit, as described in http://www.cs.wustl.edu/~schmidt/ACE_wrappers/docs/ACE-bug-process.html Thus, if you need more "predictable" help, I recommend that you check out http://www.cs.wustl.edu/~schmidt/commercial-support.html for a list of companies that will provide you with ACE+TAO commercial support. Regards, Johnny Willemsen Remedy IT Postbus 101 2650 AC Berkel en Rodenrijs The Netherlands www.theaceorb.nl / www.remedy.nl > TAO VERSION: 1.4.1 > ACE VERSION: 5.4.1 > > HOST MACHINE and OPERATING SYSTEM: > Dell PowerEdge750, Slackware Linux 10.1.0 > > TARGET MACHINE and OPERATING SYSTEM, if different from HOST: > COMPILER NAME AND VERSION (AND PATCHLEVEL): > gcc version 3.3.4 > > AREA/CLASS/EXAMPLE AFFECTED: > CosConcurrencyControl.idl failed due to tao_idl core dump > > DOES THE PROBLEM AFFECT: > COMPILATION? Yes > $ACE_ROOT/ace/config.h and > $ACE_ROOT/include/makeinclude/platform_macros.GNU > included below > LINKING? No > EXECUTION? No > OTHER (please specify)? No > > SYNOPSIS: > TAO fails to build because tao_...

Re: [ace-users] [tao-users] ACE/TAO ported to Sun Studio 12
Hi, > is this change included in the official release of ACT/TAO (and if yes > since which version)? This change will be part of the upcoming x.6.2 version. I am creating x.6.2 at this moment, when everything runs fine it will be available at the end of today. Regards, Johnny Willemsen Remedy IT Postbus 101 2650 AC Berkel en Rodenrijs The Netherlands www.theaceorb.nl / www.remedy.nl *** Integrated compile and test statistics see http://scoreboard.theaceorb.nl *** *** Commercial service and support for ACE/TAO/CIAO *** *** See http://www.theaceorb.nl/en/support.html *** ...

[tao-users] Re: [ace-users] timestamps incorrect in ACE+TAO .tar.gz
Hi > It has just come to my attention that there are many files in the > ACE+TAO .tar.gz file with timestamps showing '1970-01-05'. Obviously > this is wrong and is the only reason why my packages have been > rejected from Debian ("file(s) with a time stamp too ancient"). > > Is there a possibility that this will be fixed. Or should I just > 'touch' all the problematic files? Could you please run a touch on them? I don't know how this happened. Strange. Opening and fiddling with the distribution would make quite a few things goofy! If you have problems doing it, please let me know. Thanks Bala On Wednesday 04 February 2004 21:23, Balachandran Natarajan wrote: > Could you please run a touch on them? I don't know how this > happened. Strange. Opening and fiddling with the distribution would > make quite a few things goofy! > > If you have problems doing it, please let me know. I used the command: touch `find . -mtime +3500` and it did the job. Konstantinos Hi, Host Machine and Operating System : Intel Pentium III, 860MHZ , 512MB RAM, Windows 2000 Professional(5.0, Build 2195) Service pack 3 Borland C++ Builder Professional Version 6.0 For use with Borland C++ Builder Professional Version 6.0 I downloaded the ACE-5.4+TAO-1.4 ( not the Beta Version) from the website. Followed the instructions on installing ACE........Installed fine Followed th...

Re: [tao-users] Communication between different TAO versions #2
Hi Kerry, Thanks for using the PRF. >> TAO VERSION: 1.4.4 and 1.4 >> ACE VERSION: 5.4.4 and 5.4 >> >> HOST MACHINE and OPERATING SYSTEM: >> Pentium 4, Windows XP Pro SP1 >> >> TARGET MACHINE and OPERATING SYSTEM, if different from HOST: >> dito >> >> COMPILER NAME AND VERSION (AND PATCHLEVEL): >> MSVC++ 7.1 >> >> CONTENTS OF $ACE_ROOT/ace/config.h [if you use a link to a platform- >> specific file, simply state which one]: >> #define ACE_HAS_STANDARD_CPP_LIBRARY 1 >> #include "ace/config-win32.h" >> >> CONTENTS OF $ACE_ROOT/include/makeinclude/platform_macros.GNU (unless >> this isn't used in this case, e.g., with Microsoft Visual C++): >> >> CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features >> (used by MPC when you generate your own makefiles): >> >> AREA/CLASS/EXAMPLE AFFECTED: >> CORBA calls between hosts using different versions of TAO >> >> DOES THE PROBLEM AFFECT: >> COMPILATION? >> no >> LINKING? >> no >> EXECUTION? >> yes >> OTHER (please specify)? >> no >> >> SYNOPSIS: >&g...

[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 > > ...

[ace-users] Different behaviour with release and debug versions of ACE+TAO
ACE VERSION: 5.3 Tao Version is 1.3 HOST MACHINE and OPERATING SYSTEM: Pentium IV, Windows 2000 Professional TARGET MACHINE and OPERATING SYSTEM, if different from HOST: COMPILER NAME AND VERSION (AND PATCHLEVEL): THE $ACE_ROOT/ace/config.h FILE Same as what is there in the install documentation. 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++)]: CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features (used by MPC when you generate your own makefiles): AREA/CLASS/EXAMPLE AFFECTED: [What example failed? What module failed to compile?] DOES THE PROBLEM AFFECT: COMPILATION? LINKING? On Unix systems, did you run make realclean first? EXECUTION? OTHER (please specify)? [Please indicate whether ACE, your application, or both are affected.] SYNOPSIS: In debug version of ACE+TAO, application breaks execution when run in debug= ger With release version it seems to be stuck some where. DESCRIPTION: My project seems to have some weired behaviour under the following conditio= ns 1. ACE_TAO built in debug mode and Project in 'release mode with debug supp= ort'. All EXEs break execution on memory operations when run in debugger. It is s= howing &...

RE: [ace-users] ACE_Process_Mutex on Win XP and Different Users #2
Doug, There is precedent for passing an LPSECURITY_ATTRIBUTES in ACE (e.g. ACE_Mem_Map, ACE_MMAP_Memory_Pool_Options, ACE_FIFO, ACE_Filecache_Object). One work around I listed in the PRF is to define ACE_DEFINES_DEFAULT_WIN32_SECURITY_ATTRIBUTES in the config.h when compiling ACE. The lower level calls (e.g. ACE_OS::mutex_init, etc) could be used instead of ACE_Process_Mutex or ACE_Mutext. If LPSECURITY_ATTRIBUTES, is NULL always pass a default LPSECURITY_ATTRIBUTES to CreateMutexA or CreateMutexW. So if an additional parameter (LPSECURITY_ATTRIBUTES sa = 0) is not wanted in the Mutex contstructors, then it seems the best workaround is to pass a default LPSECURITY_ATTRIBUTES if the input one is NULL. Paul -----Original Message----- From: Douglas C. Schmidt [mailto:schmidt@cse.wustl.edu] Sent: Thursday, March 09, 2006 2:33 PM To: ace-users@cs.wustl.edu; Eccles, Paul Subject: Re: [ace-users] ACE_Process_Mutex on Win XP and Different Users Hi Paul, Thanks for using the PRF. >> ACE VERSION: 5.3 (and 5.5? >> >> HOST MACHINE and OPERATING SYSTEM: Windows XP and winsock 2.0 >> >> TARGET MACHINE and OPERATING SYSTEM, if different from HOST: >> COMPILER NAME AND VERSION (AND PATCHLEVEL): >> >> THE $ACE_ROOT/ace/config.h FILE [if you use a link to a platform- >> specific file, simply state which one]: config-win32.h >> >> THE $A...

Re: [ace-users] ACE_Process_Mutex on Win XP and Different Users #2
Hi Paul, >> There is precedent for passing an LPSECURITY_ATTRIBUTES in ACE (e.g. >> ACE_Mem_Map, ACE_MMAP_Memory_Pool_Options, ACE_FIFO, >> ACE_Filecache_Object). Ok, fair enough. >> One work around I listed in the PRF is to define >> ACE_DEFINES_DEFAULT_WIN32_SECURITY_ATTRIBUTES in the config.h when >> compiling ACE. The lower level calls (e.g. ACE_OS::mutex_init, etc) >> could be used instead of ACE_Process_Mutex or ACE_Mutext. If >> LPSECURITY_ATTRIBUTES, is NULL always pass a default >> LPSECURITY_ATTRIBUTES to CreateMutexA or CreateMutexW. >> >> So if an additional parameter (LPSECURITY_ATTRIBUTES sa = 0) is not >> wanted in the Mutex contstructors, then it seems the best >> workaround is to pass a default LPSECURITY_ATTRIBUTES if the input >> one is NULL. As long as there is precedent for putting LPSECURITY_ATTRIBUTES sa = 0 at the end of some ACE constructors then this seems like a reasonable thing to do for the ACE_Process_Mutex stuff. Could you please send us the patches for this relative to ACE 5.5? We won't be able to add it to ACE until after the x.5.1 beta goes out. 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, Na...

RE: [ace-users] ACE_Process_Mutex on Win XP and Different Users #2
Doug, I will but it won't be until after 31 March. Paul -----Original Message----- From: Douglas C. Schmidt [mailto:schmidt@cse.wustl.edu] Sent: Friday, March 10, 2006 9:48 AM To: ace-users@cs.wustl.edu; Eccles, Paul Subject: Re: [ace-users] ACE_Process_Mutex on Win XP and Different Users Hi Paul, >> There is precedent for passing an LPSECURITY_ATTRIBUTES in ACE (e.g. >> ACE_Mem_Map, ACE_MMAP_Memory_Pool_Options, ACE_FIFO, >> ACE_Filecache_Object). Ok, fair enough. >> One work around I listed in the PRF is to define >> ACE_DEFINES_DEFAULT_WIN32_SECURITY_ATTRIBUTES in the config.h when >> compiling ACE. The lower level calls (e.g. ACE_OS::mutex_init, etc) >> could be used instead of ACE_Process_Mutex or ACE_Mutext. If >> LPSECURITY_ATTRIBUTES, is NULL always pass a default >> LPSECURITY_ATTRIBUTES to CreateMutexA or CreateMutexW. >> >> So if an additional parameter (LPSECURITY_ATTRIBUTES sa = 0) is not >> wanted in the Mutex contstructors, then it seems the best workaround >> is to pass a default LPSECURITY_ATTRIBUTES if the input one is NULL. As long as there is precedent for putting LPSECURITY_ATTRIBUTES sa = 0 at the end of some ACE constructors then this seems like a reasonable thing to do for the ACE_Process_Mutex stuff. Could you please send us the patches for this relative to ACE 5.5? We won't be able to add it to ACE until afte...

Re: [tao-users] OmniORB
Hi Zbigniew, > recently we have compared latest versions of OmniORB and TAO by > running a simple client/server example. It's not clear what you mean by "later versions," so please make sure you fill out the appropriate problem report form (PRF), which is in $ACE_ROOT/PROBLEM-REPORT-FORM $TAO_ROOT/PROBLEM-REPORT-FORM when asking reporting anything about ACE+TAO since otherwise we have to "guess" what version/platform/compiler/options you've using, which is very error-prone and slows down our responsiveness. The forthcoming TAO 1.4 release (due out at the end of December 2003) has been optimized so that it should run faster than versions based on the TAO 1.3 baseline. I recommend you check with Bala <bala@dre.vanderbilt.edu> for more information on what sorts of improvements you can expect. Thanks, Doug ...

[tao-users] RE: [ace-users] Re: How to use Any>>=OctetSeq in TAO 1.3.6?
Hi, I just had a quick look. It looks to me the that TAO_Export macro is missing from OctetSeqA.h for the operators. Also the include of pre/post files is missing. 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. Bala, shouldn't we add pre/post includes and TAO_Export to the archive files? Regards, Johnny Willemsen Remedy IT Leeghwaterstraat 25 2811 DT Reeuwijk 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 > Balachandran Natarajan > Sent: Friday, January 09, 2004 6:09 PM > To: Douglas C. Schmidt > Cc: ace-users@cs.wustl.edu > Subject: [ace-users] Re: How to use Any>>=OctetSeq in TAO 1.3.6? > > Hi > > > >> while checking how an upgrade from TAO 1.2.4 to 1.3.6 affects my > > >> programs I found that there were changes to the CORBA::OctetSeq, > > >> that prevents the operator>>= for CORBA::Any to CORBA::OctetSeq > > >> from working. > > >> > > >> The needed declarations now are in OctetSeqA.h/.cpp. > When including > > >> OctetSeqA.h into my files, compiling works but the > linker is missing > > >> the function implementation. > > Grr.. Coudl you please see whether OctetSeqA.obj i...

RE: [ace-users] ACE_RW_Process_Mutex between two Linux processes under different user ids.
You could add an optional mode parameter to the constructor that defaults to the current behavior. -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 Marek Brudka > Sent: Wednesday, June 02, 2004 3:59 PM > To: Bae-Sik Chon > Cc: ace-users > Subject: Re: [ace-users] ACE_RW_Process_Mutex between two > Linux processes under different user ids. > > > On Wednesday 02 of June 2004 19:04, Bae-Sik Chon wrote: > > I am trying to use ACE_RW_Process_Mutex to control > > access of shared resources between two Linux > > processes. The default behavior of > > ACE_RW_Process_Mutex is RW only to the owner. So if > > those two processes run under same user id, it works > > fine but when they run under different user ids, it > > has problem. One process would have permission issue. > > Is there a simple way to create the permission for > > ACE_RW_Process_Mutex to be RW for both user and group? > I''m afraid that the interface of ACE_RW_Process_Mutex does not > allow to set permissions directly. I suppose it should be changed, > however I've...

[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 ...

[tao-users] Re: [ace-users] Re: Query
Hi Bill, Thanks very much for your email. Please make sure to send all questions related to TAO or ACE to the ACE mailing list or ACE+TAO newsgroup, rather than to me directly. > Actually this email is very appropriate. We at The Weather Channel > are attempting to build ACE+TAO version 5.4 on an AMD opteron using > g++ 3.3.3. > > The only errors we have seen thus far and in a component that we don't really > intend on using is: This problem was fixed before the x.4.1 release, so if you download it from http://deuce.doc.wustl.edu/Download.html you'll get a working version on 64-bit platforms. Thanks, Doug > RTCosScheduling/RTCosScheduling_PCP_Manager.cpp: In member function ` > TAO::CosSchedulingLockNode* TAO::CosSchedulingLockNode::next()': > RTCosScheduling/RTCosScheduling_PCP_Manager.cpp:36: error: reinterpret_cast > from `TAO::CosSchedulingLockNode*' to `int' loses precision > RTCosScheduling/RTCosScheduling_PCP_Manager.cpp: In member function `void > TAO::CosSchedulingLockNode::next(TAO::CosSchedulingLockNode*)': > RTCosScheduling/RTCosScheduling_PCP_Manager.cpp:53: error: reinterpret_cast > from `TAO::CosSchedulingLockNode*' to `int' loses precision > RTCosScheduling/RTCosScheduling_PCP_Manager.cpp:54: error: reinterpret_cast > from `TAO::CosSchedulingLockNode*' to `int' loses precision > RTCosScheduling/RTCosScheduling_PCP_Manager.cpp: In constr...

[ace-users] Re: [tao-users] TAO Tutorial
Hi Matt, Thanks for your email. Please send all correspondence to the TAO users list rather than me, however. > TAO Version 1.3a BTW, since you're using OCI's version of TAO please send your questions to taosupport@ociweb.com. > Sun Solaris 8 > GCC 3.4.2 > (I will be sure to include the PRF next time) Great! > As you see, I have TAO v1.3a. Would that be the reason for the *.i > files opposed to *.inl files? Yes, indeed. Take care, Doug ...

RE: [ace-users] Re: ACE-TAO subesetting
Thanks Don, Yes I do intend to follow up on the material you have alluded to in the mail. And I stumbled upon your contact during some initial reading on this subject. <snip><http://www.cs.wustl.edu/~schmidt/ACE_wrappers/docs/ACE-subsets.html> Anyone interested in contributing time or funding to these efforts should please contact d.hinton@vanderbilt.edu <snip> /Gaurav -----Original Message----- From: Don Hinton [mailto:don.hinton@vanderbilt.edu] Sent: Friday, November 19, 2004 10:42 AM To: Gaurav Khanna Cc: ace-users@cs.wustl.edu Subject: [ace-users] Re: ACE-TAO subesetting Hi Gaurav: > How do i plug into the latest state of efforts on ACE/TAO subsetting?. > I am trying to investigate opportunities of footprint/memory usage > reduction in typical use. Thanks very much for your email. Please make sure to send all questions related to ACE or TAO to the ACE mailing list or ACE+TAO newsgroup, rather than to me directly. See http://www.cs.wustl.edu/~schmidt/ACE-mail.html for more info on how to access these resources. For the latest information on ACE+TAO subsetting, please see http://www.cs.wustl.edu/~schmidt/ACE_wrappers/docs/ACE-subsets.html If you'd like to contribute to - or sponsor - efforts on ACE+TAO subsetting please send email to Doug Schmidt <d.schmidt@vanderbilt.edu>. Thanks very much, Don ...

Same user name - different user
From:Dave Comcast (dgattis@comcast.net) Subject:Same user name - different user - different domain Newsgroups:comp.mail.sendmail Date:2002-12-17 14:54:30 PST Same user name - different user - different domain. How is this done? Example: user "A" is jblow@domain1.com user "B" is jblow@domain2.com They have the same user names but use different domains. Whats the best way to handle this? Currently, an alias is all inclusive to any domain I handle. If I create an alias that jb = jblow, it covers all domains. How do you separate them? Help! Thanks, Dave http://r...

Web resources about - Re: [tao-users] Reactive/Concurrency: Difference between different ORBReactorType - comp.soft-sys.ace

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