RE: Resources and concurrency
Hi Paul, You correctly described the intended behavior. If you can find the root cause of the bottleneck you observed, please let us know. Best regards, Jerome -Message d'origine- De : Paul Kaiser [mailto:[EMAIL PROTECTED] Envoyé : mercredi 17 octobre 2007 22:22 À : Discuss Restlet Objet : Resources and concurrency I have a service implemented using Resource subclasses with a custom Finder subclass to instantiate the Resources. I noticed that if I make concurrent requests for the same URI, there is something before my Finder that is queuing the requests and dispatching them one at a time to the Finder. If the URI is different (but maps to the same Resource type) then the requests are processed concurrently. Is this the intended behavior? I realize that Resources are not supposed to be thread-safe, but we should be able to process concurrent requests for the same resource as long as Finder.createResource() is called every time. Did I miss something? Thanks, Paul __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: client side content negotiation
Hello Henry, this kind of properties is not set on the client (or instances of Client class), but on the request sent by the client. the following instruction set the preference for media type application/rdf+xml with the default quality (1 actually): request.getClientInfo().getAcceptedMediaTypes().add(new PreferenceMediaType(MediaType.APPLICATION_RDF_XML)); You can also use this constructor: Preference(T metadata, float quality) [1] best regards, Thierry Boileau [1] see http://www.restlet.org/documentation/1.0/api/org/restlet/data/Preference.html Sorry to ask a basic question here. I could not find a simple answer in the doc. I would like to specify that my client prefers certain mime types over others. So I would like to set the Accept header. With the java.net framework I would just do this: URLConnection conn = idurl.openConnection(); conn.addRequestProperty(Accept, application/rdf+xml, text/ html; q=0.2); how do I do this in Restlets? It would be nice to also be able to specify some default consumers of the different representations... Henry Home page: http://bblfish.net/ Sun Blog: http://blogs.sun.com/bblfish/ Foaf name: http://bblfish.net/people/henry/card#me
Re: HEAD not well supported?
Jerome Louvel contact at noelios.com writes: Hi all, Thanks for the quality of the feed-back. I feel like I'm now grasping all aspects of the problem and can propose a solution: 1) Split the Resource class into an abstract Handler class and a Resource subclass Hi Jerome, What is the motivation of the Handler class? I have no problem with it, I just want to understand. Is it merely to be explicit about lower level API and higher level, or is there more to it? 4) Resource offers a higher-level API that, as Tim said, is easier to use to map to domain objects, handles content negotiation, conditional methods. - handleGet() is implemented based on the variants property, the getPreferredVariant() and getRepresentation(Variant) methods - handlePost() is implemented by calling an acceptRepresentation(Representation) method to match the REST/HTTP 1.1 terminology and have less parallel names. - handlePut() is implemented by calling a storeRepresentation(Representation) method to match the REST/HTTP 1.1 terminology and have less parallel names. - handleDelete() is implemented by calling a deleteAll() or delete() or removeAll() or remove(). I like the idea of mapping well to the REST terminology. Feed-back welcome. It seems alright but there's enough there that I hesitate to endorse whole- heartedly without trying it out. That's when I usually can establish my comfort level best. Best regards, Jerome Sean
RE: EncodeRepresentation.write leaving blocked threads around?
Hi Tim, Thanks again for the suggestion about the queue. That makes total sense. I've just applied the changes to SVN. Best regards, Jerome -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Tim Peierls Envoyé : mercredi 17 octobre 2007 23:41 À : discuss@restlet.tigris.org Objet : Re: EncodeRepresentation.write leaving blocked threads around? On 10/17/07, Jerome Louvel [EMAIL PROTECTED] wrote: In terms of end to end functionality, our use of GZip encoding works fine and the encoded representations make it from client to server OK, so the concern is simply that there end up being hundreds of these dead corpse threads left over as our software runs for longer. As suggested by Tim, I have added an explicit call to setDaemon(false) in the ByteUtils class, before starting the IO threads. I hope that this can workaround the issue. I think it's good practice to setDaemon(false) as you've done -- though I still would like to know *why* the threads in Matthew's example have daemon status -- but I don't think it will solve Matthew's problem, which is that large numbers of permanently blocked threads are accumulating over long server runs. (The only difference between daemon threads and user threads is that the former don't prevent a JVM from exiting.) I can't think of an explanation for the platform-specific behavior, but it appears that somehow the underlying queue is blocking forever on a put. A simple way to avoid this without having to understand why it is happening is to use queue.offer(byte, timeout, unit) instead of queue.put(byte), throwing IOE if offer fails. Pick the timeout to give the input stream consumer ample time to kick in; some number of seconds, say. Then at least these threads will eventually go away. Likewise, on the input stream side you could use queue.poll(timeout, unit) instead of queue.take(), throwing IOE if the poll fails. Again, pick a timeout to give ample time for the representation to be encoded and partly enqueued. A more robust approach might involve using an ExecutorService to execute the writer tasks asynchronously, instead of explicity creating a Thread. But that's a bigger project that should probably wait until Matthew's issue is resolved. --tim
RE: HEAD not well supported?
Hi Sean, What is the motivation of the Handler class? I have no problem with it, I just want to understand. Is it merely to be explicit about lower level API and higher level, or is there more to it? Exactly, the goal is to clarify the separation between the lower API and higher one. The Handler class will be in org.restlet and Finder won't have any direct knowledge of the Resource class. It could be used directly for those preferring to work at this level. In term of Javadocs, that will also make things much easier to explain. It seems alright but there's enough there that I hesitate to endorse whole- heartedly without trying it out. That's when I usually can establish my comfort level best. Fair enough, I've got most of the changes done locally now. I will try to commit them in the coming days. Best regards, Jerome
Re: HEAD not well supported?
Sean Landis sean.landis at gmail.com writes: Jerome Louvel contact at noelios.com writes: Hi all, Thanks for the quality of the feed-back. I feel like I'm now grasping all aspects of the problem and can propose a solution: 1) Split the Resource class into an abstract Handler class and a Resource subclass Hi Jerome, What is the motivation of the Handler class? I have no problem with it, I just want to understand. Is it merely to be explicit about lower level API and higher level, or is there more to it? So what's the difference between a Handler and a Finder? The flow of the request would go through the following after this refactoring. Server - Component - Application - Router - Finder - Handler - Resource - Domain Object I'm trying to understand the separation-of-concern/value-add that each layer offers. Thanks. Sumit
