Re: [Resin-interest] Resin-4.0.5 Watchdog on Shutdown

[Rick Mann]

Thanks!

On Mar 30, 2010, at 15:25:47, Emil Ong wrote:

> On Tue, Mar 30, 2010 at 11:52:15AM -0700, Rick Mann wrote:
>> Ah! Thanks. So, does that mean it's safe to leave the watchdog running, and 
>> just issue a "start" again? I seem to recall Resin getting mad that someone 
>> already had the port when I did that.
> 
> That's correct: you can just leave the watchdog running and issue a
> start. Let us know if you run into the issue with port conflicts again.
> It should only be a configuration issue.
> 
> Emil
> 
>> On Mar 30, 2010, at 11:49:59, Emil Ong wrote:
>> 
>>> Hi Aaron,
>>> 
>>> This is the correct behavior. In 4.0.x, we changed the watchdog to be a
>>> long-lived process.  If you'd like to shut it down, along with all
>>> running resin instances, use the "shutdown" command.  We're in the
>>> process of updating the documentation this week to reflect the change.
>>> 
>>> Thanks,
>>> Emil
>>> 
>>> On Tue, Mar 30, 2010 at 11:01:23AM -0500, Aaron Freeman wrote:
 When we try to stop the resin-4.0.5 processes using:
 
 $JAVA_HOME/bin/java \
 -server \
 -Djava.util.logging.manager=com.caucho.log.LogManagerImpl \
 -Djava.security.egd=/dev/urandom \
 -Dhost=${SERVER} \
 -Dresin.home=${RESIN_HOME} \
 -jar ${RESIN_HOME}/lib/resin.jar \
 -conf ${SERVER_ROOT}/conf/resin.xml \
 $*
 
 Where we pass in "start" to start it and "stop" to stop the server.  The 
 main resin java process stops, but the watchdog does not.  Is that 
 expected behavior (and thus a change from 3.0.x)?  If so, how do we stop 
 the watchdog java process?  I believe Rick Mann reported the same 
 issue.  Also we are running uncompiled, if that matters.
 
 Thanks,
 
 Aaron
 
 
 ___
 resin-interest mailing list
 resin-interest@caucho.com
 http://maillist.caucho.com/mailman/listinfo/resin-interest
>>> 
>>> 
>>> ___
>>> resin-interest mailing list
>>> resin-interest@caucho.com
>>> http://maillist.caucho.com/mailman/listinfo/resin-interest
>> 
>> 
>> 
>> ___
>> resin-interest mailing list
>> resin-interest@caucho.com
>> http://maillist.caucho.com/mailman/listinfo/resin-interest
> 
> 
> ___
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] PermGen problems installing Confluence

[Rick Mann]

Thanks!

On Mar 30, 2010, at 15:28:03, Scott Ferguson wrote:

> Rick Mann wrote:
>> Scott, are you guys able to run Confluence on 4.0.5?
>> 
> I haven't checked. If it's just PermGen, though, you should be able to 
> just expand it.
> 
> You can look in /resin-admin in the JMX section, by the way, to double 
> check the setting, as well as checking the current PermGen size. (and/or 
> checking the number of classes loaded.)
> 
> -- Scott
>> On Mar 30, 2010, at 10:13:16, Rick Mann wrote:
>> 
>> 
>>> That's a great suggestion, if only I knew how to use JConsole to do that ;-)
>>> 
>>> On Mar 30, 2010, at 03:09:43, d.lo...@uib.es wrote:
>>> 
>>> 
 Doh! :) I'm sorry, I thought you meant 256m heap. Yes, 256m PermGen  
 should be more than enough, unless it has turned into a memory hog in  
 the last version.
 
 Have you checked, with JConsole for example, that the setting is  
 really being taken into account? Just to discard if it is a  
 configuration or runtime issue.
 
 S!
 D.
 
 S'està citant Rick Mann :
 
 
> But you just said you're running it using 192m. Did I miss   
> something? I only have Confluence (so far), and a handful of other   
> webapps.
> 
> On Mar 29, 2010, at 05:11:21, Daniel López wrote:
> 
> 
>> I thought I had read it somewhere but I have not been able to find it in
>> the current documentation, so it could be an empiric measure, but in any
>> case I'm pretty sure 256m was not enough, at least for JIRA+confluence
>> in the same container instance.
>> 
>> S!
>> D.
>> 
>> Rick Mann escribió:
>> 
>>> Thanks for the suggestion, Daniel. I did in fact try, just like   
>>> that. Set it to 256m.
>>> 
>>> On Mar 29, 2010, at 01:00:36, Daniel López wrote:
>>> 
>>> 
 How have you increased the MaxPermGen of your resin install?
 Just ot make sure you have not increased the size of the watchdog
 instead of the "real" instance, which happened to me at the beginning 
 :).
 Confluence has so many JSPs and other internal classes that it needs
 quite a chunk of memory for that.
 
 The node where we are running a JIRA & Confluence instance has these
 settings inside resin.xml (Resin 3.1.5 and Confluence 2.8.1 though):
 
 -server
 -XX:PermSize=128m
 -XX:MaxPermSize=192m
 -Xmx512m
 -Xms512m
 -Xss1m
 -Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
 -Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl
 
 S!
 D.
 
 Rick Mann escribió:
 
