RE: Premature EOF / Broken Pipe
Hi Timothy, Were you able to make progress on this front? Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org/ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com/ http://www.noelios.com De : Timothy Aanerud [mailto:taane...@aticonsulting.com] Envoyé : vendredi 19 juin 2009 22:05 À : discuss@restlet.tigris.org Objet : Re: Premature EOF / Broken Pipe No, I haven't tried switching HTTP connectors. I get the same failures for both HTTP and HTTPS. In another experiement, I changed the client message frequency to ~1 second intervals and at this rate on both Windows XP and Fedora10/Linux show now problems with the server running on Fedora. The various frequencies and failure rates: 1 second == no problems 1.5 seconds == ~25% failure rate 5 seconds == ~25% failure rate 10 seconds == ~3% failure rate 180 seconds == 0.5%, if any failures I'll switch the HTTP connectors out one at a time and see what happens. -- Timothy Aanerud On Fri, Jun 19, 2009 at 2:02 PM, Jerome Louvel jerome.lou...@noelios.com wrote: Hi Timothy, This looks like a bug to me. Have you tried with different Restlet HTTP connectors (such as Jetty on the server-side and Apache HTTP client)? If you could send us a simple standalone test case, we could easily debug what's going bad. 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: Timothy Aanerud [mailto:taane...@aticonsulting.com] Envoy頺 vendredi 19 juin 2009 18:18 : discuss@restlet.tigris.org Objet: RE: Premature EOF / Broken Pipe As a test, I moved the client code to a Windows XP machine. With a five second update rate it fails regularly too, with the same exceptions and stack traces. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447 http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=23635 dsMessageId=23635 62 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447 http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2363638 dsMessageId=2363638 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2366260
RE: Problem Using proxy server for Restlet service
Hi Albert, As a workaround, if you use the HTTP client connector based on HttpURLConnection (org.restlet.ext.net), then you can use the proxy parameters via JVM system properties. 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 : Albert Newton [mailto:myname.wha...@gmail.com] Envoyé : lundi 22 juin 2009 04:12 À : discuss@restlet.tigris.org Objet : Problem Using proxy server for Restlet service Browsing through the forum and googling around, it seems like currently there is no way to make a client request through the proxy server for Restlets. Seems like according to the RFE submitted at this link: http://restlet.tigris.org/issues/show_bug.cgi?id=317, this issue is not expected to be solved until 2.0 5. Am i correct? Does that mean is there no way right now to use a proxy server for Restlets? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=23640 56 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2366263
RE: Restlet v 1.1.5 multiple times allow method checked
Hi Alin, The reason is simple: when a method is not allowed, HTTP expects the server to return the list of allowed methods, therefore the framework introspects the resource by calling allow*() methods. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.6 Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org/ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com/ http://www.noelios.com De : Alin Popa [mailto:alin.p...@gmail.com] Envoyé : mercredi 24 juin 2009 15:06 À : discuss@restlet.tigris.org Objet : Restlet v 1.1.5 multiple times allow method checked Hi, Very soon I noticed something strange(?) when using Restlet Resources: if a http method is not allowed, it will go and check all allow methods: e.g. When using DELETE http method and only POST is allowed, it will go and check allowDelete, allowGet, allowPut. Why is not doing just one check for allowDelete and stops ? Is this the normal behavior ? If yes, is there a way to suppress returned message within a Resource ? Thanks. -- Regards, Alin -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2366273
RE: Possible GAE Client issue.
Hi guys, By default, we leverage the HttpURLConnection class which has been reimplemented on top of URLFetcher so this should work. Thierry will finish his work on automated Restlet editions next week or so and we'll be able to resolve such issue more quickly and precisely. For now, I suggest to enter a bug report. 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:n...@ger.gmane.org] De la part de Philippe Marschall Envoyé : vendredi 26 juin 2009 07:14 À : discuss@restlet.tigris.org Objet : Re: Possible GAE Client issue. Matt wrote: Hi there, I'm getting the following error whenever I attempt to use the client class from within the GAE. Client client = new Client(Protocol.HTTP); Response response = client.get(http://www.google.com;); Internal Connector Error (1002) - access denied (java.net.SocketPermission www.google.com resolve) NB: I'm not using anything other than the default provided by restlet i.e. I'm not using apache's HttpClient. I've updated the gae jar to be the latest snapshot as of yesterday but I'm still getting this problem. Any suggestions? Or is it a potential bug? You're not allowed to open sockets on GAE/J. Cheers Philippe -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=23655 93 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2366277
Re: Premature EOF / Broken Pipe
I haven't tried switching HTTP connectors. :-( But, I did build a sanitized/stripped down example. Unfortunately, my example does not fail like my application does. One difference between my example is I'm only exchange data with one resource, In my actual application I'm sending two messages to two resources back-to-back before pausing. -- Timothy Aanerud taane...@aticonsulting.com On Mon, Jun 29, 2009 at 2:57 AM, Jerome Louvel jerome.lou...@noelios.comwrote: Hi Timothy, Were you able to make progress on this front? Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com *De :* Timothy Aanerud [mailto:taane...@aticonsulting.com] *Envoyé :* vendredi 19 juin 2009 22:05 *À :* discuss@restlet.tigris.org *Objet :* Re: Premature EOF / Broken Pipe No, I haven't tried switching HTTP connectors. I get the same failures for both HTTP and HTTPS. In another experiement, I changed the client message frequency to ~1 second intervals and at this rate on both Windows XP and Fedora10/Linux show now problems with the server running on Fedora. The various frequencies and failure rates: 1 second == no problems 1.5 seconds == ~25% failure rate 5 seconds == ~25% failure rate 10 seconds == ~3% failure rate 180 seconds == 0.5%, if any failures I'll switch the HTTP connectors out one at a time and see what happens. -- Timothy Aanerud On Fri, Jun 19, 2009 at 2:02 PM, Jerome Louvel jerome.lou...@noelios.com wrote: Hi Timothy, This looks like a bug to me. Have you tried with different Restlet HTTP connectors (such as Jetty on the server-side and Apache HTTP client)? If you could send us a simple standalone test case, we could easily debug what's going bad. 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: Timothy Aanerud [mailto:taane...@aticonsulting.com] Envoy頺 vendredi 19 juin 2009 18:18 : discuss@restlet.tigris.org Objet: RE: Premature EOF / Broken Pipe As a test, I moved the client code to a Windows XP machine. With a five second update rate it fails regularly too, with the same exceptions and stack traces. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=23635 62 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2363638 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2366382
Restlet trunk andd GWT issues...
Hello,
I am working with the GWT edition and trunk r5150 in order to get the recent
changes that fix content negotiation issues present in 2.0m3.
I have a simple GWT app loosely based upon the RestletGWTSimpleExample. I
notice that I cannot get my GWT app to run in hosted mode without changing the
source element in GWT.gwt.xml. The trunk version specifies:
source path=./
which causes a Non-canonical source path: ./ in the hosted mode browser
followed by numerous other derived errors. Changing the offending source
statement to:
source path=/
apparently solves the issue.
I have not been able to find RestletGWTSimpleExample in the svn sources or on
the site other than through the link provided. Obviously there have been
changes made in the callback mechanism between 2.0m3 and the trunk version.
Attempting the following:
// Add an AJAX call to the server
final Client client = new Client(Protocol.HTTP);
client.get(PING_URL, new Uniform() {
public void handle(Request request, Response response, Uniform
callback) {
pingText.setText(response.getEntity().getText());
}
});
gets me past compilation issues but results in an NPE:
[ERROR] Uncaught exception escaped
java.lang.NullPointerException: null
at
org.restlet.engine.http.HttpClientConverter$1.handle(HttpClientConverter.java:384)
at
org.restlet.engine.http.GwtHttpClientCall$2.onResponseReceived(GwtHttpClientCall.java:236)
at
com.google.gwt.http.client.Request.fireOnResponseReceivedImpl(Request.java:264)
So, I am wondering if I have the callback pattern properly coded, or maybe this
isn't yet ready for prime time?
Also, it would be helpful if the RestletGWTSimpleExample source was in the svn
trunk and updated along with the core.
Thanks for any help you can provide.
ba
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2366391
Re: Restlet v 1.1.5 multiple times allow method checked
Thanks Jerome, Now's more clear. On Mon, Jun 29, 2009 at 11:30 AM, Jerome Louvel jerome.lou...@noelios.comwrote: Hi Alin, The reason is simple: when a method is not allowed, HTTP expects the server to return the list of allowed methods, therefore the framework introspects the resource by calling allow*() methods. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.6 Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com *De :* Alin Popa [mailto:alin.p...@gmail.com] *Envoyé :* mercredi 24 juin 2009 15:06 *À :* discuss@restlet.tigris.org *Objet :* Restlet v 1.1.5 multiple times allow method checked Hi, Very soon I noticed something strange(?) when using Restlet Resources: if a http method is not allowed, it will go and check all allow methods: e.g. When using DELETE http method and only POST is allowed, it will go and check allowDelete, allowGet, allowPut. Why is not doing just one check for allowDelete and stops ? Is this the normal behavior ? If yes, is there a way to suppress returned message within a Resource ? Thanks. -- Regards, Alin -- Regards, Alin -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2366288
RE: Restlet trunk andd GWT issues...
FWIW, the following change in HttpClientConverter.java seems to fix the NPE:
public void commit(final HttpClientCall httpCall, Request request,
Response response, final Uniform userCallback) throws Exception {
if (httpCall != null) {
// Send the request to the client
httpCall.sendRequest(request, response, new Uniform() {
public void handle(Request request, Response response,
Uniform callback) {
updateResponse(response, httpCall);
userCallback.handle(request, response, null);
}
});
}
}
Hello,
I am working with the GWT edition and trunk r5150 in order to get the recent
changes that fix content negotiation issues present in 2.0m3.
I have a simple GWT app loosely based upon the RestletGWTSimpleExample. I
notice that I cannot get my GWT app to run in hosted mode without changing
the source element in GWT.gwt.xml. The trunk version specifies:
source path=./
which causes a Non-canonical source path: ./ in the hosted mode browser
followed by numerous other derived errors. Changing the offending source
statement to:
source path=/
apparently solves the issue.
I have not been able to find RestletGWTSimpleExample in the svn sources or on
the site other than through the link provided. Obviously there have been
changes made in the callback mechanism between 2.0m3 and the trunk version.
Attempting the following:
// Add an AJAX call to the server
final Client client = new Client(Protocol.HTTP);
client.get(PING_URL, new Uniform() {
public void handle(Request request, Response response, Uniform
callback) {
pingText.setText(response.getEntity().getText());
}
});
gets me past compilation issues but results in an NPE:
[ERROR] Uncaught exception escaped
java.lang.NullPointerException: null
at
org.restlet.engine.http.HttpClientConverter$1.handle(HttpClientConverter.java:384)
at
org.restlet.engine.http.GwtHttpClientCall$2.onResponseReceived(GwtHttpClientCall.java:236)
at
com.google.gwt.http.client.Request.fireOnResponseReceivedImpl(Request.java:264)
So, I am wondering if I have the callback pattern properly coded, or maybe
this isn't yet ready for prime time?
Also, it would be helpful if the RestletGWTSimpleExample source was in the
svn trunk and updated along with the core.
Thanks for any help you can provide.
ba
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2366513
GAE + Restlet issue
Hi there, I'm trying to use GAE and Restlet together. All works fine on the local development server. The first initial deploy to the live server worked fine. 1.latest.[applicationid].appspot.com works as expected. However on my subsequent deploys I keep getting: 1001.latest.[applicationid].appspot.com --- fails with the following error from the logs # org.restlet.Restlet handle: Unable to start the Restlet java.lang.NullPointerException at org.restlet.engine.component.ComponentHelper.checkVirtualHost(ComponentHelper.java:89) at org.restlet.engine.component.ComponentHelper.start(ComponentHelper.java:183) at org.restlet.Component.startHelper(Component.java:539) at org.restlet.Component.start(Component.java:513) at org.restlet.Restlet.handle(Restlet.java:172) at org.restlet.Component.handle(Component.java:394) at org.restlet.Server.handle(Server.java:350) at org.restlet.engine.ServerHelper.handle(ServerHelper.java:69) at org.restlet.engine.http.HttpServerHelper.handle(HttpServerHelper.java:149) at org.restlet.ext.servlet.ServerServlet.service(ServerServlet.java:932) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093) at com.google.apphosting.runtime.jetty.SaveSessionFilter.doFilter(SaveSessionFilter.java:35) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) at com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(TransactionCleanupFilter.java:43) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at com.google.apphosting.runtime.jetty.AppVersionHandlerMap.handle(AppVersionHandlerMap.java:237) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:313) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:830) at com.google.apphosting.runtime.jetty.RpcRequestParser.parseAvailable(RpcRequestParser.java:76) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381) at com.google.apphosting.runtime.jetty.JettyServletEngineAdapter.serviceRequest(JettyServletEngineAdapter.java:125) at com.google.apphosting.runtime.JavaRuntime.handleRequest(JavaRuntime.java:235) at com.google.apphosting.base.RuntimePb$EvaluationRuntime$6.handleBlockingRequest(RuntimePb.java:4755) at com.google.apphosting.base.RuntimePb$EvaluationRuntime$6.handleBlockingRequest(RuntimePb.java:4753) at com.google.net.rpc.impl.BlockingApplicationHandler.handleRequest(BlockingApplicationHandler.java:24) at com.google.net.rpc.impl.RpcUtil.runRpcInApplication(RpcUtil.java:359) at com.google.net.rpc.impl.Server$2.run(Server.java:800) at com.google.tracing.LocalTraceSpanRunnable.run(LocalTraceSpanRunnable.java:56) at com.google.tracing.LocalTraceSpanBuilder.internalContinueSpan(LocalTraceSpanBuilder.java:510) at com.google.net.rpc.impl.Server.startRpc(Server.java:756) at com.google.net.rpc.impl.Server.processRequest(Server.java:348) at com.google.net.rpc.impl.ServerConnection.messageReceived(ServerConnection.java:459) at com.google.net.rpc.impl.RpcConnection.parseMessages(RpcConnection.java:319) at com.google.net.rpc.impl.RpcConnection.dataReceived(RpcConnection.java:290) at com.google.net.async.Connection.handleReadEvent(Connection.java:419) at com.google.net.async.EventDispatcher.processNetworkEvents(EventDispatcher.java:762) at com.google.net.async.EventDispatcher.internalLoop(EventDispatcher.java:207) at com.google.net.async.EventDispatcher.loop(EventDispatcher.java:101) at com.google.net.rpc.RpcService.runUntilServerShutdown(RpcService.java:251) at com.google.apphosting.runtime.JavaRuntime$RpcRunnable.run(JavaRuntime.java:373) at java.lang.Thread.run(Unknown Source) # W 06-29 07:44PM 54.635 org.restlet.Restlet handle: Unable to start the Restlet # E 06-29 07:44PM 54.635 org.restlet.engine.ChainHelper handle: The org.restlet.Component class has no Restlet defined to process calls. Maybe it wasn't properly
