[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [xmlblaster] Fail safe mode/invalid secretsessionId
Hi Michele,
Thanks for your quick answer.
I think that server closes the session because of a ping fail (dispatch/callback/retries=0 is set).
There is no timeout on the session and there are no JMX calls.
In the log of the agent we can see the following lines:
2006-08-04 11:35:39,725 WARN [Thread-4] xmlBlaster.dispatch - [DispatchConnection-connection:client/mwec9a0205-agent/10] initialize:XmlBlasterException errorCode=[communication.noConnection] serverSideException=false location=[SocketUrl] message=[#1.1 SSL XmlBlaster server is unknown, '-dispatch/connection/plugin/socket/hostname=<ip>' : java.net.ConnectException: Connection refused: connect] [See URL http://www.xmlblaster.org/xmlBlaster/doc/requirements/admin.errorcodes.listing.html#communication.noConnection]
2006-08-04 11:35:39,766 WARN [Thread-4] xmlBlaster.dispatch - [DispatchConnection-connection:client/mwec9a0205-agent/10] Connection transition UNDEF -> POLLING: socket://msilsa0215:7609 is unaccessible, we poll for it every 2000 msec: errorCode=communication.noConnection message=#1.1 SSL XmlBlaster server is unknown, '-dispatch/connection/plugin/socket/hostname=<ip>' : java.net.ConnectException: Connection refused: connect
2006-08-07 15:40:12,371 ERROR [Login requestor mwec9a0205-agent] errorCode=user.security.authentication.accessDenied message=#1.1 Your secretSessionId is invalid, no access to xmlBlaster_162_111_89_158_3412.
After the error " user.security.authentication.accessDenied " there are no more lines into the agents. If it has been disconnected, I should see lines
Like this one no?
2006-07-26 17:30:55,205 WARN [XmlBlaster.PingTimer] xmlBlaster.dispatch [DispatchConnection-connection:client/mwec9a0205-agent/10] No connection established, socket://msilsa0215:7609 still seems to be down after XXX connection retries
Unfortunately, it is not easily reproducible and most of the time all is ok, but in some rare cases some agents are not able to connect to the server.
Currently, I updated the code of our agents in order to reconnect if such an exception occurred. But I don't understand why some agents do not know that they lose the connection with the server (They are using a killed session).
Best regards,
Xavier.
-----Original Message-----
From: owner-xmlblaster at server.xmlBlaster.org [mailto:owner-xmlblaster at server.xmlBlaster.org] On Behalf Of Michele Laghi
Sent: jeudi 17 août 2006 14:10
To: xmlblaster at server.xmlBlaster.org
Subject: Re: [xmlblaster] Fail safe mode/invalid secretsessionId
Hi Xavier,
what you described happens when the server has no session anymore (for
example if it has been killed for some reason) and the client does not
know about it and tries to work as usual (publish subscribe etc.)
Xavier Roques wrote:
> Hello,
>
> After doing an OS patch on some of our boxes
> We notice that some agents were not connected to the xmlblaster server.
>
> In the log of the agents we can see the following errors:
>
> INFO | jvm 1 | 2006/08/07 15:40:12 | 2006-08-07 15:40:12,371 ERROR
> [Login requestor mwec9a0205-agent] event.LoginRequestor
> (com.infovista.foundation.jmx.event.LoginRequestor:LoginRequestor.java:r
> un:87) - com.infovista.foundation.middleware.mom.MOMException:
> errorCode=user.security.authentication.accessDenied message=#1.1 Your
> secretSessionId is invalid, no access to xmlBlaster_162_111_89_158_3412.
>
> And the agent does not try anymore to connect to the Xmlblaster server.
>
> We are using xmlblaster 1.1
> All our agents are configured to use the fail safe mode and only one
> session of each agent is allowed ("sameclientonly").
> The protocol used is the SOCKET one.
>
> How can I fix this issue?
>
I think it is the job of the client application (in your case your
agent) to decide what to do if such an exception happens. In your case
you would wish to reconnect (explicit reconnect).
The underlying problem, that is the reason why the server has killed the
session is unknown to me: I would need some more details, for example
configuration and server logs.
Some of the reasons could be because:
- explicit killing of the session (for example via jmx)
- session timeout
- callback ping failing and no -dispatch/callback/retries=-1 set
- ...
Regards
Michele
> Thanks,
>
> XavieR.
>
>
>