Hi!
Ok, this is now fixed in the current svn,
thanks for your patience
Marcel
I've made a simple manual test consisting of:
- connecting to the XmlBlaster server with a given IP
- reconnect ADSL line so that dynamic IP gets refreshed
- test if everything works
The reconnection does work, but:
Server's log
-------------------
Connecting for the first time:
Jan 24, 2007 3:22:12 AM INFO 17-XmlBlaster.SSLSOCKET.SSL.tcpListener-poka RL10 org.xmlBlaster.protocol.socket.HandleClient
handleMessage: Client connected, coming from host=/somenet.216.127 port=4114
Jan 24, 2007 3:22:12 AM INFO 17-XmlBlaster.SSLSOCKET.SSL.tcpListener-poka RL10 org.xmlBlaster.util.dispatch.DispatchConnection handleTransition: Connection 'SOCKET' transition UNDEF -> ALIVE: Success, DispatchConnection-callback:/node/krumpli/client/poka/-3 connected.
Then comes the ping timeout:
... Connection transition ALIVE -> POLLING: socket://192.168.0.10:4114 is unaccessible ...
(Actually, this callback IP is a private one (NAT) of course, but since the socket protocol does not need a callback, it doen't matter.)
The reconnection seems ok (notice client different IP):
Jan 24, 2007 3:26:58 AM INFO 19-XmlBlaster.SSLSOCKET.SSL.tcpListener-poka RL10 org.xmlBlaster.protocol.socket.HandleClient handleMessage: Client connected, coming from host=/somenet.216.140 port=4135
Jan 24, 2007 3:26:58 AM INFO 19-XmlBlaster.SSLSOCKET.SSL.tcpListener-poka RL10 org.xmlBlaster.authentication.Authenticate connect: Using secretSessionId 'sessionId:192.168.0.252-null-1169605332591-1367373573-4' from ConnectQos
Jan 24, 2007 3:26:58 AM INFO 19-XmlBlaster.SSLSOCKET.SSL.tcpListener-poka RL10 org.xmlBlaster.authentication.SessionInfo updateConnectQos: -3-client/poka/-3: Successfully reconfigured callback address with new settings, other reconfigurations are not yet implemented
Jan 24, 2007 3:26:58 AM INFO 19-XmlBlaster.SSLSOCKET.SSL.tcpListener-poka RL10 org.xmlBlaster.authentication.Authenticate connect: Reconnected with given secretSessionId.
The problem is that messages (all are private and transient) are not going through anymore when the connection is reestabilished. Sending them is not throwing any exception, either (oneway or not). The connection callback does not receive anything.
Am I correct to assume that I may use the "old" (pre-IP-change) XmlBlasterAccess_I instance (I have not connected or disconnected)? What might be the problem?
thanks,
Balázs Póka