Re: Using Prototype.js with Restlet

2008-07-21 Thread Thierry Boileau

Hello Eric and Gal,

you can also use a mechanism based on the URI of the resource that 
allows to make PUT, DELETE requests via POST. It consists in adding a 
method parameter in the query part of the resource's URI.
See this page for more details : 
http://www.restlet.org/documentation/1.1/faq#19


In a few word, if you want to PUT to http://myserver/myresource, just 
POST the same entity to http://myserver/myresource?method=put


best regards,
Thierry Boileau


Hi,

I have changed prototype instead.

for prototype ver 1.6.0.2

around line 1193 I replace with the following:

if (!['get', 'post', 'put', 'delete'].include(this.method)) {
   // simulate other verbs over post
   params['_method'] = this.method;
   this.method = 'post';
}

just adding the put and delete enables you to use thos methods without 
any changes to restlet.


However, if you wish to add body to your put and delete methods you 
would also need to change line 1222 to enable send body with those 
methods. As it is, prototype will add body only to post.


HTH,

Gal


- Original Message - From: Eric Vuillermet 
[EMAIL PROTECTED]

To: discuss@restlet.tigris.org
Sent: Monday, July 21, 2008 3:53 AM
Subject: Using Prototype.js with Restlet



Hi everyone,

I have just started using Restlet a week back so this might be a newbie
question, sorry!

I created a simple application using prototype.js for the front-end 
talking to

a Restlet back-end.

I would like the JS code to be as clean as possible, so my DELETE/PUT 
requests
from JavaScript look like DELETE/PUT requests, and I used the 
PrototypeFinder
class from the Restlet wiki 
(http://wiki.restlet.org/docs_1.1/g1/13-restlet/29-
restlet/99-restlet/52-restlet.html) to support the tunneling of 
DELETE/PUT
from Prototype through POST. Prototype adds a form parameter called 
'_method'
to the POST body, and the PrototypeFinder class reads that parameter 
to set

the correct method on the incoming request.

The problem it seems is that when the PrototypeFinder class read the 
_method
parameter, it does that by reading the entire input entity as a form. 
That's

OK for DELETE, but the problem is, if I want to have the JavaScript do a
normal POST, the handlePost method of the Resource class will respond 
Missing

request entity, because the input entity has already been read by
PrototypeFinder before reaching my resource's post method.

Has anyone else tried to use Prototype.js and Restlet together? Have 
they run

into this same issue? How did they solve it?

FYI: Here is the PrototypeFinder class I am using (same as the one on 
the

Restlet wiki):


public class PrototypeFinder extends Finder {

 public PrototypeFinder(Context context, Class? extends Resource
targetClass) {

   super(context, targetClass);

}




public void handle(Request request, Response response) {

 Parameter p = request.getEntityAsForm().getFirst(_method); // This is
where Prototype.js puts the real method name

 request.setMethod(null != p ? Method.valueOf(p.getValue()) :
request.getMethod());

 super.handle(request, response);

 }

}

Thanks for your help!

Eric









Re: Using Prototype.js with Restlet

2008-07-21 Thread Gal Nitzan

Hi Thierry,

Thank you. I know, however, I find it cleaner that prototype will delete 
and put from within without using the _method param.


So that is why I decided to change its behavior a bit :).

Gal.

- Original Message - 
From: Thierry Boileau [EMAIL PROTECTED]

To: discuss@restlet.tigris.org
Sent: Monday, July 21, 2008 11:00 AM
Subject: Re: Using Prototype.js with Restlet



Hello Eric and Gal,

you can also use a mechanism based on the URI of the resource that allows 
to make PUT, DELETE requests via POST. It consists in adding a method 
parameter in the query part of the resource's URI.
See this page for more details : 
http://www.restlet.org/documentation/1.1/faq#19


In a few word, if you want to PUT to http://myserver/myresource, just POST 
the same entity to http://myserver/myresource?method=put


best regards,
Thierry Boileau


Hi,

I have changed prototype instead.

for prototype ver 1.6.0.2

around line 1193 I replace with the following:

if (!['get', 'post', 'put', 'delete'].include(this.method)) {
   // simulate other verbs over post
   params['_method'] = this.method;
   this.method = 'post';
}

just adding the put and delete enables you to use thos methods without 
any changes to restlet.


However, if you wish to add body to your put and delete methods you 
would also need to change line 1222 to enable send body with those 
methods. As it is, prototype will add body only to post.


HTH,

Gal


- Original Message - From: Eric Vuillermet 
[EMAIL PROTECTED]

To: discuss@restlet.tigris.org
Sent: Monday, July 21, 2008 3:53 AM
Subject: Using Prototype.js with Restlet



