Life Cycle Problems

[RonnieDay]

Hi,

I am trying to save a state in a C# servant and it seems to become corrupt between construction and the remote method call. Is there something I am doing wrong ?

here is a quick snippet of the code I am using :


public class HelloI : HelloDisp_
{
private IDataProvider _provider;
private string _serviceName;

public HelloI(string serviceName)
{
_serviceName = serviceName;
//creation and call to data provider - works fine
_provider = new DataProvider();
_provider.GetData();
}

public override string GetData()
{
//call to the same dataprovider method - fails.
//The provider error states that it has been shutdown
return _provider.GetData();
}
}

I have tried this outside of the Ice framework and successive calls to the provider works fine. It appears that ice is doing some funny business with this class.

Any help would be appreciated

Regards

Ronnie

[RonnieDay]

could this be anything to do with having server-lifetime="false" set in my config ?

[bernard]

Hi Ronnie,

The server-lifetime setting should be set to true for most applications, but this should be totally unrelated to your issue.

Perhaps you're using a multi-threaded Ice server and your _provider does not like calls from different threads?

Did you try this test with a collocated client? (collocated as in the same program as your server, sharing the same communicator). A collocated client would use the calling thread and not a thread from the server thread pool to dispatch requests.

All the best,
Bernard

[RonnieDay]

ok, so what is server-lifetime set to true supposed to do ?

could you give an example of how to achieve a collocated client in C#?

wouldn't a collocated client would only solve the problem locally anyway? Is there anyway I can set up ice to work in a single threaded way instead of multithreaded?

[bernard]

Hi Ronnie,

ok, so what is server-lifetime set to true supposed to do ?

This server-lifetime attribute is used by IceGrid to determine the current state of the server.

As described in the manual:

A server is considered activated when all the object adapters with the server-lifetime attribute set to true are registered with the registry (the object adapter registers itself during activation).
Furthermore, server deactivation is consid*ered to begin as soon as one object adapter with the server-lifetime attribute set to true is unregistered with the registry (the object adapter unregisters itself during deactivation).

See http://www.zeroc.com/doc/Ice-3.4.1-I...rid.39.17.html. Note that the proper spelling is server-lifetime, and not server-life-time ... we'll fix this bug!

You would use server-lifetime=false for an object adapter that you activate only for a little while, or that you activate/deactivate repetitively while your server is running ... all unusual situations.

could you give an example of how to achieve a collocated client in C#?

In your server, after you activate your object adapter and before you "wait for shutdown", you would create a proxy to the target object (e.g. with stringToProxy or propertyToProxy) and call on this target object. This call would be collocated.

wouldn't a collocated client would only solve the problem locally anyway? Is there anyway I can set up ice to work in a single threaded way instead of multithreaded?

A collocated call goes through Ice and would allow you to verify that Ice doesn't change your servant in any way.

If the issue is threading, you can easily setup a single-threaded server ... it's actually the default. In your server configuration, verify that Ice.ThreadPool.Server.Size is not set or set to 1.

Best regards,
Bernard