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-pokaRL10
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-pokaRL10
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-pokaRL10
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-pokaRL10
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-pokaRL10
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-pokaRL10
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

Reply via email to