Re: [Resin-interest] Hibernate transactions

2010-03-30 Thread 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

property name=hibernate.show_sql value=true/

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

Re: [Resin-interest] Hibernate transactions

2010-03-30 Thread 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

2010-03-30 Thread 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] PermGen problems installing Confluence

2010-03-30 Thread 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 rm...@latencyzero.com:

 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):

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

 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] Resin-4.0.5 Watchdog on Shutdown

2010-03-30 Thread 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] Hibernate transactions

2010-03-30 Thread 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 starga...@blueyonder.co.uk

 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

Re: [Resin-interest] Hibernate transactions

2010-03-30 Thread 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 starga...@blueyonder.co.uk 
 mailto:starga...@blueyonder.co.uk

 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 mailto: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

2010-03-30 Thread 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] Hibernate transactions

2010-03-30 Thread 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,

snip

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

2010-03-30 Thread 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
ThreadLocalEntityManger to null.

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

-Wesley

2010/3/31 Scott Ferguson f...@caucho.com

 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

2010-03-30 Thread 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] Resin-4.0.5 Watchdog on Shutdown

2010-03-30 Thread 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] Resin-4.0.5 Watchdog on Shutdown

2010-03-30 Thread 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

2010-03-30 Thread 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] PermGen problems installing Confluence

2010-03-30 Thread 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 rm...@latencyzero.com:
 
 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):
 
 jvm-arg-server/jvm-arg
 jvm-arg-XX:PermSize=128m/jvm-arg
 jvm-arg-XX:MaxPermSize=192m/jvm-arg
 jvm-arg-Xmx512m/jvm-arg
 jvm-arg-Xms512m/jvm-arg
 jvm-arg-Xss1m/jvm-arg
 jvm-arg-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl/jvm-arg
 jvm-arg-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl/jvm-arg
 
 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

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

2010-03-30 Thread 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

2010-03-30 Thread 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 rm...@latencyzero.com:

   
 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):

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

 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] PermGen problems installing Confluence

2010-03-30 Thread 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 rm...@latencyzero.com:
 
 
 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):
 
 jvm-arg-server/jvm-arg
 jvm-arg-XX:PermSize=128m/jvm-arg
 jvm-arg-XX:MaxPermSize=192m/jvm-arg
 jvm-arg-Xmx512m/jvm-arg
 jvm-arg-Xms512m/jvm-arg
 jvm-arg-Xss1m/jvm-arg
 jvm-arg-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl/jvm-arg
 jvm-arg-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl/jvm-arg
 
 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] Resin-4.0.5 Watchdog on Shutdown

2010-03-30 Thread 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