[omniORB] How to get file descriptor from a CORBA request?

[Tuyen Chau]

I'm porting an Orbix application to omniORB. In this Orbix application,
we use the CORBA::Environment object passed in each CORBA request to
obtain the client's file descriptor. This file descriptor tells us
which client makes the request so we can maintain information on a per
client basis. Is there any way to get that information from omniORB?

Best Regards,
Tuyen

[Duncan Grisby]

On Tuesday 12 September, Tuyen Chau wrote:

> I'm porting an Orbix application to omniORB. In this Orbix
> application, we use the CORBA::Environment object passed in each CORBA
> request to obtain the client's file descriptor. This file descriptor
> tells us which client makes the request so we can maintain information
> on a per client basis. Is there any way to get that information from
> omniORB?

No, you can't get the file descriptor. And anyway, omniORB clients can
open multiple concurrent connections, and close idle connections, so the
file descriptor is not a useful indication of which client is which.
With server-side interceptors, you can access internal connection state,
and try to construct some idea of which client is which based on IP
address, but by far the simplest thing to do is for clients to identify
themselves in the calls.

Cheers,

Duncan.

--
-- Duncan Grisby --
-- ***@grisby.org --
-- http://www.grisby.org --

[Sander Steffann]

Hi,

> No, you can't get the file descriptor. And anyway, omniORB clients can
> open multiple concurrent connections, and close idle connections, so the
> file descriptor is not a useful indication of which client is which.
> With server-side interceptors, you can access internal connection state,
> and try to construct some idea of which client is which based on IP
> address, but by far the simplest thing to do is for clients to identify
> themselves in the calls.

You can add/read a service context in interceptors. You can (for example)
put an id or username/password in there without modifying the IDL of your
interfaces. This is what we do in our application. For security an SSL
connection might be a good idea.

Good luck,
Sander.

[Tuyen Chau]

Hi Sander,

Thanks for your reply. Can you elaborate on this? I'm interested in
your solution.

Are you saying that the client should use a clientSendRequest
interceptor to add a service context, and the server should use a
serverReceiveRequest interceptor to read the context? The part that I
don't understand is that if I'm in a CORBA request, say,

Account BankManager_i::openAccount(String name) {
}

How do I get the service context to figure out which client this is? Do
I need to somehow store the service context somewhere in the servant
object first when I'm in the interceptor, and then when I'm in the CORBA
request, I'll just read the context back from the object?

Thanks in advance for any help that you can provide,
Tuyen

Sander Steffann wrote:
> Hi,
>
>> No, you can't get the file descriptor. And anyway, omniORB clients can
>> open multiple concurrent connections, and close idle connections, so the
>> file descriptor is not a useful indication of which client is which.
>> With server-side interceptors, you can access internal connection state,
>> and try to construct some idea of which client is which based on IP
>> address, but by far the simplest thing to do is for clients to identify
>> themselves in the calls.
>
> You can add/read a service context in interceptors. You can (for
> example) put an id or username/password in there without modifying the
> IDL of your interfaces. This is what we do in our application. For
> security an SSL connection might be a good idea.
>
> Good luck,
> Sander.

[Sander Steffann]

Hi Tuyen,

> Thanks for your reply. Can you elaborate on this? I'm interested in your
> solution.
>
> Are you saying that the client should use a clientSendRequest interceptor
> to add a service context, and the server should use a serverReceiveRequest
> interceptor to read the context?

Exactly.

> The part that I don't understand is that if I'm in a CORBA request, say,
>
> Account BankManager_i::openAccount(String name) {
> }
>
> How do I get the service context to figure out which client this is? Do I
> need to somehow store the service context somewhere in the servant object
> first when I'm in the interceptor, and then when I'm in the CORBA request,
> I'll just read the context back from the object?

I store the data in separate thread-local storage instead of in the servant,
but that's basically it :) Works great for us. In the future I want to use
CSIv2 contexts instead of my home-made ones, but that also requires some
work on the IOR reading/writing (part of the data needed for the context is
in the IOR). I'll let you (and the list) know when/if I manage to get
something working :)

Sander

PS: I do the home-made context stuff in Python instead of in C++, but I
don't think it should make a difference

[Duncan Grisby]

On Monday 25 September, Tuyen Chau wrote:

