I'm not submitting this in the issue tracker as I failed to gather enough
information for a proper bug report - pretty much all I can say is that things
that used to work flawlessly are now broken.
The application we're working on has fairly extensive client side unit tests.
Running them will generate thousands of queries to our RESTful service. This
used to not be a problem with RESTlet 1.1.5, where aside from a few issue we
needed to work around here and there, everything was fine.
I've recently upgraded to RESTlet 2.0 M4 to give it a go, and I've found that
we now have huge performance issue. As a disclaimer, it must be noted that I've
just upgraded to RESTlet 2.0, but haven't ported anything - I'm still using the
old, deprecated API. This might be the reason for all my woes.
By default, we're using the Simple web server. Running our application on this,
we very quickly start seeing OutOfMemoryExceptions on the server side.
Additionally, I'm seeing the following CPU hotspots:
- 12.1% : org.simpleframework.transport.reactor.ExecuteAction.<init>
- 11.3% : org.simpleframework.http.core.Reader.<init>
- 17.6% : org.simpleframework.transport.reactor.PartitionDistributor.process
This might not look so bad if not for the fact that:
- I'm not running anything else.
- both of my computer's cores are on a average load of 3.28.
- this is *after* I killed the unit tests. The server should be idle, it's not
being queried at all.
Looking at these hotspots, I figured it'd be an issue with the Simple webserver
and swapped it for Jetty. Performances are much better, for a few seconds, but
then I start seeing the following stacktrace server side:
2009-08-10 10:31:03,778] DEBUG org.mortbay.log EXCEPTION
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at
com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293)
at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:789)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:746)
at
com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
at org.mortbay.io.ByteArrayBuffer.readFrom(ByteArrayBuffer.java:382)
at org.mortbay.io.bio.StreamEndPoint.fill(StreamEndPoint.java:107)
at
org.mortbay.jetty.bio.SocketConnector$Connection.fill(SocketConnector.java:198)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:290)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
at
org.mortbay.jetty.security.SslSocketConnector$SslConnection.run(SslSocketConnector.java:636)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:520)
Once this has happened, the server will often drop queries and take ages to
answer to the ones it does reply to.
I might very well be doing something wrong, and maybe the fact that I'm using
the old 1.1.5 deprecated APIs is to blame, but I thought I'd mention this on
the off-chance that it was something worst.
These issues are preventing me from working on our application, so I'll
temporarily switch back to 1.1.5. On the other hand, I'm keeping the 2.0 M4
project handy, so if you need me to run any tests to identify a possible issue,
just let me know.
Regards,
Nicolas
------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2381998
