[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster] socket reconnect flood
In
xmlBlaster/src/java/org/xmlBlaster/util/protocol/socket/SocketUrl.java
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,
thanks
Marcel
Marcel Ruff wrote:
Olá,
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.
Marcel
Póka Balázs wrote:
Hi!
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.
thanks,
Balázs Póka