> I'm trying to install Confluence 3.2 on my Resin-4.0.5 setup,   
> and it seems to go well until the step where it builds the   
> database. Then it gets PermGen out of memory errors. I'm   
> installing the expanded WAR, using a JDBC datasource against a   
> MySQL database (everything else runs like this).
> 
> I also tried increasing the MaxPermGen to 256 m. No luck.
> 
> Any ideas? Has anyone gotten this to work?
> 
 
 
 
 
 
 
 ___
 resin-interest mailing list
 resin-interest@caucho.com
 http://maillist.caucho.com/mailman/listinfo/resin-interest
 
>>> 
>>> ___
>>> resin-interest mailing list
>>> resin-interest@caucho.com
>>> http://maillist.caucho.com/mailman/listinfo/resin-interest
>>> 
>> 
>> 
>> 
>> ___
>> resin-interest mailing list
>> resin-interest@caucho.com
>> http://maillist.caucho.com/mailman/listinfo/resin-interest
>> 
>> 
> 
> 
> 
> ___
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] PermGen problems installing Confluence

[Scott Ferguson]

Rick Mann wrote:
> Scott, are you guys able to run Confluence on 4.0.5?
>   
I haven't checked. If it's just PermGen, though, you should be able to 
just expand it.

You can look in /resin-admin in the JMX section, by the way, to double 
check the setting, as well as checking the current PermGen size. (and/or 
checking the number of classes loaded.)

-- Scott
> On Mar 30, 2010, at 10:13:16, Rick Mann wrote:
>
>   
>> That's a great suggestion, if only I knew how to use JConsole to do that ;-)
>>
>> On Mar 30, 2010, at 03:09:43, d.lo...@uib.es wrote:
>>
>> 
>>> Doh! :) I'm sorry, I thought you meant 256m heap. Yes, 256m PermGen  
>>> should be more than enough, unless it has turned into a memory hog in  
>>> the last version.
>>>
>>> Have you checked, with JConsole for example, that the setting is  
>>> really being taken into account? Just to discard if it is a  
>>> configuration or runtime issue.
>>>
>>> S!
>>> D.
>>>
>>> S'està citant Rick Mann :
>>>
>>>   
 But you just said you're running it using 192m. Did I miss   
 something? I only have Confluence (so far), and a handful of other   
 webapps.

 On Mar 29, 2010, at 05:11:21, Daniel López wrote:

 
> I thought I had read it somewhere but I have not been able to find it in
> the current documentation, so it could be an empiric measure, but in any
> case I'm pretty sure 256m was not enough, at least for JIRA+confluence
> in the same container instance.
>
> S!
> D.
>
> Rick Mann escribió:
>   
>> Thanks for the suggestion, Daniel. I did in fact try, just like   
>> that. Set it to 256m.
>>
>> On Mar 29, 2010, at 01:00:36, Daniel López wrote:
>>
>> 
>>> How have you increased the MaxPermGen of your resin install?
>>> Just ot make sure you have not increased the size of the watchdog
>>> instead of the "real" instance, which happened to me at the beginning 
>>> :).
>>> Confluence has so many JSPs and other internal classes that it needs
>>> quite a chunk of memory for that.
>>>
>>> The node where we are running a JIRA & Confluence instance has these
>>> settings inside resin.xml (Resin 3.1.5 and Confluence 2.8.1 though):
>>>
>>> -server
>>> -XX:PermSize=128m
>>> -XX:MaxPermSize=192m
>>> -Xmx512m
>>> -Xms512m
>>> -Xss1m
>>> -Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
>>> -Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl
>>>
>>> S!
>>> D.
>>>
>>> Rick Mann escribió:
>>>   
 I'm trying to install Confluence 3.2 on my Resin-4.0.5 setup,   
 and it seems to go well until the step where it builds the   
 database. Then it gets PermGen out of memory errors. I'm   
 installing the expanded WAR, using a JDBC datasource against a   
 MySQL database (everything else runs like this).

 I also tried increasing the MaxPermGen to 256 m. No luck.

 Any ideas? Has anyone gotten this to work?
 
>>> 
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> resin-interest mailing list
>>> resin-interest@caucho.com
>>> http://maillist.caucho.com/mailman/listinfo/resin-interest
>>>   
>>
>> ___
>> resin-interest mailing list
>> resin-interest@caucho.com
>> http://maillist.caucho.com/mailman/listinfo/resin-interest
>> 
>
>
>
> ___
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest
>
>   



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Resin-4.0.5 Watchdog on Shutdown

[Emil Ong]

On Tue, Mar 30, 2010 at 11:52:15AM -0700, Rick Mann wrote:
> Ah! Thanks. So, does that mean it's safe to leave the watchdog running, and 
> just issue a "start" again? I seem to recall Resin getting mad that someone 
> already had the port when I did that.

