Further to this comment, I have been performing a little load testing on
JAMES. (The load test is not really aimed at testing JAMES - just the
throughput of my app, of which JAMES is only a part.) One thing I have
discovered is that I can flood a JAMES box so that I get "no route to host"
without difficulty.
I am running James on a quite modest HP 9000 (1 CPU, 1GB RAM). I have a
single client machine (PIII 733, 384MB RAM) separated from JAMES by a
broadband WAN link (not sure how fast). My client app opens a number of
threads, each of which sends one short message to JAMES via the JavaMail
API. I find that 200 threads are all that is necessary for "no route to
host" to come back.
Has anyone else struck this? Does anyone have any performance tuning tips?
I have tried adjusting the number of threads allocated to both the thread
manager and the spool manager, but that seems to make no difference. (Not
surprising, as the spoolmanager operates asynchronously to the connection
handler anyway.)
Cheers
ADK
--------------------------------------------
There is no magic.
Brad Wallace
<babafloolee@minds To: [EMAIL PROTECTED]
pring.com> cc:
Subject: James stops responding after
many TCP connections to SMTP service - DOS
24/04/2002 11:37 attack possible?
Please respond to
"James Users List"
Hi All - I'm running James in a load balanced environment (required by
our policies... ;-) One side effect of this is that the load balancers
establish repeated TCP connections to the SMTP service and then break
them (TCP RST or FIN I expect). They do this to verify that the service
is listening and accepting inbound connections. Right now I'm running
in debug mode, so these connections are being logged - I've included
samples below.
Here's the problem - after james has been running for some period of
time less than 1 week, I get the following on stdout:
Logging Error: Unknown error writing event.
java.lang.OutOfMemoryError
<<no stack trace available>>
and then james stops responding. So far I've had to restart james each
time to get this fixed. I'll admit that the frequent TCP connection
setups and breakdowns are a quirk of this type of environment, but it
concerns me also b/c this seems like an easy DOS (Denial of Service)
attack on a james server - simply establish and break TCP connections
every 5 seconds or so for a while and it will hang until someone
restarts it - it's not yet clear exactly how long you have to repeat
these TCP connections for, but it's somewhere in the hours - days range,
but not weeks. And every 5 seconds probably isn't frequent enough to
trigger most firewall's DOS filters, so this is pretty likely to get
through.
I'm running:
James 2.0a2 with just the SMTP listener (no pop3, nntp, remote admin,
etc)
java-1.3.1_02
Solaris 7
Thanks much for any input.
-Brad
Logs Excerpts:
smtpserver.log:
Tue Apr 23 22:02:58 GMT 2002 [INFO ] (smtpserver): Hello Name is:
<local machine name>
Tue Apr 23 22:02:58 GMT 2002 [DEBUG ] (smtpserver): Max message size
is: 0
Tue Apr 23 22:02:58 GMT 2002 [INFO ] (smtpserver): Connection from
<load balancer IP> (<load balancer IP>)
Tue Apr 23 22:02:58 GMT 2002 [DEBUG ] (smtpserver): Socket to <load
balancer IP> closed remotely.
java.net.SocketException: Connection reset by peer: Connection reset by
peer
at java.net.SocketInputStream.socketRead(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:90)
at
java.io.BufferedInputStream.fill(BufferedInputStream.java:186)
at
java.io.BufferedInputStream.read(BufferedInputStream.java:204)
at java.io.DataInputStream.readLine(DataInputStream.java:449)
at
org.apache.james.smtpserver.SMTPHandler.handleConnection(SMTPHandler.java:163)
at
org.apache.avalon.cornerstone.blocks.connection.ConnectionRunner.run(Connection.java:163)
Tue Apr 23 22:02:58 GMT 2002 [ERROR ] (smtpserver): Connection timeout
on socket
connections.log:
Tue Apr 23 22:11:34 GMT 2002 [DEBUG ] (connections): Starting
connection on Socket[addr=<load balancer IP>/<load balancer
IP>,port=<source port>,localport=<james smtp port>]
Tue Apr 23 22:11:34 GMT 2002 [DEBUG ] (connections): Ending connection
on Socket[addr=<load balancer IP>/<load balancer IP>,port=<source
port>,localport=<james smtp port>]
Tue Apr 23 22:11:36 GMT 2002 [ERROR ] (connections): Exception
accepting connection
java.net.SocketException: Software caused connection abort
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:468)
at java.net.ServerSocket.implAccept(ServerSocket.java:243)
at java.net.ServerSocket.accept(ServerSocket.java:222)
at
org.apache.avalon.cornerstone.blocks.connection.Connection.run(Connection.java:93)
at
org.apache.avalon.excalibur.thread.impl.ExecutableRunnable.execute(ExecutableRunnable.java:47)
at
org.apache.avalon.excalibur.thread.impl.WorkerThread.run(WorkerThread.java:80)
Tue Apr 23 22:11:38 GMT 2002 [DEBUG ] (connections): Starting
connection on Socket[addr=<load balancer IP>/<load balancer
IP>,port=<source port>,localport=<james smtp port>]
Tue Apr 23 22:11:38 GMT 2002 [DEBUG ] (connections): Ending connection
on Socket[addr=<load balancer IP>/<load balancer IP>,port=<source
port>,localport=<james smtp port>]
Tue Apr 23 22:11:40 GMT 2002 [ERROR ] (connections): Exception
accepting connection
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]
>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]
>
-----------------------------------------------------------------------------------------------
Have you seen our website?.... http://www.vodafone.co.nz
CAUTION: This correspondence is confidential and intended for the named recipient(s)
only.
If you are not the named recipient and receive this correspondence in error, you must
not copy,
distribute or take any action in reliance on it and you should delete it from your
system and
notify the sender immediately. Thank you.
Unless otherwise stated, any views or opinions expressed are solely those of the
author and do
not represent those of Vodafone New Zealand Limited.
Vodafone New Zealand Limited
21 Pitt Street, Private Bag 92161, Auckland, 1020, New Zealand
Telephone + 64 9 357 5100
Facsimile + 64 9 377 0962
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
