Re: Re: What is best way for ServerResource to get DB connection?
All reasonable advice, but if you're going to be doing this a lot, I highly
recommend using a dependency injection framework rather than explicit
singletons. I use Guice, but many people have reported great things of
Spring.
If you need to have your resource injected with dependencies that might be
singletons (and if you're willing to use Guice), you can use the code and
ideas that I've contributed to the Guice extension for Restlet. See
http://wiki.restlet.org/developers/257-restlet/284-restlet.html for more
information. This will let you write things like this:
public MyServerResource extends ServerResource {
@Inject public MyServerResource(DbSessionManager sessionMgr) {
this.sessionMgr = sessionMgr;
}
// ... service methods here using sessionMgr ...
private final DbSessionManager sessionMgr;
}
This gives you flexibility for later changing the scope of the session
manager.
--tim
On Sun, Jan 2, 2011 at 8:34 PM, Fabian Mandelbaum wrote:
> You are welcomed Anthony. Here you have some 'general' singleton
> coding that works 'everywhere' in Java:
>
> public class MySingleton {
>
> private static class MySingletonHolder {
>private static final MySingleton INSTANCE = new MySingleton();
> }
>
> private MySingleton() {
>// You'll do all initialization stuff, for example DB pools, here
> }
>
> public static MySingleton getInstance() {
>return MySingletonHolder.INSTANCE;
> }
>
> // Rest of the needed methods here (for example, to access the DB pools)
>
> }
>
> This coding uses William Pugh's "initialization on demand holder
> idiom" (no need for volatile/synchronized)
>
> Good luck.
>
> On Sun, Jan 2, 2011 at 8:06 AM, Anthony wrote:
> > Fabian,
> >
> > Being determined to accomplish the task via one of the methods I outlined
> in original post I completely neglected to consider this approach.
> >
> > I'll give the Singleton a go as time is slipping through my fingers.
> >
> > Thanks Fabian!!!
> >
> > --
> >
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2695430
> >
>
>
>
> --
> Fabián Mandelbaum
> IS Engineer
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2695561
>
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2695565
Re: Re: What is best way for ServerResource to get DB connection?
You are welcomed Anthony. Here you have some 'general' singleton
coding that works 'everywhere' in Java:
public class MySingleton {
private static class MySingletonHolder {
private static final MySingleton INSTANCE = new MySingleton();
}
private MySingleton() {
// You'll do all initialization stuff, for example DB pools, here
}
public static MySingleton getInstance() {
return MySingletonHolder.INSTANCE;
}
// Rest of the needed methods here (for example, to access the DB pools)
}
This coding uses William Pugh's "initialization on demand holder
idiom" (no need for volatile/synchronized)
Good luck.
On Sun, Jan 2, 2011 at 8:06 AM, Anthony wrote:
> Fabian,
>
> Being determined to accomplish the task via one of the methods I outlined in
> original post I completely neglected to consider this approach.
>
> I'll give the Singleton a go as time is slipping through my fingers.
>
> Thanks Fabian!!!
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2695430
>
--
Fabián Mandelbaum
IS Engineer
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2695561
Re: response.release() versus response.exhaust() in 2.0
So, what do you think about this pseudo-code to demonstrate the use of
ClientResource? (My experience has shown this to hang applications...)
function getText(url) {
var resource = new ClientResource(url)
var representation = resource.get()
if (representation) {
var text;
try {
text = representation.getText()
}
finally {
representation.exhaust()
}
return text
}
}
On Sun, Jan 2, 2011 at 3:29 PM, Jerome Louvel wrote:
> After further investigation of the source code, I rediscovered the main
> intent behind the Representation#release() method which is to provide a
> callback from the connectors to the representation that can be called when
> it has been fully written out, therefore allowing the release of associated
> resources such as database connections.
>
> Representations provided by the connectors themselves apparently don't rely
> on this method to be called as long as the content is fully read or
> exhausted, but it shouldn't hurt to call it systematically.
>
> I've revised the wiki page again as well as the Representation#release()
> Javadocs to further clarify those points.
>
> Best regards,
> Jerome
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2695526
>
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2695534
RE: response.release() versus response.exhaust() in 2.0
After further investigation of the source code, I rediscovered the main intent behind the Representation#release() method which is to provide a callback from the connectors to the representation that can be called when it has been fully written out, therefore allowing the release of associated resources such as database connections. Representations provided by the connectors themselves apparently don't rely on this method to be called as long as the content is fully read or exhausted, but it shouldn't hurt to call it systematically. I've revised the wiki page again as well as the Representation#release() Javadocs to further clarify those points. Best regards, Jerome -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2695526
RE: response.release() versus response.exhaust() in 2.0
Hi Tal,
The call to stop() is not necessary and was left from a previous version based
on the Client class. I've just fixed it. Regarding exhaust() behavior, a
significant change was made in version 2.0.0 based on David Fogel's feedback.
This method now systematically closes the underlying stream after eating all
the content.
Note that calling Response#release() currently only releases the entity if
available:
public void release() {
if (getEntity() != null) {
getEntity().release();
}
}
Regarding the proper way to close the underlying connection, it is in fact the
ClientResource#abort() or Request#abort() method that should be called. I've
clarified this in the wiki page:
http://wiki.restlet.org/docs_2.1/13-restlet/27-restlet/328-restlet/285-restlet.html
Best regards,
Jerome
--
Restlet ~ Founder and Technical Lead ~ http://www.restlet.org
Noelios Technologies ~ http://www.noelios.com
-Message d'origine-
De : Tal Liron [mailto:tal.li...@threecrickets.com]
Envoyé : vendredi 31 décembre 2010 17:11
À : discuss@restlet.tigris.org
Objet : Re: response.release() versus response.exhaust() in 2.0
I am a still unclear as to the best practice.
In the example you give on the wiki, you call stop() on the resource, and there
is no try/catch, but you do not mention whether using stop() is a good idea.
In relation to the last paragraph -- my experience has shown that
exhaust() is not good enough (Restlet 2.0.x, Apache HTTP Client), and still
leads to hanging threads. Even calling release() on the representation is not
good enough. I found that the only way to avoid hangs is a complete release()
of the *response*, and I found this out only through searching in the mailing
list. While this does avoid hanging my application, it seems like this is not
recommended. Can you clarify?
-Tal
On 12/31/2010 03:39 AM, Jerome Louvel wrote:
> Hi all,
>
> I've updated the wiki to clarify this best practice, see the last section:
> http://wiki.restlet.org/docs_2.0/285-restlet.html
>
> The Javadocs have also been previously clarified before, saying that
> release() should rarely be called:
> http://www.restlet.org/documentation/2.0/jee/api/org/restlet/represent
> ation/Representation.html#release%28%29
>
> I've clarified this even further in SVN (2.0 and trunk) by adding this
> paragraph:
> * Note that calling this method will likely prevent the reuse of the
> * underlying persistent connection and therefore should only be called
> when
> * exhausting the content with {...@link #exhaust()} is too costly or
> when
> * further calls from the client are not welcome.
>
> Hope this clarifies. We can update the wiki/javadocs further based on your
> experienced. If one connector such as Apache HTTP Client 4 doesn't work
> consistently with this description, we can try to fix it.
>
> Best regards,
> Jerome
> --
> Restlet ~ Founder and Technical Lead ~ http://www.restlet.org Noelios
> Technologies ~ http://www.noelios.com
>
>
>
>
>
> -Message d'origine-
> De : Rickard Öberg [mailto:rickardob...@gmail.com] Envoyé : vendredi
> 31 décembre 2010 03:18 À : discuss@restlet.tigris.org Objet : Re:
> response.release() versus response.exhaust() in 2.0
>
> On 2010-12-31 05.55, Tal Liron wrote:
>> pool.) It's probably best to employ a try-finally paradigm, where the
>> try clause contains as little code as possible, and the finally
>> clause releases the response. See the example below.
>>
>> var fixture
>> var resource =
>> document.external('file:///myfiles/fixture.json','application/json')
>> try {
>> fixture = resource.get().text
>>
>> }
>> finally {
>> resource.response.release()
>> }
> So this, combined with Jerome's reply:
>> >> 1) release() has the effect of closing the underlying TCP
>> socket, preventing persistent connection reuse. So it can't be
>> recommended to systematically call it.
> basically means that we can't have persistent connection reuse on the client.
> Correct or not?
>
> /Rickard
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId
> =2695100
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId
> =2695151
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2695206
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2695509
RE: Post method not work when deployed to GAE
Hi Orville, I am not sure if all the links you provided are directly linked to the problem : no deserialization of JSON-Data on POST/PUT-Methods. But I might be wrong here. Anyway : this issue will be looked into soon, hopefully: http://restlet.tigris.org/issues/show_bug.cgi?id=1219 - you might want to register yourself to the issue to receive updates. Back to the issue: the bad thing is that there are no error messages on the GAE side. The data is just not deserialized (parameter == null) when originating from a restlet client (JSE and Android). This means that I cannot provide additional error information to the resolvers. What I noticed also is that the JacksonConverter is not selected. If I "curl" a POST then the deserialization works and the Converter is resolved: "org.restlet.service.ConverterService toObject: The following converter was selected for the [application/json] representation: org.restlet.ext.jackson.jacksonconver...@..." With the restlet clients, to above converter selection output won't appear. When I compared the "curl"-Request and the restlet-Request, I noticed some differences in the HTTP-Headers. That might be a starting point for the devs. Though, as Jerome pointed out - it's holiday time ... so we should be patient. Cheers, Joe -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2695474
Re: OutputRepresentation, internal connector, 2.1-M2
I had a similar problem with returning new InputRepresentation(inputStream,
size) when inputStream came directly from a JClouds Blob with more than a
few thousand bytes. Reading the blob content into a buffer first and
constructing a ByteArrayInputStream on that buffer fixed the problem.
It appears that the new internal NIO-based connector is still a bit shaky. I
suspect this is something that, due to the nature of NIO vs. BIO, will never
be completely transparent, so the best we can do is document the best
practices and warn about fragile constructs.
Or have I missed an existing documentation page that says all this already?
That said, I'm delighted to have found these workarounds! In short: With the
internal NIO connector, prefer (InputRepresentation of) InputStreams based
on in-memory buffers to OutputRepresentations.
--tim
On Sun, Jan 2, 2011 at 12:03 AM, Tim Peierls wrote:
> I had a resource supporting GET with application/pdf implemented using
> OutputRepresentation that was working in 2.0.mumble with the internal
> connector. Using 2.1-M2, though, the internal connector only sends the first
> 250 bytes or so of about 4500 bytes total.
>
> The code looked like this:
>
> final ByteArrayOutputStream bytes = ...;
> // generate PDF into bytes
> bytes.flush(); // didn't make any difference whether I flushed it or
> not
> return new OutputRepresentation(MediaType.APPLICATION_PDF,
> bytes.size()) {
> public void write(OutputStream os) {
> bytes.writeTo(os);
> }
> });
>
> When I switched to returning InputStream, as in the POST discussion below,
> it works fine.
>
> I'll continue to use InputStream, but why would OutputRepresentation's
> behavior suddenly change?
>
> --tim
>
>
> On Fri, Jul 2, 2010 at 11:50 AM, Jerome Louvel
> wrote:
>
>> Your annotated method could look like:
>>
>> @Post("xml:pdf")
>> public InputStream submit(Document)
>>
>> If you can't return an InputStream, then you need to return
>> an OutputRepresentation, overriding its write(OutputStream) method.
>>
>> @Post("xml:pdf")
>> public OutputRepresentation submit(Document)
>>
>> Best regards,
>> Jerome Louvel
>>
>> -Message d'origine-
>> De : HT [mailto:hideki.tih...@gmail.com]
>>
>> Is there somewhere an example of how to send back a byte stream to
>> the outputstream ?
>>
>
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2695473
RE: Re: What is best way for ServerResource to get DB connection?
Fabian, Being determined to accomplish the task via one of the methods I outlined in original post I completely neglected to consider this approach. I'll give the Singleton a go as time is slipping through my fingers. Thanks Fabian!!! -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2695430
RE: Post method not work when deployed to GAE
Hi Joe, I don't have a solution for you but I have been having the same problem. In my search through the forums, I noticed that several others have reported similar problems in recent weeks: http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&viewType=browseAll&dsMessageId=2668196#messagefocus http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&viewType=browseAll&dsMessageId=2693988#messagefocus http://wiki.restlet.org/docs_2.0/13-restlet/21-restlet/318-restlet/303-restlet.html - comment #6 I have also tried several different Restlet JARs on both the Android client and GAE server to no avail. I wonder if anyone would be kind enough to post a turn-key Eclipse Android project folder along with an Eclipse GAE project folder so that us Restlet noobs would only need to change an 'x.appspot.com' value to get the sample working on our own machines. I would be willing to help maintain a project on code.google.com for it. It would be good to work with the others having the same problem. Cheers, Orville -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2695365