That's correct: you can just leave the watchdog running and issue a
start. Let us know if you run into the issue with port conflicts again.
It should only be a configuration issue.

Emil

> On Mar 30, 2010, at 11:49:59, Emil Ong wrote:
> 
> > Hi Aaron,
> > 
> > This is the correct behavior. In 4.0.x, we changed the watchdog to be a
> > long-lived process.  If you'd like to shut it down, along with all
> > running resin instances, use the "shutdown" command.  We're in the
> > process of updating the documentation this week to reflect the change.
> > 
> > Thanks,
> > Emil
> > 
> > On Tue, Mar 30, 2010 at 11:01:23AM -0500, Aaron Freeman wrote:
> >> When we try to stop the resin-4.0.5 processes using:
> >> 
> >> $JAVA_HOME/bin/java \
> >> -server \
> >> -Djava.util.logging.manager=com.caucho.log.LogManagerImpl \
> >> -Djava.security.egd=/dev/urandom \
> >> -Dhost=${SERVER} \
> >> -Dresin.home=${RESIN_HOME} \
> >> -jar ${RESIN_HOME}/lib/resin.jar \
> >> -conf ${SERVER_ROOT}/conf/resin.xml \
> >> $*
> >> 
> >> Where we pass in "start" to start it and "stop" to stop the server.  The 
> >> main resin java process stops, but the watchdog does not.  Is that 
> >> expected behavior (and thus a change from 3.0.x)?  If so, how do we stop 
> >> the watchdog java process?  I believe Rick Mann reported the same 
> >> issue.  Also we are running uncompiled, if that matters.
> >> 
> >> Thanks,
> >> 
> >> Aaron
> >> 
> >> 
> >> ___
> >> resin-interest mailing list
> >> resin-interest@caucho.com
> >> http://maillist.caucho.com/mailman/listinfo/resin-interest
> > 
> > 
> > ___
> > resin-interest mailing list
> > resin-interest@caucho.com
> > http://maillist.caucho.com/mailman/listinfo/resin-interest
> 
> 
> 
> ___
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] PermGen problems installing Confluence

[Rick Mann]

Scott, are you guys able to run Confluence on 4.0.5?

On Mar 30, 2010, at 10:13:16, Rick Mann wrote:

> That's a great suggestion, if only I knew how to use JConsole to do that ;-)
> 
> On Mar 30, 2010, at 03:09:43, d.lo...@uib.es wrote:
> 
>> Doh! :) I'm sorry, I thought you meant 256m heap. Yes, 256m PermGen  
>> should be more than enough, unless it has turned into a memory hog in  
>> the last version.
>> 
>> Have you checked, with JConsole for example, that the setting is  
>> really being taken into account? Just to discard if it is a  
>> configuration or runtime issue.
>> 
>> S!
>> D.
>> 
>> S'està citant Rick Mann :
>> 
>>> But you just said you're running it using 192m. Did I miss   
>>> something? I only have Confluence (so far), and a handful of other   
>>> webapps.
>>> 
>>> On Mar 29, 2010, at 05:11:21, Daniel López wrote:
>>> 
 I thought I had read it somewhere but I have not been able to find it in
 the current documentation, so it could be an empiric measure, but in any
 case I'm pretty sure 256m was not enough, at least for JIRA+confluence
 in the same container instance.
 
 S!
 D.
 
 Rick Mann escribió:
> Thanks for the suggestion, Daniel. I did in fact try, just like   
> that. Set it to 256m.
> 
> On Mar 29, 2010, at 01:00:36, Daniel López wrote:
> 
>> How have you increased the MaxPermGen of your resin install?
>> Just ot make sure you have not increased the size of the watchdog
>> instead of the "real" instance, which happened to me at the beginning :).
>> Confluence has so many JSPs and other internal classes that it needs
>> quite a chunk of memory for that.
>> 
>> The node where we are running a JIRA & Confluence instance has these
>> settings inside resin.xml (Resin 3.1.5 and Confluence 2.8.1 though):
>> 
>> -server
>> -XX:PermSize=128m
>> -XX:MaxPermSize=192m
>> -Xmx512m
>> -Xms512m
>> -Xss1m
>> -Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
>> -Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl
>> 
>> S!
>> D.
>> 
>> Rick Mann escribió:
>>> I'm trying to install Confluence 3.2 on my Resin-4.0.5 setup,   
>>> and it seems to go well until the step where it builds the   
>>> database. Then it gets PermGen out of memory errors. I'm   
>>> installing the expanded WAR, using a JDBC datasource against a   
>>> MySQL database (everything else runs like this).
>>> 
>>> I also tried increasing the MaxPermGen to 256 m. No luck.
>>> 
>>> Any ideas? Has anyone gotten this to work?
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> resin-interest mailing list
>> resin-interest@caucho.com
>> http://maillist.caucho.com/mailman/listinfo/resin-interest
> 
> 
> 
> ___
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] gzipfilter encoding problem for web.xml declared error pages

