why Icegrid very slow?

[ChenQingQing]

/* this is the following code. It runs well but very slow. any suggestion?

*/

public Identity getDefaultObjectByServerId(String s){
try{
ServerInfo sInfo = getAdminPrx().getServerInfo(s); //getAdminPrx() return IceGrid.AdminPrx

AdapterDescriptor adapter= (AdapterDescriptor)sInfo.descriptor.adapters.get(0 );

for (Object object : adapter.objects) {
ObjectDescriptor obj = (ObjectDescriptor)object;
if (obj.type.equals("management::Manageable")){
return obj.id;
}
}
}
catch(ServerNotExistException e){
log.error("cannot reach server " + s + " :" + e.toString());
}
return null;
}

[benoit]

Hi,

Welcome to the forums! Before we look into your issue, could you please set your signature as described in this thread?

Thanks!

Benoit.

[ChenQingQing]

I have done that now, I think

[benoit]

Hi,

I'm afraid it's impossible to say without more information what could be the reason or if this is expected at all. How long does this code take to execute? What kind of machine are you using for the icegridregistry? Could you post the application descriptor here?

Thanks,

Benoit.

[ChenQingQing]

we are doing a web based application. It seems to take 30 or even more seconds to initialize an Ice communication. I don't really know how to post "application descriptor " as which is an object I think. I may post some values which you think are important. Actually, we now have serveral applications named as "CN, CT, EC, ET, SMS, SPS and DUMMY". we use the following code to add new application in web page. Is it suitable?

// Basically we set all the attribute to empty except for name when creating node and application
ApplicationDescriptor app = new ApplicationDescriptor();
app.name = name;
app.variables = new TreeMap();
app.replicaGroups = new LinkedList();
app.serverTemplates = new TreeMap();
app.serviceTemplates = new TreeMap();
app.nodes = new TreeMap();
app.distrib = new DistributionDescriptor();

app.description = description;
try{
adminPrx.addApplication(app); //adminPrx is IceGrid.AdminPrx
}
catch(Exception e){
throw new RuntimeException(e);
}

[benoit]

Hi,

Ok, so you create the application descriptors programatically (you don't load them from an XML file). Is there many servers declared in each application? From the code you posted, it looks like the application descriptors are mostly empty, right?

I'm afraid it's still impossible to say what could be wrong. Are you sure Ice/IceGrid is responsible for the slow response time? Could you add timing information to your code around the call to "ServerInfo sInfo = getAdminPrx().getServerInfo(s)" to see how long it takes?

Please also provide the Ice version, the operating system and and kind of hardware you're using. If you could also provide a simple self compilable test case that demonstrate the problem, I'll be happy to look at it.

Cheers,
Benoit.

[benoit]

Btw, this might also be some kind of network issue. You could try to turn network tracing on with the Ice.Trace.Network property (set to 2) to see if it can give you some clues.

Benoit.

[vsonnathi]

I did notice this behavior once and the machine on which the Servant was running had two IP addresses and one of them was not accessible from the Client so Ice Runtime had to timeout and then try the other end point to get the response.

HTH.

Regards,
--Venkat.

/* this is the following code. It runs well but very slow. any suggestion?

*/

public Identity getDefaultObjectByServerId(String s){
try{
ServerInfo sInfo = getAdminPrx().getServerInfo(s); //getAdminPrx() return IceGrid.AdminPrx

AdapterDescriptor adapter= (AdapterDescriptor)sInfo.descriptor.adapters.get(0 );

for (Object object : adapter.objects) {
ObjectDescriptor obj = (ObjectDescriptor)object;
if (obj.type.equals("management::Manageable")){
return obj.id;
}
}
}
catch(ServerNotExistException e){
log.error("cannot reach server " + s + " :" + e.toString());
}
return null;
}

[ChenQingQing]

The registery machine runs VMware which create two virtural IP address.

[benoit]

Did you find the solution to your problem?

The most likely reason is that Ice tries to contact the VMware virtual IP addresses and this takes some time if the VMware virtual machines are not running. If you run your client with Ice.Trace.Network=2, you should see if that's the case. You should configure IceGrid to only listen on a specific interface (it listens on all network interfaces by default), for example with the configuration properties below, IceGrid will only listen on the interface with the IP address 192.168.0.5.

IceGrid.Registry.Client.Endpoints=default -p 12000 -h 192.168.0.5
IceGrid.Registry.Server.Endpoints=default -h 192.168.0.5
IceGrid.Registry.Internal.Endpoints=default -h 192.168.0.5
IceGrid.Registry.Admin.Endpoints=default -h 192.168.0.5

Hope this helps.

Cheers,
Benoit.

[ChenQingQing]

Now it works quickly. it should be that the VMware makes the problems.

Thanks a lot!