[omniORB] restarting ORB & specifying endpoints
Daniel Greenblatt
dan at cgl.ucsf.edu
Thu Nov 20 11:21:28 GMT 2003
Hello all,
I'm using omniORB and omnipy to communicate over the net, and thus have
been experiencing some firewall problems. To get around this, I've decided to
add an interface to my application taht will allow the user to specify
what port and IP to listen/publish, and pass this into omniORB via the
'endpoint' family of parameters...
Basically, my application tries to connect to a CORBA server on some
other host, and if it
can't because of certain issues, I destroy the ORB (orb.shutdown(),
orb.destroy()), and let the user pick a new port and IP to publish in the
IORs.
In some testing, I've tried starting up the ORB with this set of
parameters:
['Node.py', '-ORBgiopMaxMsgSize', '26214400',
'-ORBclientCallTimeOutPeriod', '30000', '-ORBtraceLevel', '25',
'-ORBtraceInvocations', '1', '-ORBendPointNoListen',
'giop:tcp:169.230.21.60:4111', '-ORBendPointNoPublish', 'giop:tcp::4111']
and everything works OK. Here is the relevant debug output (tracelevel
25)...
omniORB: endPointNoListen = giop:tcp:169.230.21.60:4111
omniORB: endPointNoPublish = giop:tcp::4111
...
omniORB: Initialising incoming endpoints.
omniORB: Bind to address 0.0.0.0.
omniORB: Starting serving incoming endpoints.
Everything works great.
Then I shut down the ORB:
self.orb.shutdown(0)
self.orb.destroy()
and attempt to restart it, using the same command line parameters
This time it fails. I get a CORBA.INITIALIZE error when I try to resolve
the POA:
self.poa = self.orb.resolve_initial_references('RootPOA')
from the trace output from the second time around, it looks like it is
caching the endpoint from the first time!! :
omniORB: endPointNoListen = giop:tcp:169.230.21.60:4111
omniORB: endPointNoListen = giop:tcp:169.230.21.60:4111
omniORB: endPointNoPublish = giop:tcp::4111
omniORB: endPointNoPublish = giop:tcp::4111
omniORB: endPointPublishAllIFs = 0
omniORB: Initialising incoming endpoints.
omniORB: Bind to address 0.0.0.0.
omniORB: Bind to address 0.0.0.0.
omniORB: Error: Unable to create an endpoint of this description:
giop:tcp::4111
omniORB: throw INITIALIZE from objectAdapter.cc:241
(NO,INITIALIZE_TransportError)
Note that when I don't specify any endpoint information to ORB_init, it
works fine the second time.
Am I forgetting to do something?
Thank you,
Dan Greenblatt
----------------------------
Daniel Greenblatt
UCSF Computer Graphics Lab
dan at cgl.ucsf.edu
On Thu, 20 Nov 2003 omniorb-list-request at omniorb-support.com wrote:
> Date: Thu, 20 Nov 2003 12:00:02 +0000
> From: omniorb-list-request at omniorb-support.com
> Reply-To: omniorb-list at omniorb-support.com
> To: omniorb-list at omniorb-support.com
> Subject: omniORB-list Digest, Vol 7, Issue 24
>
> Send omniORB-list mailing list submissions to
> omniorb-list at omniorb-support.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list
> or, via email, send a message with subject or body 'help' to
> omniorb-list-request at omniorb-support.com
>
> You can reach the person managing the list at
> omniorb-list-owner at omniorb-support.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of omniORB-list digest..."
>
>
> Today's Topics:
>
> 1. New RPM spec files. Was re: [omniORB] request for dropping
> site-packages/PortableServer* from omniorbpy (Duncan Grisby)
> 2. Exception while sending an octet sequence (Ali Reza)
> 3. Re: Exception while sending an octet sequence
> (baileyk at schneider.com)
> 4. Re: additional omniidl command-line option (Duncan Grisby)
> 5. omniORB 4.02 binaries built for Win32 with Visual C++ 5 (Perin)
> 6. omniORB 4.02 for Win32 with Visual C++ 5 build error (Perin)
> 7. Re: New RPM spec files. Was re: [omniORB] request for
> dropping site-packages/PortableServer* from omniorbpy
> (Thomas Lockhart)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 19 Nov 2003 15:16:25 +0000
> From: Duncan Grisby <duncan at grisby.org>
> Subject: New RPM spec files. Was re: [omniORB] request for dropping
> site-packages/PortableServer* from omniorbpy
> To: Thomas Lockhart <lockhart at fourpalms.org>
> Cc: omniorb-list at omniorb-support.com
> Message-ID: <200311191516.hAJFGPU21317 at grisby.dyndns.org>
>
> On Monday 17 November, Thomas Lockhart wrote:
>
> > OK, what should that top-level package be called? I'm willing to do the
> > packaging, but need suggestions on a name. Current packages are
> >
> > omniORBpy
> > omniORBpy-devel
> > omniORBpy-doc
> >
> > The top-level namespace involves OMG compliance; could it be called
> >
> > omniORBpy-omg or omniORBpy-standard or ????
>
> I've been updating the spec files in omniORB in preparation for the
> omniORB 4.0.3 and omniORBpy 2.3 releases, so I did it. I called the
> new package omniORBpy-standard.
>
> Can you check that the spec file in CVS (and snapshot tarballs) does
> what you expect, and that it's OK in all other respects? I intend to
> do the releases on Friday, so it would be great if you could check
> before then.
>
> Cheers,
>
> Duncan.
>
> --
> -- Duncan Grisby --
> -- duncan at grisby.org --
> -- http://www.grisby.org --
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 19 Nov 2003 20:45:00 +0530
> From: "Ali Reza" <A.Reza at zensar.com>
> Subject: [omniORB] Exception while sending an octet sequence
> To: "omniORB Submissions (E-mail)" <omniorb-list at omniorb-support.com>
> Message-ID:
> <02138659CA66B34F9D13E69B6F66B0A0873FEF at zenmail1.ind.zensar.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I have encountered the following exception while trying to use an octet sequence....
>
> CORBA System ExceptionIDL:omg.org/CORBA/UNKNOWN:1.0
> Completion status 2
> Minor 1330446337
> Meaningful name for minor code UNKNOWN_UserException
>
> My servant code is...
>
> BinaryFile* TS::BinaryFileExchange_impl::fetch(const char* file_name)
> {
> int file_handle = open(file_name,_A_RDONLY);
> struct stat stat_values;
> fstat(file_handle,&stat_values);
> CORBA::Octet *image_oct_buf;
> image_oct_buf = new CORBA::Octet(stat_values.st_size);
> BinaryFile *image_seq = new BinaryFile(stat_values.st_size);
> image_seq->length(stat_values.st_size);
>
>
> read(file_handle,image_oct_buf,stat_values.st_size);
> for (int i = 0; i < stat_values.st_size ; ++i) {
> *(image_seq + i) = *(image_oct_buf + i);
> }
> delete [] image_oct_buf;
> close(file_handle);
>
> return image_seq
> }
>
> // My IDL is ...
> typedef sequence<octet> BinaryFile;
> interface BinaryFileExchange {
> void send(in BinaryFile f, in string file_name);
> BinaryFile fetch(in string file_name);
> };
>
> Could somebody explain whats happening ? Where things are going wrong ??
> on cout << "Length of image_seq" << image_seq->length() << endl;
> I get a proper sized sequence i.e. the size of the number of bytes of ,y gif file.
>
> Thx./Ali
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 19 Nov 2003 10:28:01 -0600
> From: baileyk at schneider.com
> Subject: Re: [omniORB] Exception while sending an octet sequence
> To: "Ali Reza" <A.Reza at zensar.com>
> Cc: "omniORB Submissions \(E-mail\)"
> <omniorb-list at omniorb-support.com>
> Message-ID: <OFBDD85FC4.9FEB1761-ON86256DE3.00581EAF at schneider.com>
> Content-Type: text/plain; charset=us-ascii
>
>
> Note some fixes on these lines
>
> image_oct_buf = new CORBA::Octet[stat_values.st_size]; // you need square
> brackets
> BinaryFile_var image_seq = new BinaryFile(stat_values.st_size); // _var
> is safer
> image_seq->length( stat_values.st_size ); // still need to set the length
>
> ...
> image_seq[i] = *(image_oct_buf + i); // _var type has convenient
> operator[]
>
> ...
> return image_seq._retn();
>
> Hope this helps.
>
> Kendall
>
>
>
>
>
> "Ali Reza"
> <A.Reza at zensar.com> To: "omniORB Submissions (E-mail)"
> Sent by: <omniorb-list at omniorb-support.com>
> omniorb-list-bounces at omniorb- cc:
> support.com Fax to:
> Subject: [omniORB] Exception while sending an octet sequence
>
> 11/19/2003 09:15 AM
>
>
>
>
>
>
> I have encountered the following exception while trying to use an octet
> sequence....
>
> CORBA System ExceptionIDL:omg.org/CORBA/UNKNOWN:1.0
> Completion status 2
> Minor 1330446337
> Meaningful name for minor code UNKNOWN_UserException
>
> My servant code is...
>
> BinaryFile* TS::BinaryFileExchange_impl::fetch(const char* file_name)
> {
> int file_handle = open(file_name,_A_RDONLY);
> struct stat stat_values;
> fstat(file_handle,&stat_values);
> CORBA::Octet *image_oct_buf;
> image_oct_buf = new CORBA::Octet(stat_values.st_size);
> BinaryFile *image_seq = new BinaryFile(stat_values.st_size);
> image_seq->length(stat_values.st_size);
>
>
> read(file_handle,image_oct_buf,stat_values.st_size);
> for (int i = 0; i < stat_values.st_size ; ++i) {
> *(image_seq + i) = *(image_oct_buf + i);
> }
> delete [] image_oct_buf;
> close(file_handle);
>
> return image_seq
> }
>
> // My IDL is ...
> typedef sequence<octet> BinaryFile;
> interface BinaryFileExchange {
> void send(in BinaryFile f, in string file_name);
> BinaryFile fetch(in string file_name);
> };
>
> Could somebody explain whats happening ? Where things are going wrong ??
> on cout << "Length of image_seq" << image_seq->length() << endl;
> I get a proper sized sequence i.e. the size of the number of bytes of ,y
> gif file.
>
> Thx./Ali
>
> _______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list
>
>
>
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 19 Nov 2003 17:03:18 +0000
> From: Duncan Grisby <duncan at grisby.org>
> Subject: Re: [omniORB] additional omniidl command-line option
> To: Rene Jager <renej.frog at yucom.be>
> Cc: "omniORB Submissions \(E-mail\)"
> <omniorb-list at omniorb-support.com>
> Message-ID: <200311191703.hAJH3JS22000 at grisby.dyndns.org>
>
> On Friday 14 November, Rene Jager wrote:
>
> > This patch add an extra option extern to the Python back-end to set
> > packages for generated *_idl.py files/modules. Example:
> > omniidl -bpython -Wbstubs=Test_stubs -Wbextern=CosNaming -Wbextern=MyFile:mystubs Test.idl
>
> Thanks for the good idea. Your patch didn't seem to quite work, in
> that it didn't correctly set the name in omniORB.openModule(). I've
> tweaked it a bit and checked it in.
>
> Cheers,
>
> Duncan.
>
> --
> -- Duncan Grisby --
> -- duncan at grisby.org --
> -- http://www.grisby.org --
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 19 Nov 2003 17:52:45 -0300
> From: Perin <Perin at drive.com.br>
> Subject: [omniORB] omniORB 4.02 binaries built for Win32 with Visual
> C++ 5
> To: "'omniorb-list at omniorb-support.com'"
> <omniorb-list at omniorb-support.com>
> Message-ID:
> <8042FF241A25D51186F90050DABD881401B86AAE at pc197.drive.com.br>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> Hi,
>
> Could someone give me some pointer to a Site where I can
> download the omniORB 4.02 binaries built for Win32 with
> Visual C++ 5?
>
> Thanks in Advance
>
> Marcello Perin
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 19 Nov 2003 18:07:24 -0300
> From: Perin <Perin at drive.com.br>
> Subject: [omniORB] omniORB 4.02 for Win32 with Visual C++ 5 build
> error
> To: "'omniorb-list at omniorb-support.com'"
> <omniorb-list at omniorb-support.com>
> Message-ID:
> <8042FF241A25D51186F90050DABD881401B86AB0 at pc197.drive.com.br>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> Hi,
>
> Following the steps listed in the README.win32 file to build
> omniORB 4.02 for Win32 with Visual C++ 5, I receive the
> following error:
>
>
> making export in src/lib/omniORB/orbcore...
> <...>
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 11.00.7022 for
> 80x86
> Copyright (C) Microsoft Corp 1984-1997. All rights reserved.
>
> anonObject.cc
> ..\..\..\..\include\omniORB4/templatedecls.h(497) : error C2039:
> 'marshalObjRef'
> : is not a member of 'DynAny_Helper'
> ..\..\..\..\include\omniORB4/templatedecls.h(497) : error C2065:
> 'marshalObjRef'
> : undeclared identifier
> ..\..\..\..\include\omniORB4/templatedecls.h(501) : error C2039:
> 'unmarshalObjRe
> f' : is not a member of 'DynAny_Helper'
> ..\..\..\..\include\omniORB4/templatedecls.h(501) : error C2065:
> 'unmarshalObjRe
> f' : undeclared identifier
> ..\..\..\..\include\omniORB4/templatedecls.h(501) : error C2440:
> 'initializing'
> : cannot convert from 'int' to 'class DynamicAny::DynAny *'
>
> Conversion from
> integral type to pointer type requires reinterpret_cast, C-style cast or
> functi
> on-style cast
> make[3]: *** [static/anonObject.o] Error 2
> make[3]: Leaving directory
> `/cygdrive/c/omniORB-4.0.2/src/lib/omniORB/orbcore'
> make[2]: *** [export] Error 2
> make[2]: Leaving directory `/cygdrive/c/omniORB-4.0.2/src/lib/omniORB'
> make[1]: *** [export] Error 2
> make[1]: Leaving directory `/cygdrive/c/omniORB-4.0.2/src/lib'
> make: *** [export] Error 2
>
>
> Could someone give me some clue of what is happening?
>
> Thanks in Advance
>
> Marcello Perin
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 19 Nov 2003 13:53:04 -0800
> From: Thomas Lockhart <lockhart at fourpalms.org>
> Subject: Re: New RPM spec files. Was re: [omniORB] request for
> dropping site-packages/PortableServer* from omniorbpy
> To: Duncan Grisby <duncan at grisby.org>
> Cc: omniorb-list at omniorb-support.com
> Message-ID: <3FBBE640.1040408 at fourpalms.org>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> ...
> > Can you check that the spec file in CVS (and snapshot tarballs) does
> > what you expect, and that it's OK in all other respects? I intend to
> > do the releases on Friday, so it would be great if you could check
> > before then.
>
> Seems to be OK. I made the minimum changes to get the tarball and
> directory names right in the spec file, and the packages built and
> installed cleanly. A simple test case ran correctly.
>
> These pre-release SRPMs are posted at
> http://www.fourpalms.org/pub/omniORB/devel/
> but beware that they are labeled as though they are 4.0.3/2.3.
>
> I have one design issue or question for omniORBpy-standard: it contains
> some .py (and .pyc) files exposing some of omniORB at the top level of
> the namespace. It also contain omniORB.pth, which exposes (only)
> site-packages/omniORB/COS to the top level of the namespace.
>
> In principle, we could probably have all files contained in
> site-packages/omniORB exposed via omniORB.pth, which allows us to leave
> out the remaining top level files altogether. Seems cleaner to me,
> *except* that python only respects these .pth files when they are
> underneath the default python library installation area. Which they will
> likely be for RPMs, but someone *could* rebuild them to install into
> another area which would then not be able to use the .pth file at all.
>
> - Tom
>
>
>
> ------------------------------
>
> _______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list
>
>
> End of omniORB-list Digest, Vol 7, Issue 24
> *******************************************
>
More information about the omniORB-list
mailing list