[Alan Wright]

Hi

We are using resin 2.1.17 (yes i know we need to upgrade!) and are 
starting to implement role based access control using role declaration 
on Struts actions.

I have declared a 403 error page in web.xml and am experiencing a 
problem which I have tracked down to interaction with the gzipfilter 
because everything works beautifully with the gzipfilter disabled, but 
with the filter enabled I am getting:

Content Encoding Error

The page you are trying to view cannot be shown because it uses an 
invalid or unsupported form of compression.


in firefox and equivalent errors in other browsers.



I think that the response is being encoded twice by the time the browser 
sees it.

Has anyone come across this and figured out a way round it? 
Is it a known issue with 2.1.17 gzipfilter that is resolved in later 
versions of resin (if so what was the core issue)?
Is it something to do with the web.xml declared error page being a 
redirect that shouldn't be gzipped in the first place (just guessing here)?

Any suggestions would be welcome

Thanks


Alan



-- 


Alan Wright
Athene Systems

tel 0845 230 9803


Athene Systems Limited
Registered Office:
Shieling House
Invincible Road
Farnborough
GU14 7QU

Registered in England and Wales No. 3156080



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Resin-4.0.5 Watchdog on Shutdown

[Aaron Freeman]

Perfect, thanks!

Aaron


On 3/30/2010 1:49 PM, Emil Ong wrote:
> Hi Aaron,
>
> This is the correct behavior. In 4.0.x, we changed the watchdog to be a
> long-lived process.  If you'd like to shut it down, along with all
> running resin instances, use the "shutdown" command.  We're in the
> process of updating the documentation this week to reflect the change.
>
> Thanks,
> Emil
>
> On Tue, Mar 30, 2010 at 11:01:23AM -0500, Aaron Freeman wrote:
>
>> When we try to stop the resin-4.0.5 processes using:
>>
>> $JAVA_HOME/bin/java \
>> -server \
>> -Djava.util.logging.manager=com.caucho.log.LogManagerImpl \
>> -Djava.security.egd=/dev/urandom \
>> -Dhost=${SERVER} \
>> -Dresin.home=${RESIN_HOME} \
>> -jar ${RESIN_HOME}/lib/resin.jar \
>> -conf ${SERVER_ROOT}/conf/resin.xml \
>> $*
>>
>> Where we pass in "start" to start it and "stop" to stop the server.  The
>> main resin java process stops, but the watchdog does not.  Is that
>> expected behavior (and thus a change from 3.0.x)?  If so, how do we stop
>> the watchdog java process?  I believe Rick Mann reported the same
>> issue.  Also we are running uncompiled, if that matters.
>>
>> Thanks,
>>
>> Aaron
>>  



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Resin-4.0.5 Watchdog on Shutdown

[Scott Ferguson]

Rick Mann wrote:
> I'm seeing that same behavior.
>   
To shutdown the watchdog, use "shutdown". "start/stop" only starts and 
stops the Resin instance.

-- Scott
> On Mar 30, 2010, at 09:01:23, Aaron Freeman wrote:
>
>   
>> When we try to stop the resin-4.0.5 processes using:
>>
>> $JAVA_HOME/bin/java \
>> -server \
>> -Djava.util.logging.manager=com.caucho.log.LogManagerImpl \
>> -Djava.security.egd=/dev/urandom \
>> -Dhost=${SERVER} \
>> -Dresin.home=${RESIN_HOME} \
>> -jar ${RESIN_HOME}/lib/resin.jar \
>> -conf ${SERVER_ROOT}/conf/resin.xml \
>> $*
>>
>> Where we pass in "start" to start it and "stop" to stop the server.  The 
>> main resin java process stops, but the watchdog does not.  Is that 
>> expected behavior (and thus a change from 3.0.x)?  If so, how do we stop 
>> the watchdog java process?  I believe Rick Mann reported the same 
>> issue.  Also we are running uncompiled, if that matters.
>>
>> Thanks,
>>
>> Aaron
>>
>>
>> ___
>> resin-interest mailing list
>> resin-interest@caucho.com
>> http://maillist.caucho.com/mailman/listinfo/resin-interest
>> 
>
>
>
> ___
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest
>
>   



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Resin-4.0.5 Watchdog on Shutdown

[Rick Mann]

Ah! Thanks. So, does that mean it's safe to leave the watchdog running, and 
just issue a "start" again? I seem to recall Resin getting mad that someone 
already had the port when I did that.

On Mar 30, 2010, at 11:49:59, Emil Ong wrote:

