Hang in C# getDelegate__()

[acbell]

Hi,

We are seeing hangs in calls to getDelegate__() (as the result of a method call to a server) on the order of 10 to 15 seconds. This does not happen every time, but does seem to occur after nothing has been happening with the application for a while. I am guessing that the problem occurs after ACM shuts down the connection, and a new connection needs to be established. This problem does NOT occur in version 3.0.1, but exists in 3.1.1 and 3.2.1.

I will build up a debug version of the ICE lib to see if I can isolate this further, but I thought I would post what I know to see if it rang a bell with anyone.

Cheers,

[benoit]

Hi,

It's expected for the client to spend some time in the internal getDelegate() method as it's from this method that the connection might be re-established. I recommend to enable network and retry tracing (with Ice.Trace.Network=2 and Ice.Trace.Retry=2) to see how long the connection establishment takes.

Cheers,
Benoit.

[acbell]

The server was advertising an address not accessible by the client. Some behavior must have changed, though, between 3.0 and 3.1 regarding this - which endpoints are tried and so on. There's so much to remember!

Anyway, thanks for the help.

[michi]

If the proxy contains more than one endpoint, endpoint selection is random. A bug in 3.0 meant that the endpoints weren't shuffled correctly, which explains why you didn't see this earlier.

Cheers,

Michi.

[acbell]

Hi,

Yes. I remember that bug now. I think I reported it

Anyway, this gave me an idea for a feature. We have two interfaces on our system. One is private to a small set of machines, the other is public to the world. Right now, the server advertises both of these addresses. It would be nice to have an option so that the client proxy favored the endpoint that it used in the past - reorder the proxy's endpoints or cache the connection information even after the connection is closed. This way one could advertise many endpoints, but the client wouldn't waste time trying ones that were inaccessible once it knew this was the case. Of course, this isn't for everyone -- a client doesn't know WHY an endpoint couldn't be reached -- it may make perfect sense (and be desirable) to try again later, so it would have to be a configuration thing.

Thanks as always,

P.S. - I still think it would be great to have an Ice conference/meeting. Any interest out there?

[michi]

We've considered doing something like this in the past but, as you say, the difficulty is to decide when and how to retry a connection that failed previously. Overall, I'm inclined to think that the added configuration complexity may not be worth the benefit.

Have you considered arranging your interfaces such that the public clients don't receive proxies containing the private endpoint?

Cheers,

Michi.

[marc]

Originally Posted by acbell

P.S. - I still think it would be great to have an Ice conference/meeting. Any interest out there?

I would love to organize the first "Ice Developer Meeting". The question is whether we can get enough participants. Perhaps I put a poll onto our forums, to get an idea who would be interested in such a meeting. As an additional motivator, we could have the meeting in Florida in Spring time

[ctennis]

I subscribe to your idea of a springtime developer meeting in Florida!