Kalyan Akella | 1 Jan 03:10 2011
Picon

RE: Restlet for Android 2.0.3: Internal Connector Error (1002) - The calling thread timed out while waiting for a response to unblock it

Hi,

Here are the relevant app specific details that might be useful...

1. The call to the GAE service occurs on a java.lang.Thread with default
priority.
2. This thread is spawned & started inside the onStart method of my main
activity.
3. Meanwhile, I render a progress dialog on the UI thread.
4. Once the thread receives any response from the GAE service, it updates
the SharedPreferences with a certain value. If the call returns any error,
it logs this error and then updates SharedPreferences with a default value.
5. This causes my SharedPreferences listener to be invoked. It then cancels
the progress dialog and renders the main UI.

But, ever since I moved this service to GAE, the thread always returns with
the exception I mentioned in my first post. 

Am I doing something wrong here ? Please let me know if you need more
information.
Sincere Regards,
Kalyan Akella

--

-- 
View this message in context: http://restlet-discuss.1400322.n2.nabble.com/Restlet-2-0-3-Internal-Connector-Error-1002-The-calling-thread-timed-out-while-waiting-for-a-responst-tp5869419p5878524.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2695256

(Continue reading)

Anthony | 1 Jan 15:15 2011
Picon

What is best way for ServerResource to get DB connection?

I have a class that handles a pool of Oracle DB connections with methods to get and free (return to pool) a connection.

This connection pool class will be instantiated in my class that extends org.restlet.Application.

My question is how to make a connection availble to a ServerResource. Should it be injected or should
ServerResource reach out to Application.

Please provide some detail with response - for example, if it should be injected, how do I do that (via a
filter perhaps)?

Using Restlet 2.0.4

tia,
-Anthony

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2695318

Fabian Mandelbaum | 2 Jan 00:17 2011
Picon

Re: What is best way for ServerResource to get DB connection?

Hello Anthony,

I use a single(ton) SessionManager of sorts which 'serves' the
connections when asked, something like:

DBSessionManager.getInstance().getSessionRO();
DBSessionManager.getInstance().getSessionRW();

and of course, the corresponding:

DBSessionManager.getInstance().releaseSessionRO(session);
DBSessionManager.getInstance().releaseSessionRW(session);

that return the connections to the pool.

I use that approach with Apache's JackRabbit (not strictly a DB, but
it should be similar) and Apache's Commons Pool for the pool
implementation.

Hope this guides you in the correct direction.

On Sat, Jan 1, 2011 at 11:15 AM, Anthony <mambotx <at> yahoo.com> wrote:
> I have a class that handles a pool of Oracle DB connections with methods to get and free (return to pool) a connection.
>
> This connection pool class will be instantiated in my class that extends org.restlet.Application.
>
> My question is how to make a connection availble to a ServerResource. Should it be injected or should
ServerResource reach out to Application.
>
> Please provide some detail with response - for example, if it should be injected, how do I do that (via a
(Continue reading)

Tim Peierls | 2 Jan 06:03 2011
Picon

OutputRepresentation, internal connector, 2.1-M2

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 <jerome.louvel <at> noelios.com> wrote:
Your annotated method could look like:

<at> 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.

<at> Post("xml:pdf")
public OutputRepresentation submit(Document)

Best regards,
Jerome Louvel

-----Message d'origine-----
De : HT [mailto:hideki.tihiri <at> gmail.com]

Is there somewhere an example of how to send back a byte stream to the outputstream ?
webpost | 2 Jan 01:53 2011
Picon

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 'xxxxx.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

Anthony | 2 Jan 12:06 2011
Picon

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

Tim Peierls | 2 Jan 17:16 2011
Picon

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 <tim <at> peierls.net> 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 <jerome.louvel <at> noelios.com> wrote:
Your annotated method could look like:

<at> 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.

<at> Post("xml:pdf")
public OutputRepresentation submit(Document)

Best regards,
Jerome Louvel

-----Message d'origine-----
De : HT [mailto:hideki.tihiri <at> gmail.com]

Is there somewhere an example of how to send back a byte stream to the outputstream ?

Joe Dec | 2 Jan 17:21 2011
Picon

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.JacksonConverter <at> ..."

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

Jerome Louvel | 2 Jan 21:05 2011

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.o​rg
Noelios Technologies ~ http://www.noelios.com

-----Message d'origine-----
De : Tal Liron [mailto:tal.liron <at> threecrickets.com] 
Envoyé : vendredi 31 décembre 2010 17:11
À : discuss <at> 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 { <at> 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.o​rg Noelios 
> Technologies ~ http://www.noelios.com
>
>
>
>
>
> -----Message d'origine-----
> De : Rickard Öberg [mailto:rickardoberg <at> gmail.com] Envoyé : vendredi 
> 31 décembre 2010 03:18 À : discuss <at> 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

Jerome Louvel | 2 Jan 22:29 2011

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


Gmane