Re: Restlet 2.2.2, Jetty 8.1, disable SSLv3

2014-10-25 Thread Timothy Aanerud
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=4447dsMessageId=3090338

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


Re: lib/org.restlet.ext.ssl.jar missing from 2.2.2 zip

2014-08-20 Thread Timothy Aanerud
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=4447dsMessageId=3086969

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


Re: Enable only selected cipher suites

2012-06-20 Thread Timothy Aanerud
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
   ---
   Client client = new Client(ctx,Protocol.HTTPS);
   client.setConnectTimeout(5);
   
   Context workingCtx = client.getContext();
   
 System.setProperty(javax.net.ssl.trustStore,C:\\Program 
 Files\\Java\\jre6\\lib\\security\\cacerts);
   System.setProperty(javax.net.ssl.trustStorePassword, 
 changeit);
   workingCtx.getParameters().add(keystorePath, 
 C:\\openadrkeystore\\bouncykeys\\VEN_QLI.bks);
   workingCtx.getParameters().add(keystorePassword, 
 password

Re: Re: Redirect Restlet console statements to an external log file using log4j.properties

2009-10-19 Thread Timothy Aanerud
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 ty.new...@copperchipgames.com 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=4447dsMessageId=2408822


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

Re: Re: Redirect Restlet console statements to an external log file using log4j.properties

2009-10-19 Thread Timothy Aanerud
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 ty.new...@copperchipgames.com 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=4447dsMessageId=2408822


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

RE: Re: Disabling weak ciphers in Restlet

2009-10-17 Thread Timothy Aanerud
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 ListString then starts removing the the disabled ones. After 
removing items the ListString 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=4447dsMessageId=2408588


Disabling weak ciphers in Restlet

2009-10-16 Thread Timothy Aanerud
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=4447dsMessageId=2408421


Re: Premature EOF / Broken Pipe

2009-07-15 Thread Timothy Aanerud
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
taane...@aticonsulting.comwrote:

 ...

 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=4447dsMessageId=2371512

Re: Premature EOF / Broken Pipe

2009-07-15 Thread Timothy Aanerud
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 jerome.lou...@noelios.comwrote:

  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
 tannerudATaticonsulting.com 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 taane...@aticonsulting.com



  On Mon, Jun 29, 2009 at 2:57 AM, Jerome Louvel jerome.lou...@noelios.com
 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.comtaane...@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 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

Re: Premature EOF / Broken Pipe

2009-07-01 Thread Timothy Aanerud
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
tannerudATaticonsulting.com 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 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:taanerudATaticonsulting.comtaane...@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 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.comtaane...@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=2367157

Re: Premature EOF / Broken Pipe

2009-06-29 Thread Timothy Aanerud
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

Premature EOF / Broken Pipe

2009-06-19 Thread Timothy Aanerud
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.init(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 

RE: Premature EOF / Broken Pipe

2009-06-19 Thread Timothy Aanerud
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=2363562