Hi everyone,

I have just started using Restlet a week back so this might be a newbie
question, sorry!

I created a simple application using prototype.js for the front-end 
talking to

a Restlet back-end.

I would like the JS code to be as clean as possible, so my DELETE/PUT 
requests
from JavaScript look like DELETE/PUT requests, and I used the 
PrototypeFinder
class from the Restlet wiki 
(http://wiki.restlet.org/docs_1.1/g1/13-restlet/29-
restlet/99-restlet/52-restlet.html) to support the tunneling of 
DELETE/PUT
from Prototype through POST. Prototype adds a form parameter called 
'_method'
to the POST body, and the PrototypeFinder class reads that parameter to 
set

the correct method on the incoming request.

The problem it seems is that when the PrototypeFinder class read the 
_method
parameter, it does that by reading the entire input entity as a form. 
That's

OK for DELETE, but the problem is, if I want to have the JavaScript do a
normal POST, the handlePost method of the Resource class will respond 
Missing

request entity, because the input entity has already been read by
PrototypeFinder before reaching my resource's post method.

Has anyone else tried to use Prototype.js and Restlet together? Have 
they run

into this same issue? How did they solve it?

FYI: Here is the PrototypeFinder class I am using (same as the one on 
the

Restlet wiki):


public class PrototypeFinder extends Finder {

 public PrototypeFinder(Context context, Class? extends Resource
targetClass) {

   super(context, targetClass);

}




public void handle(Request request, Response response) {

 Parameter p = request.getEntityAsForm().getFirst(_method); // This is
where Prototype.js puts the real method name

 request.setMethod(null != p ? Method.valueOf(p.getValue()) :
request.getMethod());

 super.handle(request, response);

 }

}

Thanks for your help!

Eric














RE: Using Prototype.js with Restlet

2008-07-21 Thread Jerome Louvel

Hi all,

It is indeed better if Prototype can directly send the right HTTP method.
I'm not sure however how portable Gal's solution is (from a browser point of
view). 

If it is, then we should propose a patch to Prototype's team. 

Otherwise, you can use TunnelService as mentioned by Thierry. Just configure
it this way: getTunnelService().setMethodParameter(_method). I've
mentioned this easier solution in the wiki page as an alternative to the
PrototypeFinder suggested there.

Best regards,
Jerome


-Message d'origine-
De : Gal Nitzan [mailto:[EMAIL PROTECTED] 
Envoyé : lundi 21 juillet 2008 12:16
À : discuss@restlet.tigris.org
Objet : Re: Using Prototype.js with Restlet

Hi Thierry,

Thank you. I know, however, I find it cleaner that prototype will delete

and put from within without using the _method param.

So that is why I decided to change its behavior a bit :).

Gal.

- Original Message - 
From: Thierry Boileau [EMAIL PROTECTED]
To: discuss@restlet.tigris.org
Sent: Monday, July 21, 2008 11:00 AM
Subject: Re: Using Prototype.js with Restlet


 Hello Eric and Gal,

 you can also use a mechanism based on the URI of the resource that allows 
 to make PUT, DELETE requests via POST. It consists in adding a method 
 parameter in the query part of the resource's URI.
 See this page for more details : 
 http://www.restlet.org/documentation/1.1/faq#19

 In a few word, if you want to PUT to http://myserver/myresource, just POST

 the same entity to http://myserver/myresource?method=put

 best regards,
 Thierry Boileau

 Hi,

 I have changed prototype instead.

 for prototype ver 1.6.0.2

 around line 1193 I replace with the following:

 if (!['get', 'post', 'put', 'delete'].include(this.method)) {
// simulate other verbs over post
params['_method'] = this.method;
this.method = 'post';
 }

 just adding the put and delete enables you to use thos methods without 
 any changes to restlet.

 However, if you wish to add body to your put and delete methods you 
 would also need to change line 1222 to enable send body with those 
 methods. As it is, prototype will add body only to post.

 HTH,

 Gal


 - Original Message - From: Eric Vuillermet 
 [EMAIL PROTECTED]
 To: discuss@restlet.tigris.org
 Sent: Monday, July 21, 2008 3:53 AM
 Subject: Using Prototype.js with Restlet


 Hi everyone,

 I have just started using Restlet a week back so this might be a newbie
 question, sorry!

 I created a simple application using prototype.js for the front-end 
 talking to
 a Restlet back-end.

 I would like the JS code to be as clean as possible, so my DELETE/PUT 
 requests
 from JavaScript look like DELETE/PUT requests, and I used the 
 PrototypeFinder
 class from the Restlet wiki 
 (http://wiki.restlet.org/docs_1.1/g1/13-restlet/29-
 restlet/99-restlet/52-restlet.html) to support the tunneling of 
 DELETE/PUT
 from Prototype through POST. Prototype adds a form parameter called 
 '_method'
 to the POST body, and the PrototypeFinder class reads that parameter to 
 set
 the correct method on the incoming request.

 The problem it seems is that when the PrototypeFinder class read the 
 _method
 parameter, it does that by reading the entire input entity as a form. 
 That's
 OK for DELETE, but the problem is, if I want to have the JavaScript do a
 normal POST, the handlePost method of the Resource class will respond 
 Missing
 request entity, because the input entity has already been read by
 PrototypeFinder before reaching my resource's post method.

 Has anyone else tried to use Prototype.js and Restlet together? Have 
 they run
 into this same issue? How did they solve it?

 FYI: Here is the PrototypeFinder class I am using (same as the one on 
 the
 Restlet wiki):


 public class PrototypeFinder extends Finder {

  public PrototypeFinder(Context context, Class? extends Resource
 targetClass) {

super(context, targetClass);

 }




 public void handle(Request request, Response response) {

  Parameter p = request.getEntityAsForm().getFirst(_method); // This is
 where Prototype.js puts the real method name

  request.setMethod(null != p ? Method.valueOf(p.getValue()) :
 request.getMethod());

  super.handle(request, response);

  }

 }

 Thanks for your help!

 Eric






 




