Hi Nicolas, Thanks for your report. My feeling is that using the deprecated classes should cause any special trouble, unless you rely on some recent bugs fixes in 1.1 branch that wouldn't have been back ported to Restlet 2.0.
Regarding Simple, we've upgraded from version 3.1 to 4.1. It is supported to work better as NIO is leveraged. I would suggest to contact the Simple framework list to help them spot the issues: https://lists.sourceforge.net/lists/listinfo/simpleweb-support Regarding Jetty, I've also just upgraded to their 7.0 RC4 version which is now part of Eclipse. I would suggest that you try again with a recent snapshot or when we release 2.0 M5. It might also be a client-side issue... When you get a chance to try again, could you isolate your issue in a small reproducible application that we could test and debug? Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -----Message d'origine----- De : Nicolas Rinaudo [mailto:[email protected]] Envoyé : lundi 10 août 2009 10:52 À : [email protected] Objet : RESTlet 2.0 M4 issues 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:1 98) 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:22 8) at org.mortbay.jetty.security.SslSocketConnector$SslConnection.run(SslSocketCon nector.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=23819 98 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2386272
