Spiky behavior of restlet in Load test
Hi All, I have a small problem which may be big (:)) internally. Actually, I am load testing a Restlet application which takes some request parameters as input, makes a LDAP query and returns data as an XML in response. So, what happening in this load test is Spiky behavior of CPU. CPU utilization shoots upto 90% from 20% at regular intervals i.e. 28 seconds. After doing some googling I found that these spikes may be due to GC process but this reason does not seem to be satisfying. Can somebody explain me the reason of this spiky behavior of CPU? Hoping for some response from all of you guys. Thanks Prashant
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
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
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.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 19 septembre 2008 20:43
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: [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: 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
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.
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.
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
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
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
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
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
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
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
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?
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: 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:
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
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:
