Re: [Resin-interest] resin.conf = null when upgrading to Resin 4
Scott Ferguson wrote (2009-06-02 07:23): On Jun 1, 2009, at 9:48 PM, Mattias Jiderhamn wrote: Sitting here trying to upgrade the dev environment to Resin 4.0 with minimal changes to configuration and startup scripts. On Windows I'm up and running after a strange problem with a simple solution (deleting a default directory so that Resin would accept the explicit document-directory). On Linux however I'm still struggling. I think the heart of the problem is that Resin for some reason does not accept me trying to point out our old resin.conf file. [2009/06/02 06:33:08.066] resin.home = /u/resin/resin/ [2009/06/02 06:33:08.066] resin.root = /u/dna/exder.server.root [2009/06/02 06:33:08.066] resin.conf = null The arguments when starting Resin are -conf /u/dna/exder.server.root/conf/resin.conf -server-root /u/dna/exder.server.root and I also tried -conf /u/dna/exder.server.root/conf/resin.conf -root-directory /u/dna/exder.server.root Would anyone care to spare my time by telling me what I'm doing wrong here...? That's odd. What does the -verbose show as the command line passed to the Resin instance? Also, do you see the same with start as with non-start Actually, without start seems to work fine. -verbose command is then: /usr/java/jdk1.5.0_11/bin/java \ -Djava.util.logging.manager=com.caucho.log.LogManagerImpl \ -Djava.system.class.loader=com.caucho.loader.SystemClassLoader \ -Djavax.management.builder.initial=com.caucho.jmx.MBeanServerBuilderImpl \ -Djava.awt.headless=true \ -Dresin.home=/u/resin/resin/ \ -Xss1m \ -Xmn256M \ -Xms512M \ -Xmx1024M \ -XX:MaxPermSize=128M \ -d64 \ -server \ com.caucho.server.resin.Resin \ --root-directory \ /u/dna/exder.server.root \ -conf \ /u/dna/exder.server.root/conf/resin.conf \ -socketwait \ 51562 \ -verbose \ -server-root \ /u/dna/exder.server.root With start the command is /usr/java/jdk1.5.0_11/bin/java \ -Djava.util.logging.manager=com.caucho.log.LogManagerImpl \ -Djava.system.class.loader=com.caucho.loader.SystemClassLoader \ -Djavax.management.builder.initial=com.caucho.jmx.MBeanServerBuilderImpl \ -Djava.awt.headless=true \ -Dresin.home=/u/resin/resin/ \ -Xss1m \ -Xmn256M \ -Xms512M \ -Xmx1024M \ -XX:MaxPermSize=128M \ -Djava.util.logging.manager=com.caucho.log.LogManagerImpl \ -Djavax.management.builder.initial=com.caucho.jmx.MBeanServerBuilderImpl \ -Djava.awt.headless=true \ -Dresin.home=/u/resin/resin/ \ -Dresin.root=/u/dna/exder.server.root \ -Djava.util.logging.manager=com.caucho.log.LogManagerImpl \ -Djavax.management.builder.initial=com.caucho.jmx.MBeanServerBuilderImpl \ -Djava.awt.headless=true \ -Dresin.home=/u/resin/resin/ \ -Dresin.root=/u/dna/exder.server.root \ -d64 \ -server \ com.caucho.server.resin.Resin \ --root-directory \ /u/dna/exder.server.root \ -conf \ /u/dna/exder.server.root/conf/resin.conf \ -socketwait \ 51666 \ -verbose \ -server-root \ /u/dna/exder.server.root \ start \ --log-directory \ /u/dna/exder.server.root/log /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] No sessions in Resin 4
I wrote on resin.conf = null when upgrading to Resin 4 (2009-06-02 06:48): Sitting here trying to upgrade the dev environment to Resin 4.0 with minimal changes to configuration and startup scripts. On Windows I'm up and running ... I apparently jumped the gun here. I am not up and running on Windows either. While picking up my resin.conf, Resin does not handle sessions but resets them on every request. Example fine log, first request: [20:56:44.359] SessionImpl[aaaQKDKMBgGTm9hnkvIgs,] new [20:56:44.359] SessionImpl[aaaQKDKMBgGTm9hnkvIgs,] create session ... Subsequent request: [20:57:27.250] Http[11] Cookie: JSESSIONID=aaaQKDKMBgGTm9hnkvIgs [20:57:27.750] SessionImpl[aaaQKDKMBgGTm9hnkvIgs,] reset [20:57:27.750] SessionImpl[aaaQKDKMBgGTm9hnkvIgs,] reset [20:57:27.750] SessionImpl[aaaQKDKMBgGTm9hnkvIgs,] new [20:57:27.750] SessionImpl[aaaQKDKMBgGTm9hnkvIgs,] create session Tried to find a configuration fault by debugging, but I end up really confused. When com.caucho.server.session.SessionImpl.save() is entered, I have a couple of values in the session, but when stepping into the isValid() the _values Map is suddenly empty??? Here is my session config: persistent-store type=file init pathc:\temp\resin-sessions/path always-savetrue/always-save /init /persistent-store + session-config use-persistent-store / session-max4096/session-max session-timeout30/session-timeout /session-config -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] No sessions in Resin 4
On Jun 2, 2009, at 12:29 PM, Mattias Jiderhamn wrote: I wrote on resin.conf = null when upgrading to Resin 4 (2009-06-02 06:48): Sitting here trying to upgrade the dev environment to Resin 4.0 with minimal changes to configuration and startup scripts. On Windows I'm up and running ... I apparently jumped the gun here. I am not up and running on Windows either. While picking up my resin.conf, Resin does not handle sessions but resets them on every request. Example fine log, first request: [20:56:44.359] SessionImpl[aaaQKDKMBgGTm9hnkvIgs,] new [20:56:44.359] SessionImpl[aaaQKDKMBgGTm9hnkvIgs,] create session ... Subsequent request: [20:57:27.250] Http[11] Cookie: JSESSIONID=aaaQKDKMBgGTm9hnkvIgs [20:57:27.750] SessionImpl[aaaQKDKMBgGTm9hnkvIgs,] reset [20:57:27.750] SessionImpl[aaaQKDKMBgGTm9hnkvIgs,] reset [20:57:27.750] SessionImpl[aaaQKDKMBgGTm9hnkvIgs,] new [20:57:27.750] SessionImpl[aaaQKDKMBgGTm9hnkvIgs,] create session The reset is normally a message that something went wrong in loading the session. I'll need to see if we can either improve the information or just fix the issue. The bug is at http://bugs.caucho.com/view.php?id=3545 Tried to find a configuration fault by debugging, but I end up really confused. When com.caucho.server.session.SessionImpl.save() is entered, I have a couple of values in the session, but when stepping into the isValid() the _values Map is suddenly empty??? Here is my session config: persistent-store type=file init pathc:\temp\resin-sessions/path always-savetrue/always-save /init /persistent-store FYI, this is ignored, currently, because the persistent store is always available (it lives in resin-data). You do still need use- persistent-store to enable the session to use it. -- Scott + session-config use-persistent-store / session-max4096/session-max session-timeout30/session-timeout /session-config -- /Mattias ___ 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] Can user threads call ejb methods?
Is there a problem calling ejb methods from user-started threads inside the resin container? Yes, I know the ejb spec says that applications shouldn't start threads, but part of the spec is lame. The SubEtha mailing list server relies on an SMTP processing library which starts its own threads and then makes callbacks into our handlers as the email arrives. These handlers call into an ejb which processes the message in a transaction. We're seeing some really bizarre behavior where sometimes there is a transaction and sometimes there isn't. Could this be because the call is being done on a non-resin-started thread? If so, is there any workaround? Thanks, Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Can user threads call ejb methods?
Nevermind, the problem was something else. Calling a find() method on an EntityManager outside of a transaction scope, then calling an EJB which has a transaction scope causes all manner of havoc when the EJB tries to write to the database. Jeff On Tue, Jun 2, 2009 at 5:33 PM, Jeff Schnitzer j...@infohazard.org wrote: Is there a problem calling ejb methods from user-started threads inside the resin container? Yes, I know the ejb spec says that applications shouldn't start threads, but part of the spec is lame. The SubEtha mailing list server relies on an SMTP processing library which starts its own threads and then makes callbacks into our handlers as the email arrives. These handlers call into an ejb which processes the message in a transaction. We're seeing some really bizarre behavior where sometimes there is a transaction and sometimes there isn't. Could this be because the call is being done on a non-resin-started thread? If so, is there any workaround? Thanks, Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
