[omniORB] OBJECT_NOT_EXIST ???

[Sai-Lai Lo]

Ole,

2 suggestions:

1. It is better to try with callTimeOutPeriod set to infinite just to
   eliminate its side effect. In fact, due to popular demand, we had
   changed the default to no timeout after the initial 2.8 release.
   In case you have not pick up the latest source, it is worth doing it
   now at the usual place (CVS omni2_8_develp branch or the 
   omniORB_28_snapshots).

2. Do you have other concurrent client calls blocking for an extensive
   period of time on the server side? Remember, we set a limit of 5
   concurrent calls to go to the server at any time. Any more calls will be
   queued on the client side until one of the 5 returns.

   You can increase this value by setting
   omniORB::maxTcpConnectionPerServer *before* calling ORB_init().

Sai-Lai


>>>>> Storm,Ole OLS writes:

> Hi fellow omniORB'ers,
> We are using omniORB2.8 in a setup where one server (Win 2000 Service) is
> used by multiple distributed clients processes (Windows 95/98/NT/2000
> Application). Each client communicates with its own dedicated server object,
> which is dynamically created when the client logs on to the server process.
> These server objects are then destroyed when the client signs of, or
> automatically garbage-collected by the server if the clent process is
> otherwise terminated (the client ping's its object on a regular basis to
> keep it alive).

> Recently we have implemented a broadcast utility, such that the server is
> able to broadcast messages to all clients. However, after having added this
> broadcast utility, we are experiencing some client processes ocationally
> recieving the OBJECT_NOT_EXIST exception. 
> It seems that somehow the clients server object has been released from the
> ORB, and we can't figure out why!


> Our interface looks like this:

> interface ServerObject
> {
> 	...
> 	string get_broadcast_message();
> 	void ping();
> 	...
> }

> The get_broadcast_message() method is implemented as a 'hanging call', to
> avoid clients polling for messages. When a broadcast message is available
> the event object of every server object is signalled to wake up the thread
> in the 'hanging call'. The thread uses a timed wait on the event object, to
> avoid problems if the CORBA call is timed out. In our code we make sure that
> BROADCAST_TIMEOUT < omniORB::callTimeOutPeriod(...)

> The server implementation looks like this:

> char*  ServerObject_i::get_broadcast_message()
> 	// Returns the first available broadcast message.
> {
> 	try{
> 		if(m_bc_messages.size() == 0)
> 			WaitForSingleObject(m_bc_event, BROADCAST_TIMEOUT);
> 		std::string msg = "";
> 		if(m_bc_messages.size() > 0){
> 			msg = m_bc_messages.front();
> 			m_bc_messages.pop_front();
> 		}
> 		return CORBA::string_dup(msg.c_str());
> 	}
> 	catch(...)
> 	{ }
> 	return CORBA::string_dup("");
> }

> - while the client code calling get_broadcast_message() looks like:

> static DWORD WINAPI broadcast_handler_thread( LPVOID lpParameter )
> {
> 	while( true )
> 	{
> 		try
> 		{
> 			std::string s = _wc()->get_broadcast_message();
> 			if (s != "")
> 			{
> 				::MessageBox(frame_hWnd, s.c_str(),
> "Broadcast Message", MB_ICONINFORMATION | MB_SYSTEMMODAL);
> 			}
> 		}
> 		catch(...)
> 		{
> 		}
> 	}
> }
> - running in its own thread.


> Is there anything in this set-up (the hanging calls for instance) that could
> cause troubles?? We are somehow suspecting the calls to the ping() method -
> maybe they fail to reach the server object, which is then timed out!!

> We have recently upgraded from omniORB 2.7 to omniORB 2.8. For that reason
> we will ocationally have a client based on omniORB 2.7 running on the same
> machine as a client based on 2.8. Can this be a problem???




-- 
Sai-Lai Lo                                   S.Lo@uk.research.att.com
AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com 
24a Trumpington Street                Tel:   +44 1223 343000
Cambridge CB2 1QA                     Fax:   +44 1223 313542
ENGLAND