Re: Restlet 2.2.2, Jetty 8.1, disable SSLv3
Jared,
The additional "disabledPrototols" parameter worked for me. But I also
set the list of enabled ciphers with this:
private static String _mediumStrongCiphers =
// A list found on jetty website 25-Oct-2014
"TLS_DHE_DSS_WITH_AES_128_CBC_SHA " +
"TLS_DHE_RSA_WITH_AES_128_CBC_SHA " +
"TLS_DHE_DSS_WITH_AES_256_CBC_SHA " +
"TLS_RSA_WITH_AES_128_CBC_SHA " +
"TLS_DHE_RSA_WITH_AES_256_CBC_SHA " +
"TLS_RSA_WITH_AES_256_CBC_SHA";
parameters.add("enabledCipherSuites", _mediumStrongCiphers);
--
Timothy
On 10/22/2014 7:35 PM, Jared Davis wrote:
> Hi,
>
> What is the correct way to disable SSLv3 with Jetty 8.1?
>
> I've tried disabledProtocols but it seems to have no effect.
>
> Server server = component.getServers().add(Protocol.HTTPS, ip, port);
> server.getContext().getParameters().add("keystorePath", keyPathname);
> server.getContext().getParameters().add("keystorePassword",
> storepass);
> server.getContext().getParameters().add("keyPassword",keypass );
> server.getContext().getParameters().add("disabledProtocols",
> "SSLv3");
>
> Thanks,
>
> Jared
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=3090338
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=3090439
Re: lib/org.restlet.ext.ssl.jar missing from 2.2.2 zip
Robert,
PkixSslContextFactory has moved to org.restlet.ext.jsslutils.jar
Check your start up code, do you have a line like this:
parameters.add("sslContextFactory",
"org.restlet.ext.ssl.PkixSslContextFactory");
Either comment out this line or fix the package name here.
--
Timothy Aanerud
On 8/20/2014 1:39 PM, Robert Barnett wrote:
> The 2.2.2 documentation states that to enable https one must add
> lib/org.restlet.ext.ssl.jar to the class path. (source:
> http://restlet.com/learn/guide/2.2/core/security/https) But no such jar
> appears in the distribution. Omitting this jar appears to lead to the
> runtime exception:
>
> java.lang.ClassNotFoundException: org.restlet.ext.ssl.PkixSslContextFactory
>
> Please advise.
>
> Thanks.
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=3086969
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=3086973
Re: Enable only selected cipher suites
Enoch,
What operating system, version of Java are you using, and what version
of Jetty and Restlet are you using?
What you're doing should work. My server application does something
very similar. One thing to be aware of is the names of the ciphers.
OpenSSL uses different names than Java uses.
This is my list of weak ciphers:
private static String _weakCiphers =
"EXP-EDH-RSA-DES-CBC-SHA EXP-DES-CBC-SHA EXP-RC4-MD5 " +
"EDH-RSA-DES-CBC-SHA EXP-DES-CBC-SHA EXP-RC4-MD5 ";
This is my list of acceptable ciphers:
private static String _mediumStrongCiphers =
"SSL_RSA_WITH_RC4_128_MD5 " +
"SSL_RSA_WITH_RC4_128_SHA " +
"TLS_RSA_WITH_AES_128_CBC_SHA " +
"TLS_RSA_WITH_AES_256_CBC_SHA " +
"TLS_DHE_RSA_WITH_AES_128_CBC_SHA " +
"TLS_DHE_RSA_WITH_AES_256_CBC_SHA " +
"TLS_DHE_DSS_WITH_AES_128_CBC_SHA " +
"TLS_DHE_DSS_WITH_AES_256_CBC_SHA " +
"SSL_RSA_WITH_3DES_EDE_CBC_SHA " +
"SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA " +
"SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA " +
"SSL_DHE_DSS_WITH_DES_CBC_SHA";
Some of the HTTP connector packages understand disabling ciphers, some
understand enabling listed ciphers.
My server application runs on Ubuntu 10.04 LTS using openJDK 6, and I'm
still using Restlet 1.1.7. Yes, I know I should upgrade... Sometime in
March 2012 there was a OpenJDK6 update that effected my ability disable
weak ciphers using Jetty. I ended up switching my HTTP connector to
Grizzly and that made things work again.
--
Timothy Aanerud
On 6/20/2012 8:56 PM, Enoch wrote:
> Im using Restlet with embedded Jetty. I have a requirement of being able to
> enable only selected cipher suites.
>
> I primarily use embedded Jetty anyway I have also tried Simple HTTP Server
> but both does not appear to work. I am unable to find any examples in this
> regard.
> Even Restlet In Action book did not have any info in this regard. Any help
> will be greatly Any help will be greatly appreciated..
>
> Server Code for embedded Simple HTTP Server(Similar code for JETTY was tried)
>
>
> org.restlet.Server serverObj = new
> org.restlet.Server(Protocol.HTTPS);
>
> HttpServerHelper serverHelper = new HttpServerHelper(
> serverObj);
> Engine.getInstance().getRegisteredServers().add(0,
> serverHelper);
>
> org.restlet.Component component = new Component();
> org.restlet.Server server =
> component.getServers().add(Protocol.HTTPS,8080);
> component.getDefaultHost().attach(vtnURLResource, new
> VTNApplication());
>
> org.restlet.ext.simple.HttpsServerHelper httpsServerHelper =
> new HttpsServerHelper(server);
> Context workingCtx = serverHelper.getContext();
>
> workingCtx.getParameters().add("disabledCipherSuites",
>
> "SSL_RSA_WITH_RC4_128_MD5 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
> TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA ..");
> workingCtx.getParameters().add("enabledCipherSuites",
> "SSL_RSA_WITH_RC4_128_SHA");
> workingCtx.getParameters().add("sslContextFactory",
>
> "org.restlet.engine.security.DefaultSslContextFactory");
>
> workingCtx.getParameters().add("keystorePath",
>
> "C:\\openadrkeystore\\bouncykeys\\VTN_QLI.bks");
> workingCtx.getParameters().add("keystorePassword", "password");
> workingCtx.getParameters().add("keystoreType", "BKS");
> workingCtx.getParameters().add("keyPassword", "password");
>
> workingCtx.getParameters().add("truststorePath",
> "C:\\Program
> Files\\Java\\jre6\\lib\\security\\cacerts");
> workingCtx.getParameters().add("truststorePassword",
> "changeit");
>
> workingCtx.getParameters().add("needClientAuthentication",
> "true");
>
> component.start();
>
>
>
> Client Code
> -
Re: Broken pipe / Unexpected end of file from server Problem
I end up switching HTTP connectors to solve my problem. In my scenario I have client application running on Fedora using restlet using the Apache HTTP connector that talks to a restlet server running on Ubuntu using the Grizzly HTTP connector. The conditions you are describing are match what I was experiencing. Switching to the Apache HTTP connector on the client side solved my problem. I think I have since fixed a bug in my code where I wasn't completely consuming the input stream in all cases. But, I doubt that was my original problem. -- Timothy On Fri, Sep 10, 2010 at 3:28 AM, Achim W. wrote: > Hi! > > Using Restlet 1.1.10, Sun Java 6, tested on Windows XP/Debian/Ubuntu. > > I found a problem in NET client connector. Sometimes there is a Exception > with messages: > - java.io.IOException: Broken pipe (Server) > - java.net.SocketException: Unexpected end of file from server (Client) > > When using the standard(?)/fall-back(?) Connector (i.e > "com.noelios.restlet.http.StreamClientHelper", NET .jar _not_ in the > classpath) there is no problem. > > When using the NET Connector (i.e. > "com.noelios.restlet.ext.net.HttpClientHelper", NET .jar in the classpath) > then every second request fails if there is a specific time (~2 - ~5 > seconds) between the current and the previous request. It seems the server > closes the connection after ~2(?) seconds after the last request/response > which answers the client with FIN. But the client does not really close the > connection within ~5 seconds. If the next request is within those 5 seconds > the client tries to reuse the old (already closed by server) connection. > > This problem exist in NET connector when using HTTP and when using HTTPS. > Standard connector has no problem when using HTTP, HTTPS is not supported by > standard connector. > > I found another post of a user with the same problem but he couldn't > reproduce it (outside of his production environment): > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2363539 > > I have written sample programs for server/client which show the issue. When > using 0msec and 5200msec between request there is no problem, when using > 2000msec the exception occurs every second request. > > Attached are the sample programs as eclipse projects and traces of > HTTP+standard connector, HTTP+NET connector and HTTPS+NET connector. > To use the NET connector just remove the NET lib from the build path of the > client project. > > best regards > Achim > > -- > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2657466 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2659656
Re: Re: Redirect Restlet console statements to an external log file using log4j.properties
Try again... It only takes one additional import, one line of code and three additional jar files to get Restlet outputs merged into log4j. After you initialize Log4j, add this line of code: SLF4JBridgeHandler.install() These are the three additional jars: - jul-to-slf4j-1.5.8.jar -- Converts JUL to slf4j format - slf4j-api-1.5.8.jar -- base classes for SLF4J - slf4j-log4j12-1.5.8.jar -- converts SLF4J to log4j The JUL output will still be be there on standard out and standard err, but everything will be merged into your log4j logs. -- Timothy On Mon, Oct 19, 2009 at 12:01 AM, Ty wrote: > Hi, > I had a look at the user guide for v1 and v2 and am still a bit confused > about getting the Restlet logs to be processed by my application i.e. end up > in my log files. My application uses log4j. > > I followed the lin kto the slf4j website and couldn't find anything on a > JUL to log4j brudge. It looks like they have a JUL to slf4j bridge though. > > Is my newb'ness the problem? Could someone spell it out slowly for me :) > > > Thanks, > Ty > > -- > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2408822 > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2409215
Re: Re: Redirect Restlet console statements to an external log file using log4j.properties
It only takes one additional import and one line of code plus 3 jar files to get Restlet console messages logged. After you have setup log4j add the line On Mon, Oct 19, 2009 at 12:01 AM, Ty wrote: > Hi, > I had a look at the user guide for v1 and v2 and am still a bit confused > about getting the Restlet logs to be processed by my application i.e. end up > in my log files. My application uses log4j. > > I followed the lin kto the slf4j website and couldn't find anything on a > JUL to log4j brudge. It looks like they have a JUL to slf4j bridge though. > > Is my newb'ness the problem? Could someone spell it out slowly for me :) > > > Thanks, > Ty > > -- > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2408822 > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2409208
RE: Re: Disabling weak ciphers in Restlet
Thanks!
Three comments:
1. I ended up using
parameters.add("enabledCipherSuites", aStringOfCiphers)
At this level the ciphers are in a single string separated by a space. They
eventually end up as array
2. I wasn't able to use "disabledCipherSuites" because deep down in
HttpsServerHelper.start() it takes the list of enabled ciphers converts it from
String[] to List then starts removing the the disabled ones. After
removing items the List is converted back to a String[].
But this conversion didn't work correctly:
enabledCipherSuites = enabledCipherSuitesList
.toArray(enabledCipherSuites);
enabledCipherSuites started with 18 elements, I removed the last for, and when
inspected the final result, the String array still had 18 elements, but the
14th one was null. The call to
serverSocket.setEnabledCipherSuites(enabledCipherSuites); fails due to a null.
3. The names of Ciphers reported by OpenSSL are not the same as the ones
reported by HttpsUtils.getEnabledCipherSuites(); In my case I'm use the
SimpleHTTP server. By some trial and error testing I was able to identify the
weak ciphers.
But other that; disabling the weak ciphers was easy. Just one variable
declaration and one line of code. :-)
--
Timothy
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2408588
Disabling weak ciphers in Restlet
I've been working on making my server PCI (Payment Card Industry) compliant. When my site is scanned one of the vulnerabilities reported is that my site allows the use of weak SSL ciphers. I've been looking through the documentation for jsslutils and SSLContextFactory; but I don't understand how I'm suppose to disable the 40 and 56 bit ciphers. For reference I'm running on Ubuntu 8.04 TLS, openjdk-1.6, and restlet 1.1.5, and my sslContextFactory is com.noelios.retlet.util.DefaultSslContextFactory Here is the list of weak SSL ciphers supported by the remote server : Low Strength Ciphers (< 56-bit key) SSLv3 EXP-EDH-RSA-DES-CBC-SHA Kx=DH(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-DES-CBC-SHA Kx=RSA(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-RC4-MD5 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export TLSv1 EXP-EDH-RSA-DES-CBC-SHA Kx=DH(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-DES-CBC-SHA Kx=RSA(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-RC4-MD5 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2408421
Re: Premature EOF / Broken Pipe
My real application is still the only place I can reproduce the problem.
While watching the client and server both run within Eclipse I can add one
more observation about the order of events when the exceptions occur.
My client is POSTing a message to a resource. When the problem occurs the
client's call to
{ new Client(Protocol.HTTP).post(url, representation) }
does not return for ~30 seconds. The my client application does not throw
an exception until after the server has thrown it's exceptions.
My server resource is receiving an acceptRepresentation call but is throwing
an exception because the Representation entity it receives has a problem of
some sort. It's attempting to create a new Form(entity). When it throws
it's first exception. The form is only partially parsed because of a
java.io.IOException: Broken pipe.The resource then attempts to use the
incomplete form object, throws a few more exceptions that are caught.
Watching it happen I'd say that the server exceptions have all occured
before the client throws it's Premature EOF exception.
Jerome's initial suggestion to my problem was to try different http
connectors. I initially didn't realize how easy that was to do until I saw
an old posting from Thierry refering to these links.
http://www.restlet.org/documentation/1.1/faq#04 &
http://www.restlet.org/documentation/1.1/faq#05
Just change the class path. I didn't realize it was that easy. :-)
My first change was to switch my client to the Apache httpclient. I'm going
to run my client over night and see if I have any errrors.
--
Timothy Aanerud
On Sun, Jul 5, 2009 at 6:27 AM, Jerome Louvel wrote:
> Hi Timothy,
>
>
>
> Thanks for updating us. Let’s keep an eye on it and if you find a way to
> reproduce it, please let us know!
>
>
>
> 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é :* mercredi 1 juillet 2009 20:53
> *À :* discuss@restlet.tigris.org
>
> *Objet :* Re: Premature EOF / Broken Pipe
>
>
>
> I tried adding a second resource to my sample application. But it doesn't
> fail.
>
> In my actual application I have a scheduled background thread doing a POST
> transaction, immediately followed by a GET transaction. The Premature EOF
> exception has always occurred in the POST transaction. Since order does not
> matter between these two message exchanges, I switched them around. After
> doing this and trying several different scheduled time intervals for the
> background thread, I have yet to see it fail using the
> org.restlet.Client.Client using org.restlet.data.Protocol.HTTP or
> Protocol.HTTPS.
>
> I can't say "problem solved" but this is interesting and confusing at the
> same time.
> --
> Timothy Aanerud
>
> On Mon, Jun 29, 2009 at 9:18 AM, Timothy Aanerud
> wrote:
>
> 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
> taanerudataticonsulting.com
>
>
>
> On Mon, Jun 29, 2009 at 2:57 AM, Jerome Louvel
> wrote:
>
> 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:taanerudATaticonsulting.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 experiment, 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
> wro
Re: Premature EOF / Broken Pipe
Several days of over night testing showed that my application would still intermittently fail. Switching the order of the messages just reduced the incident rate. -- Timothy. On Wed, Jul 1, 2009 at 1:52 PM, Timothy Aanerud wrote: > ... > > In my actual application I have a scheduled background thread doing a POST > transaction, immediately followed by a GET transaction. The Premature EOF > exception has always occurred in the POST transaction. Since order does not > matter between these two message exchanges, I switched them around. After > doing this and trying several different scheduled time intervals for the > background thread, I have yet to see it fail using the > org.restlet.Client.Client using org.restlet.data.Protocol.HTTP or > Protocol.HTTPS. > > > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2371512
Re: Premature EOF / Broken Pipe
I tried adding a second resource to my sample application. But it doesn't fail. In my actual application I have a scheduled background thread doing a POST transaction, immediately followed by a GET transaction. The Premature EOF exception has always occurred in the POST transaction. Since order does not matter between these two message exchanges, I switched them around. After doing this and trying several different scheduled time intervals for the background thread, I have yet to see it fail using the org.restlet.Client.Client using org.restlet.data.Protocol.HTTP or Protocol.HTTPS. I can't say "problem solved" but this is interesting and confusing at the same time. -- Timothy Aanerud On Mon, Jun 29, 2009 at 9:18 AM, Timothy Aanerud wrote: > 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 > taanerudataticonsulting.com > > > > On Mon, Jun 29, 2009 at 2:57 AM, Jerome Louvel > wrote: > >> 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:taanerudATaticonsulting.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 experiment, 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:taanerudATaticonsulting.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&dsMessageId=23635 >> 62 >> >> -- >> >> >> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2363638 >> >> >> > > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2367157
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 wrote: > 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 > 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&dsMessageId=23635 > 62 > > -- > > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2363638 > > > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2366382
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 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&dsMessageId=23635 > 62 > > -- > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2363638 > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2363663
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&dsMessageId=2363562
Premature EOF / Broken Pipe
Hi, I'm having a communications problem between a client/server application both using Restlet 1.1.1 (and since upgraded to 1.1.5). The client and server are both running on Fedora 10, OpenJDK-6 build 14. The client posts a status resource message to the server to exchange status information at regular intervals. The message send works most of the time. But, some times I'll get an exception on both the server and client side. The client side throws a Premature EOF IOException while trying to parse the response entity as Sax; while the server side sees an IOException with the message Broken Pipe. (stack traces are attached using Restlet 1.1.1) If the client sends the status resource message once every three minutes, I'll hardly ever get this exception pair. If I send it every 10 seconds, the error rate is ~ 3%. At 5 second intervals, the error rate is in the 25-50% range. I was first seeing this error going over a wide area connection, but the error will occur on my local area network too. I upgraded to Restlet-1.1.5 from 1.1.1 but that didn't help. :-( Could HTTP caching be biting me here? The POST data doesn't change much from message to message. I'm running out of ideas as to what to look at next for the cause of this problem.INFO: Starting the HTTP client Jun 18, 2009 7:54:02 AM com.noelios.restlet.http.HttpClientCall getResponseEntity INFO: The length of the message body is unknown. The entity must be handled carefully and consumed entirely in order to surely release the connection. ERROR: 'Premature EOF' javax.xml.transform.TransformerException: java.io.IOException: Premature EOF at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:724) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:317) at org.restlet.resource.SaxRepresentation.parse(SaxRepresentation.java:189) at com.atilabs.rtikiosk.server.StatusResponseHandler.(StatusResponseHandler.java:24) at com.atilabs.rtikiosk.server.StatusTransaction.parseResponse(StatusTransaction.java:48) at com.atilabs.rtikiosk.server.Server$1.run(Server.java:122) Caused by: java.io.IOException: Premature EOF at sun.net.www.http.ChunkedInputStream.readAheadBlocking(ChunkedInputStream.java:556) at sun.net.www.http.ChunkedInputStream.readAhead(ChunkedInputStream.java:600) at sun.net.www.http.ChunkedInputStream.read(ChunkedInputStream.java:687) at java.io.FilterInputStream.read(FilterInputStream.java:133) at sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:2411) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager$RewindableInputStream.read(XMLEntityManager.java:2915) at com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.read(UTF8Reader.java:302) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.load(XMLEntityScanner.java:1719) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.skipSpaces(XMLEntityScanner.java:1469) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$TrailingMiscDriver.next(XMLDocumentScannerImpl.java:1373) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:624) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:116) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:486) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:810) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:740) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:110) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1208) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIdentity(TransformerImpl.java:641) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:712) ... 5 more - java.io.IOException: Premature EOF at sun.net.www.http.ChunkedInputStream.readAheadBlocking(ChunkedInputStream.java:556) at sun.net.www.http.ChunkedInputStream.readAhead(ChunkedInputStream.java:600) at sun.net.www.http.ChunkedInputStream.read(ChunkedInputStream.java:687) at java.io.FilterInputStream.read(FilterInputStream.java:133) at sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:2411) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager$RewindableInputStream.read(XMLEntityManager.java:2915) at com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.read(UTF8Reader.java:302) at com.sun
