[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xmlblaster] socket reconnect flood


line 270,271,412,413

we reset the properties settings e.g.

  finally {
        System.setProperty("javax.net.ssl.trustStore", "");
        System.setProperty("javax.net.ssl.trustStorePassword", "");

could you please comment those lines out so the properties keep their values
and recompile
 cd xmlBlaster
 build all

Please report if this has resolved your problem,


Marcel Ruff wrote:

a stack trace (and probably finer logging) during the client goes wild would be nice.
Try to start the client with 'java -Dcom.sun.management.jmxremote ...' and
use the jconsole to gather the information if possible.
I think the 'not finding truststore' problem was reported some time ago,
i don't think we resolved it at that time, sorry.


Póka Balázs wrote:

I have a sporadically occuring problem with one of my XmlBlaster clients.
Its attributes are: OS=ubuntu linux, protocol plugin=socket, security plugin=homemade.
After some days of uptime (client was always connected) I noticed that the client did a DoS attack against our XmlBlaster server. :) It tried to reconnect so violently, that the server exhausted all its memory resources on the first occasion. Just like a SYN flood. (Since then, I installed iptables rules to prevent this.)

The second time this happened, it generated these logs on the client side (these two messages repeating in same order for a few megabytes):

2006-10-25 13:55:41,127 INFO [XmlBlaster.PingTimer] (SocketConnection.java :180) - SSL client socket enabled for socket://<our_address>:7608, keyStore=/home/disp/disp/conf/nova_disp/truststore
2006-10-25 13:55:41,128 WARN [ XmlBlaster.PingTimer] (SocketConnection.java:180) - SSL client socket can't find trustStore=/home/disp/disp/conf/nova_disp/truststore in xmlBlaster search pathes, see http://www.xmlblaster.org/xmlBlaster/doc/requirements/protocol.socket.html#SSL

I checked the truststore file and wasn't really shocked to learn that it's there and that it has appropiate permissions. The worst thing is that the PingTimer thread tries this again after a few msecs, causing the connect flood mentioned.
I have to stress that the client works flawlessly for a few days before this happens.

Any idea what this is caused by? If you need any further info, just say so.

Balázs Póka