RE: Restlet causing JVM crashes

2008-07-21 Thread Jerome Louvel
Hi Mark,
 
I haven't seen this personally yet. 
 
BTW, Sun hasn't replied to my bug report submission. I don't know if it has 
been discarded or simply delayed... Maybe you should try to submit a report 
yourself, it might have a better fortune...


Best regards,
Jerome

 

  _  

De : Mark Derricutt [mailto:[EMAIL PROTECTED] 
Envoyé : lundi 21 juillet 2008 06:13
À : discuss@restlet.tigris.org
Objet : Re: Restlet causing JVM crashes


Hey all,

This problem's just started to hit again on our production boxes running RHEl 3 
and RHEL 5 and JDK 1.6_06.

I tried checking what Kevin changed (volatile to final) but can't see any 
volatile's mentioned in HeaderReader class (but my pretty much everywhere else).

It can't be just us and Kevin seeing this can it?  We're now seeing it locally 
across multiple VM versions.

Mark


On Tue, Jun 10, 2008 at 12:12 AM, Kevin Conaway [EMAIL PROTECTED] wrote:


Hi Mark,

I had the same problem as you.  I tweaked some lines of code in that class and 
recompiled and the issue went away.

It feels like a bug in the JVM because the error is happening when Hotspot 
decides to recompile the class.  I never did figure out what was causing it.  

I had posted to [EMAIL PROTECTED] back in April:

http://restlet.tigris.org/servlets/ReadMsg?list=code 
http://restlet.tigris.org/servlets/ReadMsg?list=codemsgNo=139 msgNo=139

Kevin 


On Wed, Jun 4, 2008 at 12:37 AM, Rob Heittman [EMAIL PROTECTED] wrote:


That's a new one on me, but Hardy has been the locus of a bunch of new JVM 
crash issues, mainly with Athlon processors.  Also there have been some similar 
issues with 64-bit under Red Hat and Fedora. 

This is the Sun JVM I get installing sun-java6-jdk from multiverse, and I don't 
get JVM crashes on P4, Centrino, or Core Duo.  

java version 1.6.0_06
Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
Java HotSpot(TM) Client VM (build 10.0-b22, mixed mode, sharing)

Where did you get yours from?  Direct Sun download?  Hardy tries very hard to 
use OpenJDK, which also doesn't crash for me on P4, Centrino, or Core Duo.

- Rob






-- 
It is easier to optimize correct code than to correct optimized code. -- Bill 
Harlan 


Re: Restlet causing JVM crashes

2008-07-21 Thread Mark Derricutt
For now we've told hotspot not to compile that method so hopefully that'll
help.  I've been following a similar bug report at Sun from a problem with
Eclipse that has an endless to and fro of its fixed, oh wait... no its not
:(

Mark

On Mon, Jul 21, 2008 at 10:10 PM, Jerome Louvel [EMAIL PROTECTED] wrote:

  Hi Mark,

 I haven't seen this personally yet.

 BTW, Sun hasn't replied to my bug report submission. I don't know if it has
 been discarded or simply delayed... Maybe you should try to submit a report
 yourself, it might have a better fortune...

 Best regards,
 Jerome


  --
 *De :* Mark Derricutt [mailto:[EMAIL PROTECTED]
 *Envoyé :* lundi 21 juillet 2008 06:13
 *À :* discuss@restlet.tigris.org
 *Objet :* Re: Restlet causing JVM crashes

  Hey all,

 This problem's just started to hit again on our production boxes running
 RHEl 3 and RHEL 5 and JDK 1.6_06.

 I tried checking what Kevin changed (volatile to final) but can't see any
 volatile's mentioned in HeaderReader class (but my pretty much everywhere
 else).

 It can't be just us and Kevin seeing this can it?  We're now seeing it
 locally across multiple VM versions.

 Mark

 On Tue, Jun 10, 2008 at 12:12 AM, Kevin Conaway [EMAIL PROTECTED]
 wrote:

 Hi Mark,

 I had the same problem as you.  I tweaked some lines of code in that class
 and recompiled and the issue went away.

 It feels like a bug in the JVM because the error is happening when Hotspot
 decides to recompile the class.  I never did figure out what was causing
 it.

 I had posted to [EMAIL PROTECTED] back in April:

 http://restlet.tigris.org/servlets/ReadMsg?list=codemsgNo=139

 Kevin


 On Wed, Jun 4, 2008 at 12:37 AM, Rob Heittman [EMAIL PROTECTED]
 wrote:

 That's a new one on me, but Hardy has been the locus of a bunch of new
 JVM crash issues, mainly with Athlon processors.  Also there have been some
 similar issues with 64-bit under Red Hat and Fedora.
 This is the Sun JVM I get installing sun-java6-jdk from multiverse, and I
 don't get JVM crashes on P4, Centrino, or Core Duo.

 java version 1.6.0_06
 Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
 Java HotSpot(TM) Client VM (build 10.0-b22, mixed mode, sharing)

  Where did you get yours from?  Direct Sun download?  Hardy tries very
 hard to use OpenJDK, which also doesn't crash for me on P4, Centrino, or
 Core Duo.

 - Rob





 --
 It is easier to optimize correct code than to correct optimized code. --
 Bill Harlan




-- 
It is easier to optimize correct code than to correct optimized code. --
Bill Harlan


RE: SSL + Virtual Hosts and Issue #489?

2008-07-21 Thread Jerome Louvel

Hi Alex,

For now, I've added a link from the Server connectors wiki page to the
Securing a Restlet application page. Feel free to expand the documentation
on the first page, maybe adding a concrete SSL configuration example.

We should have some info on SslContextFactory as suggested by Bruno. I'll
reply to his mail separately.

Best regards,
Jerome


-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Alex
Milowski
Envoyé : vendredi 18 juillet 2008 15:59
À : discuss@restlet.tigris.org
Objet : Re: SSL + Virtual Hosts and Issue #489?

On Wed, Jul 16, 2008 at 2:32 AM, Jerome Louvel [EMAIL PROTECTED] wrote:

 Hi Alex,

 I have added a paragraph on Confidentiality in the Securing
applications
 page covering this topic:

http://wiki.restlet.org/docs_1.1/g1/13-restlet/29-restlet/99-restlet/46-rest
 let.html

 At some point, it might makes sense to split up this page into several
ones.

Thanks.

I think it would be good to have some ssl-specific information make its
way into the connector documentation as an example.

That is, there is a simple example here:

 
http://wiki.restlet.org/docs_1.1/g1/13-restlet/27-restlet/37-restlet/38-rest
let.html

Maybe we could have about ssl configuration there as well.  Of course, the
parameters are specific to the server helper...

--Alex Milowski



RE: Restlet causing JVM crashes

2008-07-21 Thread Jerome Louvel
Mark,
 
Thanks for the follow-up. 
 
Do you have details on how to configure Hotspot to make it ignore this method? 
 
That might be useful for others. I will add it to the related bug report as 
well:
 
Segfaults with HotSpot in 64bit Linux
http://restlet.tigris.org/issues/show_bug.cgi?id=524
 
Best regards,
Jerome
 

  _  

De : Mark Derricutt [mailto:[EMAIL PROTECTED] 
Envoyé : lundi 21 juillet 2008 12:13
À : discuss@restlet.tigris.org
Objet : Re: Restlet causing JVM crashes


For now we've told hotspot not to compile that method so hopefully that'll 
help.  I've been following a similar bug report at Sun from a problem with 
Eclipse that has an endless to and fro of its fixed, oh wait... no its not :(

Mark


On Mon, Jul 21, 2008 at 10:10 PM, Jerome Louvel [EMAIL PROTECTED] wrote:


Hi Mark,
 
I haven't seen this personally yet. 
 
BTW, Sun hasn't replied to my bug report submission. I don't know if it has 
been discarded or simply delayed... Maybe you should try to submit a report 
yourself, it might have a better fortune...



Best regards,
Jerome

 

  _  


De : Mark Derricutt [mailto:[EMAIL PROTECTED] 

Envoyé : lundi 21 juillet 2008 06:13 

À : discuss@restlet.tigris.org
Objet : Re: Restlet causing JVM crashes


Hey all,

This problem's just started to hit again on our production boxes running RHEl 3 
and RHEL 5 and JDK 1.6_06.

I tried checking what Kevin changed (volatile to final) but can't see any 
volatile's mentioned in HeaderReader class (but my pretty much everywhere else).

It can't be just us and Kevin seeing this can it?  We're now seeing it locally 
across multiple VM versions.

Mark


On Tue, Jun 10, 2008 at 12:12 AM, Kevin Conaway [EMAIL PROTECTED] wrote:


Hi Mark,

I had the same problem as you.  I tweaked some lines of code in that class and 
recompiled and the issue went away.

It feels like a bug in the JVM because the error is happening when Hotspot 
decides to recompile the class.  I never did figure out what was causing it.  

I had posted to [EMAIL PROTECTED] back in April:

http://restlet.tigris.org/servlets/ReadMsg?list=code 
http://restlet.tigris.org/servlets/ReadMsg?list=codemsgNo=139 msgNo=139

Kevin 


On Wed, Jun 4, 2008 at 12:37 AM, Rob Heittman [EMAIL PROTECTED] wrote:


That's a new one on me, but Hardy has been the locus of a bunch of new JVM 
crash issues, mainly with Athlon processors.  Also there have been some similar 
issues with 64-bit under Red Hat and Fedora. 

This is the Sun JVM I get installing sun-java6-jdk from multiverse, and I don't 
get JVM crashes on P4, Centrino, or Core Duo.  

java version 1.6.0_06
Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
Java HotSpot(TM) Client VM (build 10.0-b22, mixed mode, sharing)

Where did you get yours from?  Direct Sun download?  Hardy tries very hard to 
use OpenJDK, which also doesn't crash for me on P4, Centrino, or Core Duo.

- Rob






-- 
It is easier to optimize correct code than to correct optimized code. -- Bill 
Harlan 




-- 
It is easier to optimize correct code than to correct optimized code. -- Bill 
Harlan 


Re: Restlet causing JVM crashes

2008-07-21 Thread Mark Derricutt
There's apparantly two ways of doing it:

-XX:CompileCommand=exclude,my/pkg/MyClass,theMethod

or

-XX: CompileCommandFile=/my/canned/command/file

The command file can also be .hotspot_compiler in the current directory.
And the ,'s can also be spaced.

I found this via http://forums.sun.com/thread.jspa?messageID=1844071

On Mon, Jul 21, 2008 at 10:20 PM, Jerome Louvel [EMAIL PROTECTED] wrote:

  Mark,

 Thanks for the follow-up.

 Do you have details on how to configure Hotspot to make it ignore this
 method?

 That might be useful for others. I will add it to the related bug report as
 well:

 Segfaults with HotSpot in 64bit Linux
 http://restlet.tigris.org/issues/show_bug.cgi?id=524

 Best regards,
 Jerome


  --
 *De :* Mark Derricutt [mailto:[EMAIL PROTECTED]
 *Envoyé :* lundi 21 juillet 2008 12:13

 *À :* discuss@restlet.tigris.org
 *Objet :* Re: Restlet causing JVM crashes

  For now we've told hotspot not to compile that method so hopefully
 that'll help.  I've been following a similar bug report at Sun from a
 problem with Eclipse that has an endless to and fro of its fixed, oh
 wait... no its not :(

 Mark

 On Mon, Jul 21, 2008 at 10:10 PM, Jerome Louvel [EMAIL PROTECTED]
 wrote:

  Hi Mark,

 I haven't seen this personally yet.

 BTW, Sun hasn't replied to my bug report submission. I don't know if it
 has been discarded or simply delayed... Maybe you should try to submit a
 report yourself, it might have a better fortune...

 Best regards,
 Jerome


  --
  *De :* Mark Derricutt [mailto:[EMAIL PROTECTED]
 *Envoyé :* lundi 21 juillet 2008 06:13
 *À :* discuss@restlet.tigris.org
 *Objet :* Re: Restlet causing JVM crashes

   Hey all,

 This problem's just started to hit again on our production boxes running
 RHEl 3 and RHEL 5 and JDK 1.6_06.

 I tried checking what Kevin changed (volatile to final) but can't see any
 volatile's mentioned in HeaderReader class (but my pretty much everywhere
 else).

 It can't be just us and Kevin seeing this can it?  We're now seeing it
 locally across multiple VM versions.

 Mark

 On Tue, Jun 10, 2008 at 12:12 AM, Kevin Conaway [EMAIL PROTECTED]
 wrote:

 Hi Mark,

 I had the same problem as you.  I tweaked some lines of code in that
 class and recompiled and the issue went away.

 It feels like a bug in the JVM because the error is happening when
 Hotspot decides to recompile the class.  I never did figure out what was
 causing it.

 I had posted to [EMAIL PROTECTED] back in April:

 http://restlet.tigris.org/servlets/ReadMsg?list=codemsgNo=139

 Kevin


 On Wed, Jun 4, 2008 at 12:37 AM, Rob Heittman 
 [EMAIL PROTECTED] wrote:

 That's a new one on me, but Hardy has been the locus of a bunch of new
 JVM crash issues, mainly with Athlon processors.  Also there have been some
 similar issues with 64-bit under Red Hat and Fedora.
 This is the Sun JVM I get installing sun-java6-jdk from multiverse, and
 I don't get JVM crashes on P4, Centrino, or Core Duo.

 java version 1.6.0_06
 Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
 Java HotSpot(TM) Client VM (build 10.0-b22, mixed mode, sharing)

  Where did you get yours from?  Direct Sun download?  Hardy tries very
 hard to use OpenJDK, which also doesn't crash for me on P4, Centrino, or
 Core Duo.

 - Rob





 --
 It is easier to optimize correct code than to correct optimized code. --
 Bill Harlan




 --
 It is easier to optimize correct code than to correct optimized code. --
 Bill Harlan




-- 
It is easier to optimize correct code than to correct optimized code. --
Bill Harlan


RE: Restlet causing JVM crashes

2008-07-21 Thread Jerome Louvel
Thanks for the note, I've added it to the report. Let us know if, on the long 
term, this effectively works around the HotSpot bug in your environment.


Best regards,
Jerome

  _  

De : Mark Derricutt [mailto:[EMAIL PROTECTED] 
Envoyé : lundi 21 juillet 2008 12:26
À : discuss@restlet.tigris.org
Objet : Re: Restlet causing JVM crashes


There's apparantly two ways of doing it:

-XX:CompileCommand=exclude,my/pkg/MyClass,theMethod

or

-XX: CompileCommandFile=/my/canned/command/file

The command file can also be .hotspot_compiler in the current directory.  And 
the ,'s can also be spaced.

I found this via http://forums.sun.com/thread.jspa?messageID=1844071


On Mon, Jul 21, 2008 at 10:20 PM, Jerome Louvel [EMAIL PROTECTED] wrote:


Mark,
 
Thanks for the follow-up. 
 
Do you have details on how to configure Hotspot to make it ignore this method? 
 
That might be useful for others. I will add it to the related bug report as 
well:
 
Segfaults with HotSpot in 64bit Linux
http://restlet.tigris.org/issues/show_bug.cgi?id=524
 
Best regards,
Jerome
 

  _  


De : Mark Derricutt [mailto:[EMAIL PROTECTED] 

Envoyé : lundi 21 juillet 2008 12:13 

À : discuss@restlet.tigris.org
Objet : Re: Restlet causing JVM crashes


For now we've told hotspot not to compile that method so hopefully that'll 
help.  I've been following a similar bug report at Sun from a problem with 
Eclipse that has an endless to and fro of its fixed, oh wait... no its not :(

Mark


On Mon, Jul 21, 2008 at 10:10 PM, Jerome Louvel [EMAIL PROTECTED] wrote:


Hi Mark,
 
I haven't seen this personally yet. 
 
BTW, Sun hasn't replied to my bug report submission. I don't know if it has 
been discarded or simply delayed... Maybe you should try to submit a report 
yourself, it might have a better fortune...



Best regards,
Jerome

 

  _  


De : Mark Derricutt [mailto:[EMAIL PROTECTED] 

Envoyé : lundi 21 juillet 2008 06:13 

À : discuss@restlet.tigris.org
Objet : Re: Restlet causing JVM crashes


Hey all,

This problem's just started to hit again on our production boxes running RHEl 3 
and RHEL 5 and JDK 1.6_06.

I tried checking what Kevin changed (volatile to final) but can't see any 
volatile's mentioned in HeaderReader class (but my pretty much everywhere else).

It can't be just us and Kevin seeing this can it?  We're now seeing it locally 
across multiple VM versions.

Mark


On Tue, Jun 10, 2008 at 12:12 AM, Kevin Conaway [EMAIL PROTECTED] wrote:


Hi Mark,

I had the same problem as you.  I tweaked some lines of code in that class and 
recompiled and the issue went away.

It feels like a bug in the JVM because the error is happening when Hotspot 
decides to recompile the class.  I never did figure out what was causing it.  

I had posted to [EMAIL PROTECTED] back in April:

http://restlet.tigris.org/servlets/ReadMsg?list=code 
http://restlet.tigris.org/servlets/ReadMsg?list=codemsgNo=139 msgNo=139

Kevin 


On Wed, Jun 4, 2008 at 12:37 AM, Rob Heittman [EMAIL PROTECTED] wrote:


That's a new one on me, but Hardy has been the locus of a bunch of new JVM 
crash issues, mainly with Athlon processors.  Also there have been some similar 
issues with 64-bit under Red Hat and Fedora. 

This is the Sun JVM I get installing sun-java6-jdk from multiverse, and I don't 
get JVM crashes on P4, Centrino, or Core Duo.  

java version 1.6.0_06
Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
Java HotSpot(TM) Client VM (build 10.0-b22, mixed mode, sharing)

Where did you get yours from?  Direct Sun download?  Hardy tries very hard to 
use OpenJDK, which also doesn't crash for me on P4, Centrino, or Core Duo.

- Rob






-- 
It is easier to optimize correct code than to correct optimized code. -- Bill 
Harlan 




-- 
It is easier to optimize correct code than to correct optimized code. -- Bill 
Harlan 




-- 
It is easier to optimize correct code than to correct optimized code. -- Bill 
Harlan 


Re: Restlet causing JVM crashes

2008-07-21 Thread Kevin Conaway

 BTW, Sun hasn't replied to my bug report submission


I wouldn't hold your breath either.  They're notoriously slow about
responding to bug reports.  If they don't deem it worthy of their time, they
won't even put it in their bug tracker for you to follow up on.

On Mon, Jul 21, 2008 at 6:10 AM, Jerome Louvel [EMAIL PROTECTED] wrote:

  Hi Mark,

 I haven't seen this personally yet.

 BTW, Sun hasn't replied to my bug report submission. I don't know if it has
 been discarded or simply delayed... Maybe you should try to submit a report
 yourself, it might have a better fortune...

 Best regards,
 Jerome


  --
 *De :* Mark Derricutt [mailto:[EMAIL PROTECTED]
 *Envoyé :* lundi 21 juillet 2008 06:13
 *À :* discuss@restlet.tigris.org
 *Objet :* Re: Restlet causing JVM crashes

  Hey all,

 This problem's just started to hit again on our production boxes running
 RHEl 3 and RHEL 5 and JDK 1.6_06.

 I tried checking what Kevin changed (volatile to final) but can't see any
 volatile's mentioned in HeaderReader class (but my pretty much everywhere
 else).

 It can't be just us and Kevin seeing this can it?  We're now seeing it
 locally across multiple VM versions.

 Mark

 On Tue, Jun 10, 2008 at 12:12 AM, Kevin Conaway [EMAIL PROTECTED]
 wrote:

 Hi Mark,

 I had the same problem as you.  I tweaked some lines of code in that class
 and recompiled and the issue went away.

 It feels like a bug in the JVM because the error is happening when Hotspot
 decides to recompile the class.  I never did figure out what was causing
 it.

 I had posted to [EMAIL PROTECTED] back in April:

 http://restlet.tigris.org/servlets/ReadMsg?list=codemsgNo=139

 Kevin


 On Wed, Jun 4, 2008 at 12:37 AM, Rob Heittman [EMAIL PROTECTED]
 wrote:

 That's a new one on me, but Hardy has been the locus of a bunch of new
 JVM crash issues, mainly with Athlon processors.  Also there have been some
 similar issues with 64-bit under Red Hat and Fedora.
 This is the Sun JVM I get installing sun-java6-jdk from multiverse, and I
 don't get JVM crashes on P4, Centrino, or Core Duo.

 java version 1.6.0_06
 Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
 Java HotSpot(TM) Client VM (build 10.0-b22, mixed mode, sharing)

  Where did you get yours from?  Direct Sun download?  Hardy tries very
 hard to use OpenJDK, which also doesn't crash for me on P4, Centrino, or
 Core Duo.

 - Rob





 --
 It is easier to optimize correct code than to correct optimized code. --
 Bill Harlan



Re: Restlet causing JVM crashes

2008-07-21 Thread Marcel Casado


 Hi Jerome et al,

 I tried to configure Hotspot  as indicated by Mark. In my case I use 
restlet with Tomcat.  First I  tried to add JVM command line options for 
the compiler when tomcat is started. I use a shell script where I added 
the line below:


-XX:CompileCommand=exclude,com/noelios/restlet/http/HeaderReader,readValue

This did not took effect so I tried a variant of the second option 
provided by Mark   (


http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/gbyzo.html

) it consists in create a file named .hotspot_compiler and place it at 
/tomcat_home/bin with this content :


exclude com/noelios/restlet/http/HeaderReader readValue

this took effect because in catalina.out the line below was printed :

CompilerOracle: exclude com/noelios/restlet/http/HeaderReader.readValue


I tested the restlet apps for a few hours and the JVM did not crash 
anymore. In general the .hotspot_compiler file has to be placed on the 
application directory so if restlet crashes for you due the Hotspot 
compiler, you should placed the file where the log for the crash is created.


--- MY  S Y S T E M  ---

OS:Red Hat Enterprise Linux WS release 4 (Nahant Update 6)

uname:Linux 2.6.9-67.0.7.ELsmp #1 SMP Wed Feb 27 04:47:23 EST 2008 x86_64
libc:glibc 2.3.4 NPTL 2.3.4
rlimit: STACK 10240k, CORE 0k, NPROC 36864, NOFILE 1024, AS infinity
load average:1.66 1.66 1.65

CPU:total 2 (1 cores per cpu, 1 threads per core) family 15 model 4 
stepping 3, cmov, cx8, fxsr, mmx, sse, sse2, sse3


Memory: 4k page, physical 4045152k(56520k free), swap 2048276k(2048068k 
free)


vm_info: Java HotSpot(TM) 64-Bit Server VM (10.0-b22) for linux-amd64 
JRE (1.6.0_06-b02), built on Mar 25 2008 01:03:02 by java_re with gcc 
3.2.2 (SuSE Linux)



Thanks to Mark for pointing to us this solution that save me to refactor 
a lot of code for not be able to use Restlet framework due this JVM bug.



-Marcel


Jerome Louvel wrote:
Thanks for the note, I've added it to the report. Let us know if, on 
the long term, this effectively works around the HotSpot bug in your 
environment.


Best regards,
Jerome


*De :* Mark Derricutt [mailto:[EMAIL PROTECTED]
*Envoyé :* lundi 21 juillet 2008 12:26
*À :* discuss@restlet.tigris.org
*Objet :* Re: Restlet causing JVM crashes

There's apparantly two ways of doing it:

-XX:CompileCommand=exclude,my/pkg/MyClass,theMethod

or

-XX: CompileCommandFile=/my/canned/command/file

The command file can also be .hotspot_compiler in the current 
directory.  And the ,'s can also be spaced.


I found this via http://forums.sun.com/thread.jspa?messageID=1844071

On Mon, Jul 21, 2008 at 10:20 PM, Jerome Louvel [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:


Mark,
 
Thanks for the follow-up.
 
Do you have details on how to configure Hotspot to make it ignore

this method?
 
That might be useful for others. I will add it to the related bug

report as well:
 
Segfaults with HotSpot in 64bit Linux

http://restlet.tigris.org/issues/show_bug.cgi?id=524
 
Best regards,

Jerome
 



*De :* Mark Derricutt [mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]]
*Envoyé :* lundi 21 juillet 2008 12:13

*À :* discuss@restlet.tigris.org mailto:discuss@restlet.tigris.org
*Objet :* Re: Restlet causing JVM crashes

For now we've told hotspot not to compile that method so hopefully
that'll help.  I've been following a similar bug report at Sun
from a problem with Eclipse that has an endless to and fro of its
fixed, oh wait... no its not :(

Mark

On Mon, Jul 21, 2008 at 10:10 PM, Jerome Louvel
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:

Hi Mark,
 
I haven't seen this personally yet.
 
BTW, Sun hasn't replied to my bug report submission. I don't

know if it has been discarded or simply delayed... Maybe you
should try to submit a report yourself, it might have a better
fortune...

Best regards,
Jerome

 



*De :* Mark Derricutt [mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]]
*Envoyé :* lundi 21 juillet 2008 06:13

*À :* discuss@restlet.tigris.org
mailto:discuss@restlet.tigris.org
*Objet :* Re: Restlet causing JVM crashes

Hey all,

This problem's just started to hit again on our production
boxes running RHEl 3 and RHEL 5 and JDK 1.6_06.

I tried checking what Kevin changed (volatile to final) but
can't see any volatile's mentioned in HeaderReader class (but
my pretty much everywhere else).

It can't be just us and Kevin seeing this can it?  We're now
seeing it locally