[omniORB] two clients in one PC

[Aida Fátima Cano]

Hello

I'm trying to test a server that must coordinate 20 clients; I have no 20
computers on which run the different clients so I've tried running two
clients on the same PC. What works fine with two clients in two different
computers totally crashes if the clients runs in the same PC. Each client
binds it service in omninames with different name, althoug the methods which
offers are the same for the two of them.

It is possible for CORBA an omniorb implementation to run this test?

Thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20070116/384c4df6/attachment.htm

[Thomas Lockhart]

... Each client binds it service in omninames with different name, althoug
the methods which offers are the same for the two of them.
It is possible for CORBA an omniorb implementation to run this test?

I am not sure I understand your scenario (I got confused by "client
binds... with different name"), but in general multiple clients and
servers can coexist on a single machine.

If you are using persistent IORs or otherwise constraining the ports
used by the clients then of course they must be unique.

hth

- Tom

[Aida Fátima Cano]

//------------------------------------------------------------------------
// The "name text" put forth by CORBA server in name service.
// This same name ("DataServiceName1") is used by the CORBA server when
// binding to the name server (CosNaming::Name).
//------------------------------------------------------------------------
m_corbaCosName.length(1);
m_corbaCosName[0].id="DataServiceName1"

What I mean when saying that each client binds with a diffierent name is
that each one is registered in omninames with differene name, although the
application is the same.

The code above is not the one used, but with a dynaimc variable instead
"DataServiceName1"

I'm not totally sure if the problem is related with the way I configure
CORBA or with the code of the clients because I don't know very deeply how
CORBA works. I'll try figure out where exactly the problem is, so I can ask
something less general.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20070116/f1625c43/attachment.htm

[Wernke zur Borg]

//------------------------------------------------------------------------
// The "name text" put forth by CORBA server in name service.
// This same name ("DataServiceName1") is used by the CORBA server when
// binding to the name server (CosNaming::Name).
//------------------------------------------------------------------------
m_corbaCosName.length(1);
m_corbaCosName[0].id="DataServiceName1"



What I mean when saying that each client binds with a diffierent name is that each one is registered in omninames with differene name, although the application is the same.

The code above is not the one used, but with a dynaimc variable instead "DataServiceName1"

I'm not totally sure if the problem is related with the way I configure CORBA or with the code of the clients because I don't know very deeply how CORBA works. I'll try figure out where exactly the problem is, so I can ask something less general.

Thanks


Hi

either you or I have a misunderstanding here... clients normally do not bind to or register with the naming service (except they offer an interface themselves) but they usually only resolve names, which is a transient process. I understand your scenario as having one server and multiple clients, so only the server creates object bindings in the naming service, and each of the clients resolves the names.

I am afraid we have to get the nomenclature precise before we can proceed helping you with your problem.

Wernke

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20070117/984813a4/attachment-0001.htm

[Aida Fátima Cano]

I'm sorry.

I didn't realize I forgot to clarify this point. The server offers services
to the clients, but the clients mus offer some services in return, and of
course, all of them the same services. Is somethign like this:
One client must stop working so, before that, sends a request to the
server, and the server ask to the others clients on the net to do the tasks
of the one that is leaving.

thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20070117/abac4414/attachment.htm

[Wernke zur Borg]

I'm sorry.

I didn't realize I forgot to clarify this point. The server offers services to the clients, but the clients mus offer some services in return, and of course, all of them the same services. Is somethign like this:
One client must stop working so, before that, sends a request to the server, and the server ask to the others clients on the net to do the tasks of the one that is leaving.



OK, this sounds better, in the sense of CORBA you have multiple redundant servers offering the same interface. This should work as long as each of them binds their objects with unique names, but you wrote earlier that this is the case.

A possible reason for a crash would be that a client uses an object reference that is no longer valid, because the server has gone down.

Are you sure that you (a) always unbind a server's objects before it goes down, and (b) always catch exceptions thrown by server calls? If you do the latter, you would get aware about an IOR that is no longer valid, and you could then try to re-resolve it at the naming service. Failure to do so would indicate a server that has gone down.

So, in principle your scenario is feasible, but as you wrote, it is hard to find the reason for crashes without more detailed information. You should enable the omniORB trace and try to understand what happens in detail.

Regards, Wernke

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20070117/cc837b7a/attachment.htm