[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster] socket reconnect flood
we reset the properties settings e.g.
could you please comment those lines out so the properties keep their values
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 ...'
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
Its attributes are: OS=ubuntu linux, protocol plugin=socket, security
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
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
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