> Hi Aaron,
> 
> This is the correct behavior. In 4.0.x, we changed the watchdog to be a
> long-lived process.  If you'd like to shut it down, along with all
> running resin instances, use the "shutdown" command.  We're in the
> process of updating the documentation this week to reflect the change.
> 
> Thanks,
> Emil
> 
> On Tue, Mar 30, 2010 at 11:01:23AM -0500, Aaron Freeman wrote:
>> When we try to stop the resin-4.0.5 processes using:
>> 
>> $JAVA_HOME/bin/java \
>> -server \
>> -Djava.util.logging.manager=com.caucho.log.LogManagerImpl \
>> -Djava.security.egd=/dev/urandom \
>> -Dhost=${SERVER} \
>> -Dresin.home=${RESIN_HOME} \
>> -jar ${RESIN_HOME}/lib/resin.jar \
>> -conf ${SERVER_ROOT}/conf/resin.xml \
>> $*
>> 
>> Where we pass in "start" to start it and "stop" to stop the server.  The 
>> main resin java process stops, but the watchdog does not.  Is that 
>> expected behavior (and thus a change from 3.0.x)?  If so, how do we stop 
>> the watchdog java process?  I believe Rick Mann reported the same 
>> issue.  Also we are running uncompiled, if that matters.
>> 
>> Thanks,
>> 
>> Aaron
>> 
>> 
>> ___
>> resin-interest mailing list
>> resin-interest@caucho.com
>> http://maillist.caucho.com/mailman/listinfo/resin-interest
> 
> 
> ___
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Resin-4.0.5 Watchdog on Shutdown

[Rick Mann]

I'm seeing that same behavior.

On Mar 30, 2010, at 09:01:23, Aaron Freeman wrote:

> When we try to stop the resin-4.0.5 processes using:
> 
> $JAVA_HOME/bin/java \
> -server \
> -Djava.util.logging.manager=com.caucho.log.LogManagerImpl \
> -Djava.security.egd=/dev/urandom \
> -Dhost=${SERVER} \
> -Dresin.home=${RESIN_HOME} \
> -jar ${RESIN_HOME}/lib/resin.jar \
> -conf ${SERVER_ROOT}/conf/resin.xml \
> $*
> 
> Where we pass in "start" to start it and "stop" to stop the server.  The 
> main resin java process stops, but the watchdog does not.  Is that 
> expected behavior (and thus a change from 3.0.x)?  If so, how do we stop 
> the watchdog java process?  I believe Rick Mann reported the same 
> issue.  Also we are running uncompiled, if that matters.
> 
> Thanks,
> 
> Aaron
> 
> 
> ___
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Resin-4.0.5 Watchdog on Shutdown

[Emil Ong]

Hi Aaron,

This is the correct behavior. In 4.0.x, we changed the watchdog to be a
long-lived process.  If you'd like to shut it down, along with all
running resin instances, use the "shutdown" command.  We're in the
process of updating the documentation this week to reflect the change.

Thanks,
Emil

On Tue, Mar 30, 2010 at 11:01:23AM -0500, Aaron Freeman wrote:
> When we try to stop the resin-4.0.5 processes using:
> 
> $JAVA_HOME/bin/java \
> -server \
> -Djava.util.logging.manager=com.caucho.log.LogManagerImpl \
> -Djava.security.egd=/dev/urandom \
> -Dhost=${SERVER} \
> -Dresin.home=${RESIN_HOME} \
> -jar ${RESIN_HOME}/lib/resin.jar \
> -conf ${SERVER_ROOT}/conf/resin.xml \
> $*
> 
> Where we pass in "start" to start it and "stop" to stop the server.  The 
> main resin java process stops, but the watchdog does not.  Is that 
> expected behavior (and thus a change from 3.0.x)?  If so, how do we stop 
> the watchdog java process?  I believe Rick Mann reported the same 
> issue.  Also we are running uncompiled, if that matters.
> 
> Thanks,
> 
> Aaron
> 
> 
> ___
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Hibernate transactions

[Wesley Wu]

More to mention about MDBs (Message Driven Beans):

1. Always use @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
on public void onMessage(Message message).
because the impl of Resin MDBs has severe reenter synchronization problem.
If I start a transaction before onMessage() being called there would be
several transactions tried to crossing commit in unexpected manner.

2. Inject a ExecutorService to do the real stuff.

public class MyMessageDrivenBean implements MessageListener {
@Inject
ExecutorService executorService;
private InjectManager _webBeans = InjectManager.create();

@Override
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
public void onMessage(Message message) {
 RealStuffRunnable runnable = webBeans.getReference(RealStuffRunnable
.class);
 // set some properties of runnable
 ...
 // run it in a new thread
 executorService.execute(runnable);
}
}

3. Use @TransactionAttribute on RealStuffRunnable.run()

Thus my real stuff will not suffer from the reenter and crossing commit.

Any better solutions?

-Wesley
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Hibernate transactions

[Wesley Wu]

I will not call UserTransaction.begin() when all db operations are SELECT.
I create a EntityManager from emf to do SELECT stuff with no transaction at
all.

When I detected there're some update/delete operations, I'll do this:
1. close the former created EntityManager if there is one (for precedent
SELECT op)
2. call UserTransaction.begin()
3. create a new EntityManager
4. do left jobs
5. commint() on success or rollback() on failure.
*. finally (always) close the em (bounded to current thread) and set current
ThreadLocal to null.