> Are you saying that the client should use a clientSendRequest
> interceptor to add a service context, and the server should use a
> serverReceiveRequest interceptor to read the context? The part that I
> don't understand is that if I'm in a CORBA request, say,
>
> Account BankManager_i::openAccount(String name) {
> }
>
> How do I get the service context to figure out which client this is?
> Do I need to somehow store the service context somewhere in the
> servant object first when I'm in the interceptor, and then when I'm in
> the CORBA request, I'll just read the context back from the object?

The normal approach is to put something in per-thread state. You don't
want to put it on the servant object because multiple clients could call
a single servant concurrently.

Cheers,

Duncan.

--
-- Duncan Grisby --
-- ***@grisby.org --
-- http://www.grisby.org --

[Tuyen Chau]

Duncan Grisby wrote:
> The normal approach is to put something in per-thread state. You don't
> want to put it on the servant object because multiple clients could call
> a single servant concurrently.
>
> Cheers,
>
> Duncan
This brings up another problem for us that we didn't anticipate. Our
implementation unfortunately is not thread safe. Is there anyway we can
force a single thread model in omniORB? It will be a big job for us to
make our code thread safe.

Thanks for your response,
Tuyen

[Alberto Casado Martín]

Hello,

Is there anyway we can force a single thread model in omniORB? It will be
a big job for us to
make our code thread safe.

Yes, you can do that configuring your POA in SINGLE_THREAD_MODEL.


12 CHAPTER 2. THE BASICS
>
>
Multi-threading
> As omniORB is fully multithreaded, multiple threads may perform the same
> upcall to your implementation concurrently. It is up to your
> implementation
> to synchronise the threads' accesses to shared data. In our simple
> example,
> we have no shared data to protect so no thread synchronisation is
> necessary.
> Alternatively, you can create a POA which has the SINGLE_THREAD_MODEL
> Thread Policy. This guarantees that all calls to that POA are processed
> sequentially.
>


Cheers.
Alberto.

2006/9/29, Tuyen Chau <***@verano.com>:
>
> Duncan Grisby wrote:
> > The normal approach is to put something in per-thread state. You don't
> > want to put it on the servant object because multiple clients could call
> > a single servant concurrently.
> >
> > Cheers,
> >
> > Duncan
> This brings up another problem for us that we didn't anticipate. Our
> implementation unfortunately is not thread safe. Is there anyway we can
> force a single thread model in omniORB? It will be a big job for us to
> make our code thread safe.
>
> Thanks for your response,
> Tuyen
>
> _______________________________________________
> omniORB-list mailing list
> omniORB-***@omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20060930/62bcc20d/attachment.htm

[Alex Tingle]

You should avoid SINGLE_THREAD_MODEL, since it doesn't guarantee that
your upcalls will be handled by a single thread, only that the upcalls
will be made sequentially. OmniORB's MAIN_THREAD_MODEL is a better bet,
since it guarantees that all upcalls are handled by the main thread.

http://blog.firetree.net/2005/06/14/single_thread_model/

-Alex

--
:: Let me solve your problems: http://www.firetree.net/consulting/
:: alex.tingle AT firetree.net [phone]

On 29 Sep 2006, at 22:19, Tuyen Chau wrote:

> Duncan Grisby wrote:
>> The normal approach is to put something in per-thread state. You don't
>> want to put it on the servant object because multiple clients could
>> call
>> a single servant concurrently.
>>
>> Cheers,
>>
>> Duncan
> This brings up another problem for us that we didn't anticipate. Our
> implementation unfortunately is not thread safe. Is there anyway we
> can force a single thread model in omniORB? It will be a big job for
> us to make our code thread safe.
>
> Thanks for your response,
> Tuyen
>
> _______________________________________________
> omniORB-list mailing list
> omniORB-***@omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list

[renny.koshy at rubixinfotech.com ()]

Alberto:

We've done something where we have single-threaded code.

