Lead ~ http://www.restlet.org
Noelios Technologies ~ http://www.noelios.com
-Message d'origine-
De : Thierry Boileau [mailto:thierry.boil...@noelios.com]
Envoyé : vendredi 9 avril 2010 13:35
À : discuss@restlet.tigris.org
Objet : RE: Re: Re: Re: Suspended thread doing Client.put
Hello,
in this case, the entity has been consumed, directly from the socket and cannot
be read again.
The benefit from this approach is that such representations (the class of the
representation should be InputRepresentation) has a minimal impact on memory
(the representation is not stored), bu
Two things -
1) Reproduce steps amendment:
- Start ProxyMain
Amendment: using args: 8181 http://localhost:8182/realserver
(The proxy port is 8181, real server is 8182)
2) I'm using the j2se edition
I think the issue might be related to representation.write() causing stream to
be null at some
I have a very similar issue with the simple attached code:
It happens with a POST in this case on the v2.0 RC2 (testing) codebase...I
thought this info might be useful for reproducing
1) Here I have a simple Restlet Server application which returns some hardcoded
xml
2) I write a little rest
Hi Thierry-
After switching to the HttpClient extension, the problem POST now
works. The service we're posting to is a sort of openID sign-in
aggregation service called rpxnow.com . (Basically they've done a
bunch of integrations with sign-in providers like google, yahoo,
twitter, facebook, et
Hello David,
Could you send the characteristics of the remote server, if possible?
As a workaround, you can still use the other client connectors (net,
httpclient). If it works with them, we're quite interested in the headers of
both request and response.
>Incidentally, this was a bit of a pai
Hi Jerome-
I did try a number of variations:
// My original code:
ClientResource res = new ClientResource(Method.POST, uri);
Representation entity = res.post(null);
// with an empty Representation:
ClientResource res = new ClientResource(Method.POST, uri);
Representation entity = res.post(new Em
avid Fogel [mailto:carrotsa...@gmail.com]
Envoyé : mercredi 24 mars 2010 20:33
À : discuss@restlet.tigris.org
Objet : Re: Re: Suspended thread doing Client.put
Hi all-
We've updated to the restlet trunk last night, but not successfully-
some or all (hard to tell yet) of our Client requests are h
Hi all-
We've updated to the restlet trunk last night, but not successfully-
some or all (hard to tell yet) of our Client requests are hanging with
the thread getting suspended during the latch.await() call in
BaseClientHelper.handle().
(Our project is a web-app that uses openid for federated sig
Hello all,
I've entered an issue for this bug:
http://restlet.tigris.org/issues/show_bug.cgi?id=1053.
As a workaround, you can use either the "net" or the "httpclient" client
extensions.
Best regards,
Thierry Boileau
--
http://restlet.tigris
If you just download the example sources from the FirstResource tutorial
http://www.restlet.org/documentation/2.0/examples/firstResource/sources.zip
http://www.restlet.org/documentation/2.0/firstResource
you'll get the same stalling / deadlock / whatever.
Any workaround?
Best regards, Klaas.
Jon's analysis looks right.
I don't really understand the BaseClientHelper, but it looks as though
handle() stashes the latch on the request, enqueues the response, and waits
for someone to open the latch. Both handleInbound and handleOutbound have
code to open the latch, but there are a lot of wa
I've been seeing hangs on GET, too. Unfortunately, can't provide debug
information for this particular project ... I hacked a quick workaround
to avoid it.
Seems to do with the fixes Thierry made to protocol handling.
On 03/03/2010 03:50 PM, webp...@tigris.org wrote:
> Jerome,
>
> I have the sa
Jerome,
I have the same problem and am running the 2.0m7 version. I can replicate the
problem with the sample resource code, using the sample client software, with
the resources hosted within a servlet container.
It appears that the client hangs on the Latch on the GET directly after a PUT
on
De : Thierry Boileau [mailto:thierry.boil...@noelios.com]
Envoyé : lundi 1 février 2010 12:28
À : discuss@restlet.tigris.org
Objet : Re: Suspended thread doing Client.put
Hi Jeff,
could make a test with the 2.0m7? It helpes to automatically release
connection once the entity has
Hi Jeff,
could make a test with the 2.0m7? It helpes to automatically release
connection once the entity has been handled.
Best regards,
Thierry Boileau
> Yes, we made sure to update and we did notice that there were recent
> changes to the latch code.
> -jeff
>
> "Thierry Boileau"
Yes, we made sure to update and we did notice that there were recent changes to
the latch code.
-jeff
"Thierry Boileau" wrote in message
news:4b62c277.1060...@noelios.com...
Hello Jeff,
did you try the latest snapshot (the internal connectors have been updated a
few days ago)?
Best r
Hello Jeff,
did you try the latest snapshot (the internal connectors have been
updated a few days ago)?
Best regards,
Thierry Boileau
> We're seeing the vm blocking forever on a call to Client.put that
> worked fine on an earlier release of 2.0-SNAPSHOT:
>
> Thread [main] (Suspended)
>
We're seeing the vm blocking forever on a call to Client.put that
worked fine on an earlier release of 2.0-SNAPSHOT:
Thread [main] (Suspended)
Unsafe.park(boolean, long) line: not available [native method]
LockSupport.park(Object) line: 158
CountDownLatch$Sync(
19 matches
Mail list logo