This worked for me in the last three years in several heavy loaded websites.

-Wesley

2010/3/31 Scott Ferguson 

> Why would calling UserTransaction in your code be faster? Essentially,
> all @TransactionAttribute does is call UserTransaction.begin() and
> commit(). (Any extra overhead should be minimal, especially compared to
> the actual transaction.)
>
> -- Scott
>
>
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Hibernate transactions

[Stargazer]

On 30-Mar-2010 18:03, Scott Ferguson wrote:
> Wesley Wu wrote:
>
>> Yes. One minor problem:
>>
>> @PersistentContext should be @PersistentUnit.
>>  
>   would calling UserTransaction in your code be faster? Essentially,
>


I don't know about the finer details, but looking back on this now it's 
fixed it seems the example is really only half done. A fuller one 
showing not just how to read the db but how to update it would be more 
real-world and less frustrating for those making the switch.




___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Hibernate transactions

[Stargazer]

On 30-Mar-2010 17:54, Wesley Wu wrote:
> Yes. One minor problem:
>
> @PersistentContext should be @PersistentUnit.
>
Doh!
Great, works now. Thanks for your help!




___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] PermGen problems installing Confluence

[Rick Mann]

That's a great suggestion, if only I knew how to use JConsole to do that ;-)

On Mar 30, 2010, at 03:09:43, d.lo...@uib.es wrote:

> Doh! :) I'm sorry, I thought you meant 256m heap. Yes, 256m PermGen  
> should be more than enough, unless it has turned into a memory hog in  
> the last version.
> 
> Have you checked, with JConsole for example, that the setting is  
> really being taken into account? Just to discard if it is a  
> configuration or runtime issue.
> 
> S!
> D.
> 
> S'està citant Rick Mann :
> 
>> But you just said you're running it using 192m. Did I miss   
>> something? I only have Confluence (so far), and a handful of other   
>> webapps.
>> 
>> On Mar 29, 2010, at 05:11:21, Daniel López wrote:
>> 
>>> I thought I had read it somewhere but I have not been able to find it in
>>> the current documentation, so it could be an empiric measure, but in any
>>> case I'm pretty sure 256m was not enough, at least for JIRA+confluence
>>> in the same container instance.
>>> 
>>> S!
>>> D.
>>> 
>>> Rick Mann escribió:
 Thanks for the suggestion, Daniel. I did in fact try, just like   
 that. Set it to 256m.
 
 On Mar 29, 2010, at 01:00:36, Daniel López wrote:
 
> How have you increased the MaxPermGen of your resin install?
> Just ot make sure you have not increased the size of the watchdog
> instead of the "real" instance, which happened to me at the beginning :).
> Confluence has so many JSPs and other internal classes that it needs
> quite a chunk of memory for that.
> 
> The node where we are running a JIRA & Confluence instance has these
> settings inside resin.xml (Resin 3.1.5 and Confluence 2.8.1 though):
> 
> -server
> -XX:PermSize=128m
> -XX:MaxPermSize=192m
> -Xmx512m
> -Xms512m
> -Xss1m
> -Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
> -Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl
> 
> S!
> D.
> 
> Rick Mann escribió:
>> I'm trying to install Confluence 3.2 on my Resin-4.0.5 setup,   
>> and it seems to go well until the step where it builds the   
>> database. Then it gets PermGen out of memory errors. I'm   
>> installing the expanded WAR, using a JDBC datasource against a   
>> MySQL database (everything else runs like this).
>> 
>> I also tried increasing the MaxPermGen to 256 m. No luck.
>> 
>> Any ideas? Has anyone gotten this to work?
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Hibernate transactions

[Scott Ferguson]

Wesley Wu wrote:
> Yes. One minor problem:
>
> @PersistentContext should be @PersistentUnit.
>
>
> That's exactly what I used to do in the past three years.
>
> I controlled the entitymanager and transaction by my own code in a JPA 
> wrapper class,
> and gained great performance advantage over automatic transaction 
> handling like @TransactionAttribute.
Why would calling UserTransaction in your code be faster? Essentially, 
all @TransactionAttribute does is call UserTransaction.begin() and 
commit(). (Any extra overhead should be minimal, especially compared to 
the actual transaction.)

