Re: Using the standalone server
Yes -- well, not a "random" Object, but an Object used purely for its built-in lock -- and then the type of incr could be plain int. --tim On Tue, Sep 30, 2008 at 10:04 PM, Rob Heittman <[EMAIL PROTECTED]>wrote: > Right. So if it was desirable to do so (for example, if I was doing > something more complicated than counting) I could have declared a random > Object lockObject and the block would be functional, at least. > /threadjack > > - R > > On Tue, Sep 30, 2008 at 8:30 PM, Tim Peierls <[EMAIL PROTECTED]> wrote: > >> In this case, though, the value of the field incr is changing, so it is >> not suitable as the argument of @GuardedBy. >> > >
Re: PUT to a Directory fails
Shockingly, I'm on Windows XP Pro. Anything special I should do to make sure I'm not leaving something open? -jeff Rob Heittman wrote: Server OS details? This comes up often on Windows, which will not allow you to delete a file that has an InputStream open to it. Not sure why an InputStream would still be open, though ... it's not a feature if it is. On Tue, Sep 30, 2008 at 8:48 PM, Jeff Ramsdale <[EMAIL PROTECTED]> wrote: I'm using GWT and Restlet 1.1-SNAPSHOT. My server provides a Directory, from which I can GET a text file and display it in an editable TextArea in the browser. I have a button that should PUT the modified contents back to the server but the PUT fails on the server with:
Re: Using the standalone server
Right. So if it was desirable to do so (for example, if I was doing something more complicated than counting) I could have declared a random Object lockObject and the block would be functional, at least. /threadjack - R On Tue, Sep 30, 2008 at 8:30 PM, Tim Peierls <[EMAIL PROTECTED]> wrote: > In this case, though, the value of the field incr is changing, so it is not > suitable as the argument of @GuardedBy. >
Re: PUT to a Directory fails
Server OS details? This comes up often on Windows, which will not allow you to delete a file that has an InputStream open to it. Not sure why an InputStream would still be open, though ... it's not a feature if it is. On Tue, Sep 30, 2008 at 8:48 PM, Jeff Ramsdale <[EMAIL PROTECTED]> wrote: > I'm using GWT and Restlet 1.1-SNAPSHOT. My server provides a Directory, from > which I can GET a text file and display it in an editable TextArea in the > browser. I have a button that should PUT the modified contents back to the > server but the PUT fails on the server with:
PUT to a Directory fails
I'm using GWT and Restlet 1.1-SNAPSHOT. My server provides a Directory, from which I can GET a text file and display it in an editable TextArea in the browser. I have a button that should PUT the modified contents back to the server but the PUT fails on the server with: WARNING: Unable to delete the existing file This comes from line 828 in FileClientHelper. In line 780 tmp.exists() is true, but file.delete() returns false. Since this goes into native code I'm unable to determine why the delete fails. I've done setModifiable(true) on my Directory. Any pointers on why this might be failing? Thanks, -jeff
Re: Using the standalone server
Yes. In *Java Concurrency in Practice* lingo, you need to be able to declare of any non-final, non-volatile field f that is potentially accessed by multiple threads that f is @GuardedBy(something), where "something" is usually "this" for non-static fields, but could be any object, like the referent of a final field of reference type. @GuardedBy(x) means all accesses to f are with x's built-in lock held, i.e., inside synchronized (x) {...} -- or if x is a j.u.c.locks.Lock, then wrapped by a try-finally with x.lock()/x.unlock(). In this case, though, the value of the field incr is changing, so it is not suitable as the argument of @GuardedBy. --tim On Tue, Sep 30, 2008 at 7:06 PM, Rob Heittman <[EMAIL PROTECTED]>wrote: > Using an atomic makes more sense. This class predates my reading of > your book ;-) Although, looking at this again, I'm embarrassed to > admit I'm not sure *why* synchronizing on incr doesn't do anything. > Because I'm reassigning it? > > > Slight problem with newUniqueID(), though. Synchronizing on incr doesn't > do > > anything. How about using AtomicLong and masking out the high bits? >
Re: Using the standalone server
Trunk's updated to use an AtomicLong. Masking was slowish. I'm just resetting it to zero when it is found to exceed Integer.MAX_VALUE, which fulfills the original contract of the class, which is to guarantee Integer.MAX_VALUE unique values per second (and maybe a few more, depending). Any fallacies in that? > Slight problem with newUniqueID(), though. Synchronizing on incr doesn't do > anything. How about using AtomicLong and masking out the high bits?
Re: Using the standalone server
On Sep 30, 2008, at 2:55 PM, Rob Heittman wrote: I see that I am in fact using the Simple connector, as per the FirstResource tutorial, I went out of my way to put its jar on the classpath. This configuration is what I meant by 'standalone server'. I like Simple in concept, but I've had some not-so-wonderful experiences with it in practice. It also seems to be supported by a smallish team with limited resources. Jetty's been uniformly wonderful for us in production -- we were using it for embedded apps before we started working with Restlet, and I recommend it as both a Servlet and a Restlet container. My app is pretty simple, and thus far has no traditional state I need to maintain - except the notion of "is logged in". I'd like to use the Jetty connector. As I said, I'm using the Simple connector in my FirstResource-like app, and when I remove from my runtime classpath estlet-1.1rc2/lib/org.simpleframework_3.1/org.simpleframework.jar and add restlet-1.1rc2/lib/org.mortbay.jetty_6.1/org.mortbay.jetty.jar restlet-1.1rc2/lib/javax.servlet_2.5/javax.servlet.jar per http://www.restlet.org/documentation/1.1/connectors#jetty I get on startup: Exception in thread "main" java.lang.NoClassDefFoundError: simple/http/ ProtocolHandler which indicates that something in my build is still looking for Simple connector support. I looked to the Configuration section here http://www.restlet.org/documentation/1.1/connectors#server_connectors to understand how to code the server's main() entry point, but couldn't see how my FirstResource-like app, with its Component, subclassed Application, and Routers ( and router.attach()'s ) translates. If in fact translation is necessary? That is, perhaps the NoClassDefError owes to something else? The philosophy behind all this is a bit head-twisting, but once I did it this way a few times, I never ever ever EVER wanted to go back to the "old" way! It is more up front work to decide I need a class of server-side resource, and work through how to handle it, rights and responsibilities, side effects of operations, etc. But, once I've done that, I'm DONE with the server architecture ... and the resource integrates with any kind of Web-based client, regardless of platform, language, etc. With the Servlet session model, it's so easy to throw things in the session bag, but then I need to invent ways of getting them out every time I want to move processing to the client. Net effect: with sessions, I don't wanna move any processing to the client. I generally get this, and appreciate it. P.S. Since Restlet doesn't do it on its own yet, here's my browser identity cookie generator: http://gogoego.googlecode.com/svn/trunk/modules/RestletFoundation/src/com/solertium/container/CookieUtility.java Nice. Thanks. I'm clearly angling for neophyte of the week here. I appreciate the first-principles feedback and code snippets.
Re: Using the standalone server
Using an atomic makes more sense. This class predates my reading of your book ;-) Although, looking at this again, I'm embarrassed to admit I'm not sure *why* synchronizing on incr doesn't do anything. Because I'm reassigning it? > Slight problem with newUniqueID(), though. Synchronizing on incr doesn't do > anything. How about using AtomicLong and masking out the high bits?
Re: Using the standalone server
On Tue, Sep 30, 2008 at 5:55 PM, Rob Heittman <[EMAIL PROTECTED]>wrote: > P.S. Since Restlet doesn't do it on its own yet, here's my browser > identity cookie generator: > > http://gogoego.googlecode.com/svn/trunk/modules/RestletFoundation/src/com/solertium/container/CookieUtility.java > Thanks for this! Slight problem with newUniqueID(), though. Synchronizing on incr doesn't do anything. How about using AtomicLong and masking out the high bits? --tim
Re: Using the standalone server
> I see that I am in fact using the Simple connector, as per the FirstResource > tutorial, I went out of my way to put its jar on the classpath. This > configuration is what I meant by 'standalone server'. I like Simple in concept, but I've had some not-so-wonderful experiences with it in practice. It also seems to be supported by a smallish team with limited resources. Jetty's been uniformly wonderful for us in production -- we were using it for embedded apps before we started working with Restlet, and I recommend it as both a Servlet and a Restlet container. But Jerome runs the Restlet and Noelios sites on Simple, so everyone's experiences do not match mine :-) > I'm just making this up as I go along, but I'm not opposed to learning > something in the process :-) So I had envisioned that my Restlet > application would have two logical clients: 1) the browser for some > requests, and 2) embedded Ajax for others. And I'm starting to wonder if I > can reconcile that bipartite model with a stateless server. It is challenging, but can be done. Let's see. The classic example of something very hard to implement without *some* server side state is an e-commerce shopping cart. There are a handful of examples on the web of a "purely RESTful shopping cart," but they tend to be a bit odd -- either in implementation or UI -- compared to the experience that folks have come to expect from something like Amazon.com. For example, one has you dragging things between frames, and if you click the Back button too many times, you lose your cart. Since odd experiences don't usually translate to sales, 99% or more of sites that provide a shopping cart, use some server side state tied to a browser identity cookie. But one way to RESTify this model, without changing it completely, is to deconstruct the idea of the "session" a bit. Instead of having one generalized server-side bag of state (the JSP/Servlet style HttpSession), which can only be accessed using server-side code, the client can use RESTful operations to create a needed resource on the server (e.g. a ShoppingCartResource); then these resources may be exposed back to the creator using RESTful patterns. This hypothetical ShoppingCartResource would have a URI and variant representations that can be PUT, GET, etc., including perhaps an HTML representation that is the full decorated "web page" representation for dumb-browser use, and a JSON or XML representation more suitable for AJAX interaction. It could be authenticated in some way, so that its contents were only mutable by the original creator (identified by a cookie or HTTP Basic, perhaps). Now you have your shopping cart abstracted in a way that you can work with it on the server side using internal requests (we use Restlet riap:// calls), OR work with it on the client side using an Applet, Flex/Flash RIA, GWT, or AJAX application. The philosophy behind all this is a bit head-twisting, but once I did it this way a few times, I never ever ever EVER wanted to go back to the "old" way! It is more up front work to decide I need a class of server-side resource, and work through how to handle it, rights and responsibilities, side effects of operations, etc. But, once I've done that, I'm DONE with the server architecture ... and the resource integrates with any kind of Web-based client, regardless of platform, language, etc. With the Servlet session model, it's so easy to throw things in the session bag, but then I need to invent ways of getting them out every time I want to move processing to the client. Net effect: with sessions, I don't wanna move any processing to the client. P.S. Since Restlet doesn't do it on its own yet, here's my browser identity cookie generator: http://gogoego.googlecode.com/svn/trunk/modules/RestletFoundation/src/com/solertium/container/CookieUtility.java - Rob
Re: Using the standalone server
Hi Mark, I'm just making this up as I go along, but I'm not opposed to learning something in the process :-) So I had envisioned that my Restlet application would have two logical clients: 1) the browser for some requests, and 2) embedded Ajax for others. And I'm starting to wonder if I can reconcile that bipartite model with a stateless server. I seem to recall reading something about this client side state in the O'Reilly book on RESTful web services. I should go back and read up on this. But frankly, the only state I had in mind to track at this point is whether the user is "logged in" or not. Any suggestions on how you fellows handle something simple like this would be much appreciated. HTTP supports authentication. This is also useable by a browser. If a browser requests a status 401 (authentication required), it opens a box, where the user could enter his username and password. The reason why this possibility is not used is IMO, that you can not use the corporate design in this box. The reason that it is not possible is, that the box looks always the same, so that the user will not enter his password in a box, where he is not sure, if it is the right. For this authentication type you could use the class org.retlet.Guard. Another possibilty is to set a cookie, which contains a value that the user is authenticated, and remove this cookie, if you log out. For now Restlet has no support for it, but there are plans for Restlet 1.2 to build a new security package in the API. I think, there should be a solution for this problem. best regards Stephan
Re: Using the standalone server
Thank you, Rob, Stephan. I'm triangulating as fast as I can, and appreciate your feedback. inline below... On Sep 30, 2008, at 12:16 PM, Rob Heittman wrote: If you mean the Net connector in Restlet 1.1 (which does not depend on any robust external HTTP connector), this is indeed only appropriate for development or lightly loaded scenarios. We use it for some production embedded applications, for example, some software that runs as a service and needs to trivially receive and emit HTTP requests for the local web server. But it does not compete with the capacity of the other connectors. We do use Restlet in "standalone mode" in many production applications, including our most heavily loaded multi-site client web servers. In terms of number of requests and sheer data volume, these are VERY active production services. However, by "standalone mode" here we mean not using the Net adapter, but rather using one of the other embedded connectors. Jetty is our favorite, as it is both lightweight and robust, and its NIO support is very good. Grizzly is looking promising for the future. Taking a look at this (which I discovered a few minutes ago) http://www.restlet.org/documentation/1.1/connectors I see that I am in fact using the Simple connector, as per the FirstResource tutorial, I went out of my way to put its jar on the classpath. This configuration is what I meant by 'standalone server'. As Stephan mentioned ... here we are deploying applications designed completely around the REST paradigm, the server does not keep any session state for the client. Clients are responsible for keeping their own state and transferring the relevant bits of it to the server when a request is made. This is an intentional design decision. We do set cookies for unique browser identification purposes, mainly for logging anonymous access. Intelligent clients are a great help in making this design work well (Java, AJAX, GWT, Flex/RIA, etc.). Much of the Servlet model, and the frameworks stacked upon it, consists of ingenious workarounds to make a web server capable of producing and managing all tiers of an application, given a very "dumb" HTML-and-forms based user agent on the other end of the HTTP connection. Unfortunately, this is hard on the server, decentralizes little of the computing load, and makes fielding a production web service much more expensive than it ought to be. I'm just making this up as I go along, but I'm not opposed to learning something in the process :-) So I had envisioned that my Restlet application would have two logical clients: 1) the browser for some requests, and 2) embedded Ajax for others. And I'm starting to wonder if I can reconcile that bipartite model with a stateless server. I seem to recall reading something about this client side state in the O'Reilly book on RESTful web services. I should go back and read up on this. But frankly, the only state I had in mind to track at this point is whether the user is "logged in" or not. Any suggestions on how you fellows handle something simple like this would be much appreciated. Mark - Rob On Tue, Sep 30, 2008 at 2:45 PM, Mark Petrovic <[EMAIL PROTECTED]> wrote: Good day. This is a well-intentioned albeit somewhat ignorant question: is anyone using the Noelios standalone server in a production scenario? I think of all the hundreds of person-years in something like servlet technology and wonder if the standalone server is more of a development tool than a production platform. If you're using the standalone server, how are you doing basic session management? With cookies? Thanks.
Re: Using the standalone server
If you mean the Net connector in Restlet 1.1 (which does not depend on any robust external HTTP connector), this is indeed only appropriate for development or lightly loaded scenarios. We use it for some production embedded applications, for example, some software that runs as a service and needs to trivially receive and emit HTTP requests for the local web server. But it does not compete with the capacity of the other connectors. We do use Restlet in "standalone mode" in many production applications, including our most heavily loaded multi-site client web servers. In terms of number of requests and sheer data volume, these are VERY active production services. However, by "standalone mode" here we mean not using the Net adapter, but rather using one of the other embedded connectors. Jetty is our favorite, as it is both lightweight and robust, and its NIO support is very good. Grizzly is looking promising for the future. As Stephan mentioned ... here we are deploying applications designed completely around the REST paradigm, the server does not keep any session state for the client. Clients are responsible for keeping their own state and transferring the relevant bits of it to the server when a request is made. This is an intentional design decision. We do set cookies for unique browser identification purposes, mainly for logging anonymous access. Intelligent clients are a great help in making this design work well (Java, AJAX, GWT, Flex/RIA, etc.). Much of the Servlet model, and the frameworks stacked upon it, consists of ingenious workarounds to make a web server capable of producing and managing all tiers of an application, given a very "dumb" HTML-and-forms based user agent on the other end of the HTTP connection. Unfortunately, this is hard on the server, decentralizes little of the computing load, and makes fielding a production web service much more expensive than it ought to be. - Rob On Tue, Sep 30, 2008 at 2:45 PM, Mark Petrovic <[EMAIL PROTECTED]> wrote: > Good day. > > This is a well-intentioned albeit somewhat ignorant question: is anyone > using the Noelios standalone server in a production scenario? I think of > all the hundreds of person-years in something like servlet technology and > wonder if the standalone server is more of a development tool than a > production platform. > > If you're using the standalone server, how are you doing basic session > management? With cookies? > > Thanks. > > >
Re: Using the standalone server
Hi Mark, If you're using the standalone server, how are you doing basic session management? With cookies? One of the basics of REST and also Restlet is, that the communication between client and server is stateless, that means that there are no session (for more details and reasons see http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3 and http://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch_styles.htm#sec_3_4_3). So we don't need session management. best regards Stephan
Spiky response time problem again
Hello, I notice there is similar problem just posted today. However, it doesn't seem to have answer yet. Please let me try again... My restlet application experiences uneven response time and for a while, the requests would choked then a big load got processed. In order to isolate the problem, I took away the logic inside the Resource. Now my Resource is as simple as parsing a JSON payload then set the response to successfully accepted. @Override public void post(Representation entity) { if (entity == null) { this.getResponse().setStatus(Status.CLIENT_ERROR_BAD_REQUEST); } else { try { Form form = new Form(entity); String payloadText = form.getFirstValue(PAYLOAD); if (StringUtils.hasText(payloadText)) { JSONObject payload = new JSONObject(payloadText); this.getResponse().setStatus(Status.SUCCESS_ACCEPTED); } else { this.getResponse().setStatus(Status.CLIENT_ERROR_BAD_REQUEST); } } catch (JSONException je) { this.getResponse().setStatus(Status.CLIENT_ERROR_BAD_REQUEST); } catch (Exception e) { this.getResponse().setStatus(Status.SERVER_ERROR_SERVICE_UNAVAILABLE); } } } My client sends 10 post request per second evenly. final ScheduledFuture testHandle = scheduler.scheduleAtFixedRate(tester, 5000, 100, java.util.concurrent.TimeUnit.MILLISECONDS); Periodically there were some requests taking very long. Here are some examples, the number is in milliseconds. A long request took 45008 A long request took 93003 A long request took 93001 A long request took 189002 A long request took 45001 The application is at java version "1.5.0_15", Restlet 1.0.9, Tomcat 6.0.16, Windows XP dual core. JAVA_OPTS=-server -showversion -Xms1g -Xmx1g -Xss512k -XX:+UseParallelGC -XX:+UseParallelOldGC -XX:ParallelGCThreads=4 -Djava.net.preferIPV4Stack=true -Dfile.encoding=UTF-8 I am not convinced GC is the reason. Because I have YourKit on the application, I don't see that every time when the request chokes, the GC is running. Please let me know what else I should looking for at YourKit. Thank you very much.
Using the standalone server
Good day. This is a well-intentioned albeit somewhat ignorant question: is anyone using the Noelios standalone server in a production scenario? I think of all the hundreds of person-years in something like servlet technology and wonder if the standalone server is more of a development tool than a production platform. If you're using the standalone server, how are you doing basic session management? With cookies? Thanks.
Re: Missing bytes in entity body
Hi Stephan Thanks for quick fix! It works now for me. At first I wasn't sure if JAX-RS was responsible, so I didn't mention it in the subject line. Cheers, Roman Stephan Koops wrote: Hi Roman, yes, you are right, this was a bug in the StringProvider. It's fixed in the trunk now. Does it work for you now? Sorry for the delay, because I have to do a lot of other things in the moment I do not read the mailing list emails fast. If you note in the subject that it's a problem for JAX-RS, than I will read it earlier perhaps. best regards Stephan Roman Geus schrieb: Hi Thierry To my knowledge my example uses only Restlet classes, i.e. javax.ws.rs.core.Response I think the problem could be in org.restlet.ext.jaxrs.internal.provider.StringProvider.getSize(...). It returns the number of characters, but the docs of javax.ws.rs.ext.MessageBodyWriter.getSize(...) say it should return the number of bytes in serialized form. Hope it helps, Roman Thierry Boileau wrote: Hi Roman, when I have a look at the source code of the StringRepresentation class, I notice that the length is computed on via the "getBytes" method which should calcute the correct length. I have a few questions: as I think that this code ("Response.ok().entity(result).build();") is certainly base on some of your own classes, we would like to know what kind of Representation are you using? Is it possible for you to update the character set of the returned representation and test with several charsets? Best regards, Thierry Boileau -- Restlet ~ Core developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com Hi all I have run across a problem, where the last few bytes of the entity body are not transferred to the client. The problem occurs if the number of characters in the entity body does not match the number of bytes in the encoded string (in my case UTF-8). Example 1: @GET @Produces("text/plain") public Response dsearch() { String result = "Romän"; return Response.ok().entity(result).build(); } Here Restlet sets the the Content-Length to 5, the client receives the bytes 122 157 155 303 244 (in octal) corresponding to the string "Romä". The last character "n" got lost. Restlet seems to set the Content-Length to the number of characters in the entity instead of to the number of bytes of the encoded string, causing the loss of trailing characters. Example 2: @GET @Produces("text/plain") public Response dsearch() { String result = "Romän"; return Response.ok().entity(result.getBytes()).build(); // note the getBytes() call } This case works fine: Restlet sets the the Content-Length to 6, the client receives the bytes 122 157 155 303 244 156 (in octal) corresponding to the full string "Romän". Is it a bug or a feature? Cheers, Roman
RE: [RFC] WadlResource, get a param value according to the description
Hi Jerôme, Sorry to answer so late, i'm a little busy :) I created the corresponding issue: http://restlet.tigris.org/issues/show_bug.cgi?id=604 > Actually, the template value should be "0;service=hihi" and not just > "hihi". > Isn't it? Actually, i expected "hihi", i believed ';' was a separator (the matrix separator) like '?' is the query separator. It seems I was wrong :) What do you think if we could "enable" the matrix separator in the template engine? (i dont know where, i dont know how). I know this separator is not part of the standard URI grammar... that's just an idea :) Best regards, -- Vincent Ricard
RE: Spiky behavior of restlet in Load test
Hi Prashant, You should indeed try using a profiler. Otherwise, try to isolate the cause of these spikes, for example replacing the Restlet-LDAP resources with mock resources and see how it affects the behavior. If this becomes very urgent or too complex to debug and figure out, we can help you through our consulting services: http://www.noelios.com/services/consulting Otherwise, if you think it is an issue inside Restlet code, try to isolate a reproducible sample and attach it to your reply or a new issue in the tracker. We'll look at it ASAP. 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 : news [mailto:[EMAIL PROTECTED] De la part de Prashant Envoye : mardi 30 septembre 2008 10:09 A : discuss@restlet.tigris.org Objet : Re: Spiky behavior of restlet in Load test Hi John, Thanks for response. please see answers inline. Have you run the server with a profiler attached (such as jprobe, yourkit, etc.)? {Prashant>>} No, we have not used any profiler tool yet. Are you load testing at a steady state? I.e., are you just running the same request over and over in a loop? Or something more complicated? {Prashant>>} Yes we are iterating over a simple Get request only using Jmeter. Are you on a single-core CPU for the test or one core for the load tester and one core for the server or what? I.e., what's your test setup? {Prashant>>} the test env is very high end machine. that is not a problem. What's your server setup? What version of the which JVM are you using, what flags, etc.? {Prashant>>} Server is tomcat 6, JVM version is 1.5.0_15 and flags are as given below: JAVA_OPTS="-XX:PermSize=128M -Xms1024M -Xmx1024M -verbose:gc" JAVA_OPTS="$JAVA_OPTS "-XX:+UseParallelGC Anyway, the short answer is very likely a GC issue. Whether or not there's much for you to do about will depend on all of the specifics. Use a profiler and find out. Full GC is not running very frequently as only 4-5 times in test of approx 4+ hrs Rest GC logs are as given below: [GC 229449K->26581K(920128K), 0.1256557 secs] [GC 227733K->24585K(910848K), 0.1229751 secs] [GC 223497K->26901K(911104K), 0.1219179 secs] [GC 223637K->27180K(912896K), 0.1182056 secs] [GC 221804K->24372K(906432K), 0.1202989 secs] [GC 216884K->26299K(903104K), 0.1210345 secs] [GC 216763K->27832K(906048K), 0.1120220 secs] [GC 216312K->28156K(900480K), 0.1164525 secs] [GC 214652K->28312K(901504K), 0.1143799 secs] [GC 212888K->25634K(893632K), 0.1180457 secs] [GC 208290K->26513K(897984K), 0.1151762 secs] [GC 207313K->27598K(891264K), 0.1144405 secs] [GC 206606K->28563K(893952K), 0.1090829 secs] [GC 205779K->29436K(889216K), 0.1105980 secs] [GC 204924K->29700K(889088K), 0.1341427 secs] [GC 203460K->30048K(885824K), 0.1077271 secs] Please help. Thanks Prashant
RE: Random Grizzly IOException
Hi Bruce, Thanks for the env details. It seems to be due to a null selector passed as a parameter to the register() method in ByteUtils. I've added an extra test in ByteUtils. It might either fully fix the problem or move it somewhere else. Could you test again with a recent snapshot? http://www.restlet.org/downloads/snapshot.zip Best regards, Jérôme Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : news [mailto:[EMAIL PROTECTED] De la part de Bruce Lee Envoyé : lundi 29 septembre 2008 16:40 À : discuss@restlet.tigris.org Objet : Re: Random Grizzly IOException Hi Jerome, My environment is as follows: OS: Windows XP Pro SP2 JVM: Java(TM) SE Runtime Environment (build 1.6.0_07-b06) Java HotSpot(TM) Client VM (build 10.0-b23, mixed mode, sharing) Regards, Jerome Louvel wrote: > Hi Bruce, > > Thanks for the reporting this new issue. I've entered a formal report: > > "NPE during NIO SelectableChannel.register" > http://restlet.tigris.org/issues/show_bug.cgi?id=603 > > As it looks like a JVM bug, it would be very useful if you could indicate > your OS, JVM version on the report. > > Best regards, > Jérôme Louvel > -- > Restlet ~ Founder and Lead developer ~ http://www.restlet.org > Noelios Technologies ~ Co-founder ~ http://www.noelios.com > > > -Message d'origine- > De : news [mailto:[EMAIL PROTECTED] De la part de Bruce Lee > Envoyé : vendredi 26 septembre 2008 18:39 > À : discuss@restlet.tigris.org > Objet : Re: Random Grizzly IOException > > Hi Jerome, > > I downloaded the Restlet 1.1 RC2 and although it seems to be much better > than before, under running the test with Jmeter, there is still > exceptions being thrown. The exception is as follows: > SEVERE: An exception occured writing the response entity > java.lang.NullPointerException > at > java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableC > hannel.java:180) > at > java.nio.channels.SelectableChannel.register(SelectableChannel.java:254) > at > org.restlet.util.ByteUtils$NbChannelOutputStream.doWrite(ByteUtils.java:261) > at > org.restlet.util.ByteUtils$NbChannelOutputStream.write(ByteUtils.java:294) > at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202) > at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:263) > at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:106) > at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:116) > at java.io.OutputStreamWriter.write(OutputStreamWriter.java:203) > at java.io.Writer.write(Writer.java:140) > at > org.restlet.resource.StringRepresentation.write(StringRepresentation.java:21 > 0) > at > org.restlet.resource.StreamRepresentation.write(StreamRepresentation.java:68 > ) > at > com.noelios.restlet.http.HttpServerCall.writeResponseBody(HttpServerCall.jav > a:491) > at > com.noelios.restlet.http.HttpServerCall.sendResponse(HttpServerCall.java:429 > ) > at > com.noelios.restlet.http.HttpServerConverter.commit(HttpServerConverter.java > :388) > at > com.noelios.restlet.http.HttpServerHelper.handle(HttpServerHelper.java:148) > at > com.noelios.restlet.ext.grizzly.HttpParserFilter.execute(HttpParserFilter.ja > va:78) > at > com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolCh > ain.java:137) > at > com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) > at > com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) > at > com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.jav > a:67) > at > com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56 > ) > at > com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:169) > Sep 26, 2008 12:35:53 PM com.noelios.restlet.LogFilter afterHandle > > Regards, > > Bruce Lee wrote: >> Hi Jerome, >> >> Thanks a lot for the timely fix! I'll be looking forward to test out the >> 1.1RC2. >> >> Regards, >> >> Jerome Louvel wrote: >>> Hi Bruce, >>> >>> Thanks a lot for sharing this test class. It helped me to fix the >>> remaining NIO exception that occured when the main selector was >>> exhausted. Now a new temporary selector is properly registered and >>> selected. Your test class works flawlessly! >>> >>> Please check in the upcoming 1.1 RC2. >>> >>> Best, >>> Jerome >>> >>> >>> Jerome Louvel a écrit : Hi Bruce, I've just fixed the Grizzly/NIO exception that occurred on Linux "Resource temporarily unavailable). This solves an issue that was reported by several persons and that we were experiencing as well. I suggest that you try again when 1.1 RC2 is released. Hopefully soon now. Best regards, Jérôme Louvel -- Restlet ~ Founder and Lead developer ~ http://www.
Re: Spiky behavior of restlet in Load test
Hi John, Thanks for response. please see answers inline. Have you run the server with a profiler attached (such as jprobe, yourkit, etc.)? {Prashant>>} No, we have not used any profiler tool yet. Are you load testing at a steady state? I.e., are you just running the same request over and over in a loop? Or something more complicated? {Prashant>>} Yes we are iterating over a simple Get request only using Jmeter. Are you on a single-core CPU for the test or one core for the load tester and one core for the server or what? I.e., what's your test setup? {Prashant>>} the test env is very high end machine. that is not a problem. What's your server setup? What version of the which JVM are you using, what flags, etc.? {Prashant>>} Server is tomcat 6, JVM version is 1.5.0_15 and flags are as given below: JAVA_OPTS="-XX:PermSize=128M -Xms1024M -Xmx1024M -verbose:gc" JAVA_OPTS="$JAVA_OPTS "-XX:+UseParallelGC Anyway, the short answer is very likely a GC issue. Whether or not there's much for you to do about will depend on all of the specifics. Use a profiler and find out. Full GC is not running very frequently as only 4-5 times in test of approx 4+ hrs Rest GC logs are as given below: [GC 229449K->26581K(920128K), 0.1256557 secs] [GC 227733K->24585K(910848K), 0.1229751 secs] [GC 223497K->26901K(911104K), 0.1219179 secs] [GC 223637K->27180K(912896K), 0.1182056 secs] [GC 221804K->24372K(906432K), 0.1202989 secs] [GC 216884K->26299K(903104K), 0.1210345 secs] [GC 216763K->27832K(906048K), 0.1120220 secs] [GC 216312K->28156K(900480K), 0.1164525 secs] [GC 214652K->28312K(901504K), 0.1143799 secs] [GC 212888K->25634K(893632K), 0.1180457 secs] [GC 208290K->26513K(897984K), 0.1151762 secs] [GC 207313K->27598K(891264K), 0.1144405 secs] [GC 206606K->28563K(893952K), 0.1090829 secs] [GC 205779K->29436K(889216K), 0.1105980 secs] [GC 204924K->29700K(889088K), 0.1341427 secs] [GC 203460K->30048K(885824K), 0.1077271 secs] Please help. Thanks Prashant
Re: Missing bytes in entity body
Hi Roman, yes, you are right, this was a bug in the StringProvider. It's fixed in the trunk now. Does it work for you now? Sorry for the delay, because I have to do a lot of other things in the moment I do not read the mailing list emails fast. If you note in the subject that it's a problem for JAX-RS, than I will read it earlier perhaps. best regards Stephan Roman Geus schrieb: Hi Thierry To my knowledge my example uses only Restlet classes, i.e. javax.ws.rs.core.Response I think the problem could be in org.restlet.ext.jaxrs.internal.provider.StringProvider.getSize(...). It returns the number of characters, but the docs of javax.ws.rs.ext.MessageBodyWriter.getSize(...) say it should return the number of bytes in serialized form. Hope it helps, Roman Thierry Boileau wrote: Hi Roman, when I have a look at the source code of the StringRepresentation class, I notice that the length is computed on via the "getBytes" method which should calcute the correct length. I have a few questions: as I think that this code ("Response.ok().entity(result).build();") is certainly base on some of your own classes, we would like to know what kind of Representation are you using? Is it possible for you to update the character set of the returned representation and test with several charsets? Best regards, Thierry Boileau -- Restlet ~ Core developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com Hi all I have run across a problem, where the last few bytes of the entity body are not transferred to the client. The problem occurs if the number of characters in the entity body does not match the number of bytes in the encoded string (in my case UTF-8). Example 1: @GET @Produces("text/plain") public Response dsearch() { String result = "Romän"; return Response.ok().entity(result).build(); } Here Restlet sets the the Content-Length to 5, the client receives the bytes 122 157 155 303 244 (in octal) corresponding to the string "Romä". The last character "n" got lost. Restlet seems to set the Content-Length to the number of characters in the entity instead of to the number of bytes of the encoded string, causing the loss of trailing characters. Example 2: @GET @Produces("text/plain") public Response dsearch() { String result = "Romän"; return Response.ok().entity(result.getBytes()).build(); // note the getBytes() call } This case works fine: Restlet sets the the Content-Length to 6, the client receives the bytes 122 157 155 303 244 156 (in octal) corresponding to the full string "Romän". Is it a bug or a feature? Cheers, Roman
Re: Spiky behavior of restlet in Load test
Have you run the server with a profiler attached (such as jprobe, yourkit, etc.)? Are you load testing at a steady state? I.e., are you just running the same request over and over in a loop? Or something more complicated? Are you on a single-core CPU for the test or one core for the load tester and one core for the server or what? I.e., what's your test setup? What's your server setup? What version of the which JVM are you using, what flags, etc.? Anyway, the short answer is very likely a GC issue. Whether or not there's much for you to do about will depend on all of the specifics. Use a profiler and find out. Have fun, John