1. Receive the requests as normal
2. Construct a "request structure", which contains a semaphore
3. Add the request to a queue [this must be done with mutex protection so
that the queue itself isn't accessed by two threads at once]
4. Wait for the semaphore to be signalled

In the main thread which is the "single thread" of our code
1. Check for requests in the queue
2. Process a requests
3. signal the sempahore on the request that was just processed
4. go back to 1.

Renny Koshy
President & CEO

--------------------------------------------
RUBIX Information Technologies, Inc.
www.rubixinfotech.com



"Alberto Casado
Mart?n"
<alberto.casado.m To
***@gmail.com> "Tuyen Chau" <***@verano.com>
Sent by: cc
omniorb-list-boun omniorb-***@omniorb-support.com
***@omniorb-suppo Subject
rt.com Re: [omniORB] How to get file
descriptor from a CORBA request?

09/30/2006 04:50
AM







Hello,

Is there anyway we can force a single thread model in omniORB? It
will be a big job for us to
make our code thread safe.

Yes, you can do that configuring your POA in SINGLE_THREAD_MODEL.


12 CHAPTER 2. THE BASICS

Multi-threading
As omniORB is fully multithreaded, multiple threads may perform the
same
upcall to your implementation concurrently. It is up to your
implementation
to synchronise the threads' accesses to shared data. In our simple
example,
we have no shared data to protect so no thread synchronisation is
necessary.
Alternatively, you can create a POA which has the
SINGLE_THREAD_MODEL
Thread Policy. This guarantees that all calls to that POA are
processed sequentially.


Cheers.
Alberto.

2006/9/29, Tuyen Chau <***@verano.com>:
Duncan Grisby wrote:
> The normal approach is to put something in per-thread state. You don't
> want to put it on the servant object because multiple clients could
call
> a single servant concurrently.
>
> Cheers,
>
> Duncan
This brings up another problem for us that we didn't anticipate. Our
implementation unfortunately is not thread safe. Is there anyway we can
force a single thread model in omniORB? It will be a big job for us to
make our code thread safe.

Thanks for your response,
Tuyen

_______________________________________________
omniORB-list mailing list
omniORB-***@omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list

[Sebastian Bickel]

Ist there a technique to dynamically generate CORBA objects during runtime. I want to
generate multiple event channels, but if I do that in the implementation of the CORBA object,
I get a "AlreadyExist"-Message. Can you please help me.

The code is attached. I only want to create multiple objects of the event channel during
runtime, but it doesn't succeed. Please help me.
// A little bit changed from the examples to omniEvents
//
// Package : omniEvents
// channel.cc Created : 2005/04/23
// Author : Alex Tingle
//
// Copyright (C) 2005 Alex Tingle
//
// This file is part of the omniEvents application and has been
modified
// during the study thesis of Sebastian BIckel.
//
// omniEvents is free software; you can redistribute it and/or
// modify it under the terms of the GNU Lesser General Public
// License as published by the Free Software Foundation; either
// version 2.1 of the License, or (at your option) any later
version.
//
// omniEvents is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU
// Lesser General Public License for more details.
//
// You should have received a copy of the GNU Lesser General
Public
// License along with this library; if not, write to the Free
Software
// Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307 USA
//
// Description:
// Demonstates how to make a standalone EventChannel in your own
// application, using libomniEvents.
//



[...]

#include <omniEvents/EventChannel.h>

/** Signal handler. */
void myShutdown(int signum)
{
OmniEvents::Orb::inst().shutdown(signum);
}

void * event_channel_task (void *)
{
std::cout << "OmniEvents::Orb::inst().run() calling!" <<
std::endl;
OmniEvents::Orb::inst().run();
std::cout << "OmniEvents::Orb::inst().run() called!" <<
std::endl;
}

#include "channel_factory.h"
#include <pthread.h>

std::string * ChannelFactory::createChannel(CORBA::ORB_var orb)
{
//
// Start orb.
// CORBA::ORB_var orb = CORBA::ORB_init(argc,argv);

const char* action=""; // Use this variable to help report errors.
try {
action="initialise OmniEvents::Orb";
// Your code MUST include these two lines.
OmniEvents::Orb::inst()._orb=CORBA::ORB::_duplicate(orb);
OmniEvents::Orb::inst().resolveInitialReferences();

action="activate the RootPOA's POAManager";
// You MUST activate the RootPOA's POAManager. You can do this
yourself
// in the normal way, or you can use the reference that
OmniEvents::Orb
// has resolved for you.
PortableServer::POAManager_var pman;
pman=OmniEvents::Orb::inst()._RootPOA->the_POAManager();
pman->activate();

action="create EventChannel servant";
// The constructor just allocates memory.
OmniEvents::EventChannel_i* channelSrv =new
OmniEvents::EventChannel_i();

action="activate EventChannel servant";
// activate() creates & activates the EventChannel's POA and
CORBA objects.
try {
channelSrv->activate("EventChannel");
} catch(...)
{
==> std::cout << "AdapterAlreadyExists" << std::endl;
}

// From this point, clients may invoke EventChannel operations.
action="obtain an object reference to the EventChannel";
CosEventChannelAdmin::EventChannel_var channelRef =channelSrv-
>_this();

// The user interface of this example is simple: The
EventChannel's IOR
// is dumped to the standard output stream.
action="stringify the EventChannel reference";
CORBA::String_var sior =orb->object_to_string(channelRef.in());
cout<<sior.in()<<endl;


action="set signal handlers";
::signal(SIGINT , ::myShutdown);
::signal(SIGTERM, ::myShutdown);

action="collect orphan requests";
// You MUST call this method, it processes orphan (asynchronous)
method
// calls made by the EventChannel.
// You can safely call it instead of CORBA::ORB::run(). If you
do not
// want to park the main thread, then you must create a new
thread for this
// method.
//cout<<"Calling OmniEvents::Orb::inst().run()
asynchronusly..."<<endl;
// OmniEvents::Orb::inst().run();
pthread_t thread;
pthread_create(&thread // Thread-Id
,NULL // Attributes
,::event_channel_task // Function
,NULL); // Arguments (none)

// OmniEvents::Orb::inst().run();
std::string * str_iop = new std::string();
(*str_iop) = sior.in();
return str_iop;

// OmniEvents::Orb::shutdown() has been called by the
myShutdown() signal
// handler. (The user pressed Ctrl-C or killed the process.)

// In order to make run() return, you MUST call
OmniEvents::Orb::shutdown().

action="destroy orb";
orb->destroy();

}
catch(CORBA::SystemException& ex) {
cerr<<"Failed to "<<action<<".";
#if defined(HAVE_OMNIORB4)
cerr<<" "<<ex._name();
if(ex.NP_minorString())
cerr<<" ("<<ex.NP_minorString()<<")";
#endif
cerr<<endl;
::exit(1);
}
catch(CORBA::Exception& ex) {
cerr<<"Failed to "<<action<<"."
#if defined(HAVE_OMNIORB4)
" "<<ex._name()
#endif
<<endl;
::exit(1);
}

return 0;
}



Greetings


Sebastian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20061002/b9089759/attachment-0001.htm

[Alex Tingle]

Sebastian,

> try {
> channelSrv->activate("EventChannel");
> } catch(...)
> {
> ==> std::cout << "AdapterAlreadyExists" << std::endl;
> }

You get the message "AdapterAlreadyExists" because you wrote it!!

The two exceptions activate() might throw are:
PortableServer::POA::ObjectAlreadyActive
PortableServer::POA::AdapterAlreadyExists

Either way, your problem is caused by the fact that you are trying to
create multiple EventChannels with the same name. The name must be
unique, because it is used as an ObjectId within omniORB.

If you don't care what the name is, then just call
OmniEvents::newUniqueId(), like this...

CORBA::String_var channelId =OmniEvents::newUniqueId();
channelSrv->activate(channelId.in());

regards,

-Alex

--
Dammit Jim, I'm a programmer... not a mind reader!

On 2 Oct 2006, at 20:00, Sebastian Bickel wrote:

> Ist there a technique to dynamically generate CORBA objects during
> runtime. I want to generate multiple event channels, but if I do that
> in
> the implementation of the CORBA object, I get a "AlreadyExist"-Message.
> Can you please help me.
>
>
> The code is attached. I only want to create multiple objects of the
> event channel during runtime, but it doesn't succeed. Please help me.
> // A little bit changed from the examples to omniEvents
> //
> // Package : omniEvents
> // channel.cc Created : 2005/04/23
> // Author : Alex Tingle
> //
> // Copyright (C) 2005 Alex Tingle
> //
> // This file is part of the omniEvents application and has been
> modified
> // during the study thesis of Sebastian BIckel.
> //
> // omniEvents is free software; you can redistribute it and/or
> // modify it under the terms of the GNU Lesser General Public
> // License as published by the Free Software Foundation; either
> // version 2.1 of the License, or (at your option) any later
> version.
>
> //
> // omniEvents is distributed in the hope that it will be useful,
> // but WITHOUT ANY WARRANTY; without even the implied warranty of
> // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> // Lesser General Public License for more details.
> //
> // You should have received a copy of the GNU Lesser General Public
> // License along with this library; if not, write to the Free
> Software
> // Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
> 02111-1307 USA
> //
> // Description:
> // Demonstates how to make a standalone EventChannel in your own
> // application, using libomniEvents.
> //
>
>
>
>
>
>
> [...]
>
>
> #include <omniEvents/EventChannel.h>
>
>
> /** Signal handler. */
> void myShutdown(int signum)
> {
> OmniEvents::Orb::inst().shutdown(signum);
> }
>
>
> void * event_channel_task (void *)
> {
> std::cout << "OmniEvents::Orb::inst().run() calling!" <<
> std::endl;
> OmniEvents::Orb::inst().run();
> std::cout << "OmniEvents::Orb::inst().run() called!" <<
> std::endl;
>
> }
>
>
> #include "channel_factory.h"
> #include <pthread.h>
>
>
> std::string * ChannelFactory::createChannel(CORBA::ORB_var orb)
> {
> //
> // Start orb.
> // CORBA::ORB_var orb = CORBA::ORB_init(argc,argv);
>
>
> const char* action=""; // Use this variable to help report errors.
> try {
> action="initialise OmniEvents::Orb";
> // Your code MUST include these two lines.
> OmniEvents::Orb::inst()._orb=CORBA::ORB::_duplicate(orb);
> OmniEvents::Orb::inst().resolveInitialReferences();
>
>
> action="activate the RootPOA's POAManager";
> // You MUST activate the RootPOA's POAManager. You can do this
> yourself
> // in the normal way, or you can use the reference that
> OmniEvents::Orb
> // has resolved for you.
> PortableServer::POAManager_var pman;
> pman=OmniEvents::Orb::inst()._RootPOA->the_POAManager();
> pman->activate();
>
>
> action="create EventChannel servant";
> // The constructor just allocates memory.
> OmniEvents::EventChannel_i* channelSrv =new
> OmniEvents::EventChannel_i();
>
>
> action="activate EventChannel servant";
> // activate() creates & activates the EventChannel's POA and CORBA
> objects.
> try {
> channelSrv->activate("EventChannel");
> } catch(...)
> {
> ==> std::cout << "AdapterAlreadyExists" << std::endl;
> }
>
>
> // From this point, clients may invoke EventChannel operations.
> action="obtain an object reference to the EventChannel";
> CosEventChannelAdmin::EventChannel_var channelRef =channelSrv-
>> _this();
>
>
> // The user interface of this example is simple: The EventChannel's
> IOR
> // is dumped to the standard output stream.
> action="stringify the EventChannel reference";
> CORBA::String_var sior =orb->object_to_string(channelRef.in());
> cout<<sior.in()<<endl;
>
>
>
> action="set signal handlers";
> ::signal(SIGINT , ::myShutdown);
> ::signal(SIGTERM, ::myShutdown);
>
> action="collect orphan requests";
> // You MUST call this method, it processes orphan (asynchronous)
> method
> // calls made by the EventChannel.
> // You can safely call it instead of CORBA::ORB::run(). If you do
> not
> // want to park the main thread, then you must create a new thread
> for this
> // method.
> //cout<<"Calling OmniEvents::Orb::inst().run()
> asynchronusly..."<<endl;
> // OmniEvents::Orb::inst().run();
> pthread_t thread;
> pthread_create(&thread // Thread-Id
> ,NULL // Attributes
> ,::event_channel_task // Function
> ,NULL); // Arguments (none)
>
> // OmniEvents::Orb::inst().run();
> std::string * str_iop = new std::string();
> (*str_iop) = sior.in();
> return str_iop;
>
>
> // OmniEvents::Orb::shutdown() has been called by the myShutdown()
> signal
> // handler. (The user pressed Ctrl-C or killed the process.)
>
>
> // In order to make run() return, you MUST call
> OmniEvents::Orb::shutdown().
>
>
> action="destroy orb";
> orb->destroy();
>
>
> }
> catch(CORBA::SystemException& ex) {
> cerr<<"Failed to "<<action<<".";
> #if defined(HAVE_OMNIORB4)
> cerr<<" "<<ex._name();
> if(ex.NP_minorString())
> cerr<<" ("<<ex.NP_minorString()<<")";
> #endif
> cerr<<endl;
> ::exit(1);
> }
> catch(CORBA::Exception& ex) {
> cerr<<"Failed to "<<action<<"."
> #if defined(HAVE_OMNIORB4)
> " "<<ex._name()
> #endif
> <<endl;
> ::exit(1);
> }
>
>
> return 0;
> }
>
>
>
>
>
>
> Greetings
>
>
>
>
> Sebastian
> _______________________________________________
> omniORB-list mailing list
> omniORB-***@omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list