-- Scott
>
> I never inject a @PersistentContext or never use a container provided 
> EntityManager. 
> I use ThreadLocal to maintain every EntityManager instance.
>
> -Wesley
>
> 2010/3/30 Stargazer  >
>
> On 30-Mar-2010 09:34, Wesley Wu wrote:
> > To make set method auto translated into a UPDATE clause, the
> > entitymanager should be opened after a transaction begins.
> >
> >
> Sincere thanks again, hopefully this will all help others coming
> across
> it in the future.
>
> If I understood you correctly I made those changes and now get
> example.CourseServlet.emf : @PersistenceContext field must be
> assignable
> from EntityManager.
>
> Heres the new full servlet:
>
> package example;
>
> import java.io.IOException;
> import java.io.PrintWriter;
>
> import javax.inject.Inject;
> import javax.persistence.EntityManager;
> import javax.persistence.EntityManagerFactory;
> import javax.persistence.PersistenceContext;
> import javax.servlet.ServletException;
> import javax.servlet.http.HttpServlet;
> import javax.servlet.http.HttpServletRequest;
> import javax.servlet.http.HttpServletResponse;
> import javax.transaction.UserTransaction;
>
> public class CourseServlet extends HttpServlet
> {
>   // Resin IoC will inject this
>   @PersistenceContext(unitName="example")
>   EntityManagerFactory emf;
>
>   @Inject
>   private UserTransaction ut;
>
>   public void service(HttpServletRequest request, HttpServletResponse
> response)
> throws IOException, ServletException
>   {
> PrintWriter out = response.getWriter();
> response.setContentType("text/html");
>
> EntityManager em = null;
> try {
> ut.begin();
> em = emf.createEntityManager();
> CourseBean updateCourse = em.find(CourseBean.class, new
> Integer(1));
> updateCourse.setCourse("Magic");
> ut.commit();
> } catch (Exception e) {
> e.printStackTrace();
> } finally {
> if (em != null && em.isOpen()) {
> em.close();
> }
> }
>   }
> }
>
>
>
>
> ___
> resin-interest mailing list
> resin-interest@caucho.com 
> http://maillist.caucho.com/mailman/listinfo/resin-interest
>
>
> 
>
> ___
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest
>   



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Hibernate transactions

[Wesley Wu]

Yes. One minor problem:

@PersistentContext should be @PersistentUnit.


That's exactly what I used to do in the past three years.

I controlled the entitymanager and transaction by my own code in a JPA
wrapper class,
and gained great performance advantage over automatic transaction handling
like @TransactionAttribute.

I never inject a @PersistentContext or never use a container provided
EntityManager.
I use ThreadLocal to maintain every EntityManager instance.

-Wesley

2010/3/30 Stargazer 

> On 30-Mar-2010 09:34, Wesley Wu wrote:
> > To make set method auto translated into a UPDATE clause, the
> > entitymanager should be opened after a transaction begins.
> >
> >
> Sincere thanks again, hopefully this will all help others coming across
> it in the future.
>
> If I understood you correctly I made those changes and now get
> example.CourseServlet.emf : @PersistenceContext field must be assignable
> from EntityManager.
>
> Heres the new full servlet:
>
> package example;
>
> import java.io.IOException;
> import java.io.PrintWriter;
>
> import javax.inject.Inject;
> import javax.persistence.EntityManager;
> import javax.persistence.EntityManagerFactory;
> import javax.persistence.PersistenceContext;
> import javax.servlet.ServletException;
> import javax.servlet.http.HttpServlet;
> import javax.servlet.http.HttpServletRequest;
> import javax.servlet.http.HttpServletResponse;
> import javax.transaction.UserTransaction;
>
> public class CourseServlet extends HttpServlet
> {
>   // Resin IoC will inject this
>   @PersistenceContext(unitName="example")
>EntityManagerFactory emf;
>
>   @Inject
>   private UserTransaction ut;
>
>   public void service(HttpServletRequest request, HttpServletResponse
> response)
> throws IOException, ServletException
>   {
> PrintWriter out = response.getWriter();
> response.setContentType("text/html");
>
>  EntityManager em = null;
> try {
> ut.begin();
>  em = emf.createEntityManager();
> CourseBean updateCourse = em.find(CourseBean.class, new
> Integer(1));
> updateCourse.setCourse("Magic");
> ut.commit();
> } catch (Exception e) {
> e.printStackTrace();
> } finally {
> if (em != null && em.isOpen()) {
> em.close();
> }
> }
>   }
> }
>
>
>
>
> ___
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest
>
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] Resin-4.0.5 Watchdog on Shutdown

[Aaron Freeman]

When we try to stop the resin-4.0.5 processes using:

$JAVA_HOME/bin/java \
-server \
-Djava.util.logging.manager=com.caucho.log.LogManagerImpl \
-Djava.security.egd=/dev/urandom \
-Dhost=${SERVER} \
-Dresin.home=${RESIN_HOME} \
-jar ${RESIN_HOME}/lib/resin.jar \
-conf ${SERVER_ROOT}/conf/resin.xml \
$*

Where we pass in "start" to start it and "stop" to stop the server.  The 
main resin java process stops, but the watchdog does not.  Is that 
expected behavior (and thus a change from 3.0.x)?  If so, how do we stop 
the watchdog java process?  I believe Rick Mann reported the same 
issue.  Also we are running uncompiled, if that matters.

Thanks,

Aaron


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] PermGen problems installing Confluence

[d . lopez]

Doh! :) I'm sorry, I thought you meant 256m heap. Yes, 256m PermGen  
should be more than enough, unless it has turned into a memory hog in  
the last version.

