Archived
This forum has been archived. Please start a new discussion on GitHub.
Local connections work fine and remote connections sometimes fail
Hi,
I am using Ice 3.4.2 on OSX Snow Leopard as the ice service host and Ice Touch 1.1 for the ice client.
At first, I could not establish a connection between the client and the server. Before posting this message I did my homework and after a bit of testing and debugging, I think i have linked the problem to the OSX firewall. Even tough it was configured to let the transaction through for the server process, it somehow prevents it from working properly. I therefore disabled it completely to take that out of the equation.
Since then I have a strange intermittent problem establishing a connection between the client and the server. Sometimes, everything will work fine for up to two connections and then it will not work anymore until I reset everything and wait for a while.
In order to isolate potential issues, I went back to the library demo provided with the official ICE distribution which shows the same behavior. I run the java library server on my MacBook and the Ice-Touch library client on an iPhone 3GS.
Here is what is going on :
- If I try to connect the iOS library client to the server running at demo2.zeroc.com I can establish a connection and logout as many times as I see fit. No problem. It works flawlessly.
- If I try to connect the java client to the java server, both running on the same MacBook host, I can also establish a connection and logout as many times as I see fit. No problem. It works flawlessly.
- If I try to connect the iOS library client to the (java) server running on my mac, it will work once or twice flawlessly and then when I logout and try to login one more time, the client will get stuck in an endless "wait" displaying the "Connecting..." message on screen.
Here is what the server trace looks like when that situation occurs :
And here is the Error message that pops up on the iPhone screen a roughly in synch with the server trace at 26/07/11 15:24:06:675
which is a message I expected since the session has already timed out and was destroyed.
Am I correct to assume this is not an ICE related issue but more of a network routing / firewall issue ? The only thing I cannot fit into this diagnostic is the fact that I sometimes can establish a complete connection between the client and the server. When that happens, I can run queries back and forth without any issues.
This is really strange... I have been trying to figure it out for a couple of days already and I don't know where to look anymore.
Any hint would be greatly appreciated.
Regards,
Mathieu Dupont
Miralupa inc.
I am using Ice 3.4.2 on OSX Snow Leopard as the ice service host and Ice Touch 1.1 for the ice client.
At first, I could not establish a connection between the client and the server. Before posting this message I did my homework and after a bit of testing and debugging, I think i have linked the problem to the OSX firewall. Even tough it was configured to let the transaction through for the server process, it somehow prevents it from working properly. I therefore disabled it completely to take that out of the equation.
Since then I have a strange intermittent problem establishing a connection between the client and the server. Sometimes, everything will work fine for up to two connections and then it will not work anymore until I reset everything and wait for a while.
In order to isolate potential issues, I went back to the library demo provided with the official ICE distribution which shows the same behavior. I run the java library server on my MacBook and the Ice-Touch library client on an iPhone 3GS.
Here is what is going on :
- If I try to connect the iOS library client to the server running at demo2.zeroc.com I can establish a connection and logout as many times as I see fit. No problem. It works flawlessly.
- If I try to connect the java client to the java server, both running on the same MacBook host, I can also establish a connection and logout as many times as I see fit. No problem. It works flawlessly.
- If I try to connect the iOS library client to the (java) server running on my mac, it will work once or twice flawlessly and then when I logout and try to login one more time, the client will get stuck in an endless "wait" displaying the "Connecting..." message on screen.
Here is what the server trace looks like when that situation occurs :
MatsBook:library mdupont$ java Server -- 26/07/11 15:22:37:380 demo.Database.library.Server: ConnectionPool: establishing 5 connections to jdbc:mysql://localhost/library -- 26/07/11 15:22:51:363 demo.Database.library.Server: Protocol: sending validate connection message type = 3 (validate connection) compression status = 0 (not compressed; do not compress response, if any) message size = 14 -- 26/07/11 15:22:51:461 demo.Database.library.Server: Protocol: received request message type = 0 (request) compression status = 0 (not compressed; do not compress response, if any) message size = 74 request id = 1 identity = SessionFactory facet = operation = ice_isA mode = 1 (nonmutating) context = -- 26/07/11 15:22:51:469 demo.Database.library.Server: Protocol: sending reply message type = 2 (reply) compression status = 0 (not compressed; do not compress response, if any) message size = 26 request id = 1 reply status = 0 (ok) -- 26/07/11 15:22:51:492 demo.Database.library.Server: Protocol: received request message type = 0 (request) compression status = 0 (not compressed; do not compress response, if any) message size = 50 request id = 2 identity = SessionFactory facet = operation = create mode = 0 (normal) context = -- 26/07/11 15:22:51:515 demo.Database.library.Server: SessionFactory: create new session: 369ad5e2-0480-40f8-8bd7-ce43d5d67f55 -- 26/07/11 15:22:51:515 demo.Database.library.Server: Protocol: sending reply message type = 2 (reply) compression status = 0 (not compressed; do not compress response, if any) message size = 255 request id = 2 reply status = 0 (ok) -- 26/07/11 15:22:51:535 demo.Database.library.Server: Protocol: received request message type = 0 (request) compression status = 0 (not compressed; do not compress response, if any) message size = 61 request id = 3 identity = SessionFactory facet = operation = getSessionTimeout mode = 1 (nonmutating) context = -- 26/07/11 15:22:51:536 demo.Database.library.Server: Protocol: sending reply message type = 2 (reply) compression status = 0 (not compressed; do not compress response, if any) message size = 33 request id = 3 reply status = 0 (ok) -- 26/07/11 15:23:22:680 demo.Database.library.Server: ReapThread: The session 369ad5e2-0480-40f8-8bd7-ce43d5d67f55 has timed out. -- 26/07/11 15:23:22:688 demo.Database.library.Server: Session: session 369ad5e2-0480-40f8-8bd7-ce43d5d67f55 is now destroyed. -- 26/07/11 15:24:06:675 demo.Database.library.Server: Protocol: sending validate connection message type = 3 (validate connection) compression status = 0 (not compressed; do not compress response, if any) message size = 14 -- 26/07/11 15:24:06:697 demo.Database.library.Server: Protocol: received request message type = 0 (request) compression status = 0 (not compressed; do not compress response, if any) message size = 76 request id = 1 identity = 369ad5e2-0480-40f8-8bd7-ce43d5d67f55 facet = operation = getLibrary mode = 0 (normal) context = -- 26/07/11 15:24:06:698 demo.Database.library.Server: Protocol: sending reply message type = 2 (reply) compression status = 0 (not compressed; do not compress response, if any) message size = 69 request id = 1 reply status = 2 (object not exist) identity = 369ad5e2-0480-40f8-8bd7-ce43d5d67f55 facet = operation = getLibrary -- 26/07/11 15:24:06:725 demo.Database.library.Server: Protocol: received close connection message type = 4 (close connection) compression status = 1 (not compressed; compress response, if any) message size = 14 -- 26/07/11 15:24:06:730 demo.Database.library.Server: Protocol: received close connection message type = 4 (close connection) compression status = 1 (not compressed; compress response, if any) message size = 14
And here is the Error message that pops up on the iPhone screen a roughly in synch with the server trace at 26/07/11 15:24:06:675
Error Ice/Outgoing.cpp:424:Ice::ObjectNotExistException: object does not exist: identity: '369ad5e2-0480-40f8-8bd7-ce43d5d67f55' facet: operation: getLibrary
which is a message I expected since the session has already timed out and was destroyed.
Am I correct to assume this is not an ICE related issue but more of a network routing / firewall issue ? The only thing I cannot fit into this diagnostic is the fact that I sometimes can establish a complete connection between the client and the server. When that happens, I can run queries back and forth without any issues.
This is really strange... I have been trying to figure it out for a couple of days already and I don't know where to look anymore.
Any hint would be greatly appreciated.
Regards,
Mathieu Dupont
Miralupa inc.
0
Comments
-
Hi Mathieu,
I believe that your problem is related to the server endpoints configuration, by default server is configured to listen on all addresses, but this doesn't always work. Try to set the SessionFactory endpoints in config.server to an address that is reachable from the iPhone.SessionFactory.Endpoints=tcp -h 192.168.50.2 -p 10000:ssl -h 192.168.50.2 -p 10001
see also Object Adapter Endpoints - Ice 3.4 - ZeroC0 -
Dear Jose,
Thank you very much for such a swift and correct answer.
Not only does it fix the problem on the demo code but on my own client/server code as well.
Is it only experience with ICE that guided you toward this solution or there is some specific hint I should have spotted myself in the trace log ?
Is it a "best practice" to have a server listen on a single IP address/interface ?
Regards,
Mathieu0 -
Is it only experience with ICE that guided you toward this solution or there is some specific hint I should have spotted myself in the trace log ?
Running the client on the debugger, and enabling network tracing helps to know what is going on.Is it a "best practice" to have a server listen on a single IP address/interface ?
That depends on the system configuration, if all the addresses are reachable from remote clients, listen on all isn't a problem. For public services i think is a better option to use DNS names, and avoid to write ips in configuration files.0