Have you checked, with JConsole for example, that the setting is  
really being taken into account? Just to discard if it is a  
configuration or runtime issue.

S!
D.

S'està citant Rick Mann :

> But you just said you're running it using 192m. Did I miss   
> something? I only have Confluence (so far), and a handful of other   
> webapps.
>
> On Mar 29, 2010, at 05:11:21, Daniel López wrote:
>
>> I thought I had read it somewhere but I have not been able to find it in
>> the current documentation, so it could be an empiric measure, but in any
>> case I'm pretty sure 256m was not enough, at least for JIRA+confluence
>> in the same container instance.
>>
>> S!
>> D.
>>
>> Rick Mann escribió:
>>> Thanks for the suggestion, Daniel. I did in fact try, just like   
>>> that. Set it to 256m.
>>>
>>> On Mar 29, 2010, at 01:00:36, Daniel López wrote:
>>>
 How have you increased the MaxPermGen of your resin install?
 Just ot make sure you have not increased the size of the watchdog
 instead of the "real" instance, which happened to me at the beginning :).
 Confluence has so many JSPs and other internal classes that it needs
 quite a chunk of memory for that.

 The node where we are running a JIRA & Confluence instance has these
 settings inside resin.xml (Resin 3.1.5 and Confluence 2.8.1 though):

 -server
 -XX:PermSize=128m
 -XX:MaxPermSize=192m
 -Xmx512m
 -Xms512m
 -Xss1m
 -Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
 -Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl

 S!
 D.

 Rick Mann escribió:
> I'm trying to install Confluence 3.2 on my Resin-4.0.5 setup,   
> and it seems to go well until the step where it builds the   
> database. Then it gets PermGen out of memory errors. I'm   
> installing the expanded WAR, using a JDBC datasource against a   
> MySQL database (everything else runs like this).
>
> I also tried increasing the MaxPermGen to 256 m. No luck.
>
> Any ideas? Has anyone gotten this to work?








___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Hibernate transactions

[Stargazer]

On 30-Mar-2010 09:34, Wesley Wu wrote:
> To make set method auto translated into a UPDATE clause, the
> entitymanager should be opened after a transaction begins.
>
>
Sincere thanks again, hopefully this will all help others coming across 
it in the future.

If I understood you correctly I made those changes and now get
example.CourseServlet.emf : @PersistenceContext field must be assignable 
from EntityManager.

Heres the new full servlet:

package example;

import java.io.IOException;
import java.io.PrintWriter;

import javax.inject.Inject;
import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.PersistenceContext;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.transaction.UserTransaction;

public class CourseServlet extends HttpServlet
{
   // Resin IoC will inject this
   @PersistenceContext(unitName="example")
   EntityManagerFactory emf;

   @Inject
   private UserTransaction ut;

   public void service(HttpServletRequest request, HttpServletResponse 
response)
 throws IOException, ServletException
   {
 PrintWriter out = response.getWriter();
 response.setContentType("text/html");

 EntityManager em = null;
 try {
 ut.begin();
 em = emf.createEntityManager();
 CourseBean updateCourse = em.find(CourseBean.class, new 
Integer(1));
 updateCourse.setCourse("Magic");
 ut.commit();
 } catch (Exception e) {
 e.printStackTrace();
 } finally {
 if (em != null && em.isOpen()) {
 em.close();
 }
 }
   }
}




___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Hibernate transactions

[Wesley Wu]

To make set method auto translated into a UPDATE clause, the
entitymanager should be opened after a transaction begins.

@PersistenceUnit(unitName="example")
EntityManagerFactory emf;

EntityManager em;
try {
   ut.begin();
   EntityManager em= emf.createEntityManager();
   CourseBean updateCourse = em.find(CourseBean.class, new
Integer(1));
   updateCourse.setCourse("Magic");
   ut.commit();
   } catch (Exception e) {
   e.printStackTrace();
   } finally {
   if (em != null && em.isOpen()) {
   em.close();
  }
   }


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Hibernate transactions

[Stargazer]

On 30-Mar-2010 06:42, Wesley Wu wrote:
>  try {
>  ut.begin();
>  CourseBean updateCourse = _manager.find(CourseBean.class, new
> Integer(1));
>  updateCourse.setCourse("Magic");
>  ut.commit();
>  } catch (Exception e) {
>  e.printStackTrace();
>  }
>
> will work.
>
> -Wesley
>
>
>
Thanks, but theres clearly something basic wrong here as that change 
made no difference. If I add



to persistence.xml I see in the console

Hibernate: select coursebean0_.id as id0_0_, coursebean0_.course as 
course0_0_, coursebean0_.teacher as teacher0_0_ from basic_courses 
coursebean0_ where coursebean0_.id=?
Hibernate: select coursebean0_.id as id0_0_, coursebean0_.course as 
course0_0_, coursebean0_.teacher as teacher0_0_ from basic_courses 
coursebean0_ where coursebean0_.id=?

But no attempt at a write. Single stepping the code proves the 
transaction is being executed.

> ___
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest
>
>




___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest