Re: [Resin-interest] Resin Pro 3.1.9 - JDK Deadlock on Startup
On Jun 18, 2009, at 7:46 PM, Rob Lockstone wrote: The deadlock check is part of the functionality. There's an that defaults to 15 minutes, because the ping needs to wait for the server to start before pinging. Interesting, so even though I haven't defined a jsp page for the ping to check, it still operates? What is it checking? It's a JDK capability. The JDK has an MBean "java.lang:type=Threading" with the operation "findMonitorDeadlockedThreads". So it doesn't need anything HTTP- related. -- Scott In any event, good to know. I'm going to crank this value down since our servers generally get started within about a minute or so. I'll pad it out a little to account for recompiling jsp's and such. Rob I've added a bug report to at least clean up that log report. -- Scott Rob Here's an example of the arguments we pass to Java. Most of our servers are configured similarly with variations in the heap sizes. -server -verbose:gc -Xmn500m -Xms5000m -Xmx5000m -Xss128k -Xrs -Xloggc:log/gc.log -Xdebug -XX:+UseConcMarkSweepGC -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Dhttp.maxConnections=400 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9337 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=falsejvm-arg> -agentlib:resin And here's the portion of the log file from when a deadlock occurs. RESIN [02:58:38.369] {resin-destroy} Server[id=,cluster=app-tier] stopping [This is when the restart request is sent. --Rob] RESIN [02:58:38.416] {http--80-2843$1916052035} WebApp[] active RESIN [02:59:06.136] {main} Proxy Cache disk-size=1024M memory- size=64M [Resin starts to restart here. --Rob] RESIN [02:59:06.168] {main} PingThread[] starting, checking [] RESIN [02:59:06.340] {main} RESIN [02:59:06.340] {main} Windows 2003 5.2 amd64 RESIN [02:59:06.340] {main} Java(TM) SE Runtime Environment 1.6.0_13-b03, Cp1252, en RESIN [02:59:06.340] {main} Java HotSpot(TM) 64-Bit Server VM 11.3- b02, 64, mixed mode, Sun Microsystems Inc. RESIN [02:59:06.340] {main} user.name: SYSTEM RESIN [02:59:06.340] {main} resin.home = d:\resin RESIN [02:59:06.340] {main} resin.root = d:\resin RESIN [02:59:06.340] {main} resin.conf = /d:/resin/conf/resin.conf RESIN [02:59:06.340] {main} RESIN [03:14:06.169] {resin-7} JDK detected deadlock. Restarting Resin. [15 minutes later is when Resin has detected the deadlock and restarts. --Rob] RESIN [03:14:06.169] {resin-7} javax .management .openmbean .CompositeDataSupport (compositeType = javax .management .openmbean .CompositeType (name = java .lang .management .ThreadInfo ,items = ((itemName = blockedCount ,itemType =javax.management.openmbean.SimpleType(name=java.lang.Long)), (itemName = blockedTime ,itemType =javax.management.openmbean.SimpleType(name=java.lang.Long)), (itemName = inNative ,itemType =javax.management.openmbean.SimpleType(name=java.lang.Boolean)), (itemName = lockInfo ,itemType = javax .management .openmbean .CompositeType (name = java .lang .management .LockInfo ,items = ((itemName = className ,itemType =javax.management.openmbean.SimpleType(name=java.lang.String)), (itemName = identityHashCode ,itemType =javax.management.openmbean.SimpleType(name=java.lang.Integer), (itemName = lockName ,itemType =javax.management.openmbean.SimpleType(name=java.lang.String)), (itemName = lockOwnerId ,itemType =javax.management.openmbean.SimpleType(name=java.lang.Long)), (itemName = lockOwnerName ,itemType =javax.management.openmbean.SimpleType(name=java.lang.String)), (itemName = lockedMonitors ,itemType = javax .management .openmbean .ArrayType (name = [Ljavax .management .openmbean .CompositeData ;,dimension = 1 ,elementType = javax .management .openmbean .CompositeType (name = java .lang .management .MonitorInfo ,items = ((itemName = className ,itemType =javax.management.openmbean.SimpleType(name=java.lang.String)), (itemName = identityHashCode ,itemType =javax.management.openmbean.SimpleType(name=java.lang.Integer)), (itemName = lockedStackDepth ,itemType =javax.management.openmbean.SimpleType(name=java.lang.Integer)), (itemName = lockedStackFrame ,itemType = javax .management .openmbean .CompositeType (name = java .lang .StackTraceElement ,items = ((itemName = className ,itemType =javax.management.openmbean.SimpleType(name=java.lang.String)), (itemName = fileName ,itemType =javax.management.openmbean.SimpleType(name=java.lang.String)), (itemName = lineNumber ,itemType =javax.management.openmbean.SimpleType(name=java.lang.Integer)), (itemName = methodName ,itemType =javax.management.openmbean.SimpleType(name=java.lang.String)), (itemName = nativeMethod ,itemType = javax .management .openmbean .SimpleType(name
Re: [Resin-interest] Resin Pro 3.1.9 - JDK Deadlock on Startup
On Jun 18, 2009, at 19:31, Scott Ferguson wrote: On Jun 18, 2009, at 5:22 PM, Rob Lockstone wrote: I've never seen this happen with Resin. But ever since upgrading to Resin Pro 3.1.9 (from Pro 3.0.21), it's happening several times per week with different servers during restarts. Environment: Windows 2003 64-bit Server (SP2), Resin Pro 3.1.9 (100 Server License), JDK 1.6.0_13 (64-bit) I looked in the 1.6.0_14 release notes and didn't see anything specific to deadlock situations that were fixed in the .14 release. I don't know if this is a problem with our code, or Resin, or the JDK, or some combination thereof. It might be a classloading-related deadlock. The log is horrible (it's straight JMX output), but I think it has some classloader classes that might be a problem. Other than the obvious, "Why is this happening and how can I fix it?" question, I'm also curious about the 15 minutes that it always takes resin to notice the deadlock and restart. Is this 15 minutes configurable? If so, where can I adjust it and what are the implications of making it < 15 minutes? The deadlock check is part of the functionality. There's an that defaults to 15 minutes, because the ping needs to wait for the server to start before pinging. Interesting, so even though I haven't defined a jsp page for the ping to check, it still operates? What is it checking? In any event, good to know. I'm going to crank this value down since our servers generally get started within about a minute or so. I'll pad it out a little to account for recompiling jsp's and such. Rob I've added a bug report to at least clean up that log report. -- Scott Rob Here's an example of the arguments we pass to Java. Most of our servers are configured similarly with variations in the heap sizes. -server -verbose:gc -Xmn500m -Xms5000m -Xmx5000m -Xss128k -Xrs -Xloggc:log/gc.log -Xdebug -XX:+UseConcMarkSweepGC -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Dhttp.maxConnections=400 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9337 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=falsejvm-arg> -agentlib:resin And here's the portion of the log file from when a deadlock occurs. RESIN [02:58:38.369] {resin-destroy} Server[id=,cluster=app-tier] stopping [This is when the restart request is sent. --Rob] RESIN [02:58:38.416] {http--80-2843$1916052035} WebApp[] active RESIN [02:59:06.136] {main} Proxy Cache disk-size=1024M memory- size=64M [Resin starts to restart here. --Rob] RESIN [02:59:06.168] {main} PingThread[] starting, checking [] RESIN [02:59:06.340] {main} RESIN [02:59:06.340] {main} Windows 2003 5.2 amd64 RESIN [02:59:06.340] {main} Java(TM) SE Runtime Environment 1.6.0_13-b03, Cp1252, en RESIN [02:59:06.340] {main} Java HotSpot(TM) 64-Bit Server VM 11.3- b02, 64, mixed mode, Sun Microsystems Inc. RESIN [02:59:06.340] {main} user.name: SYSTEM RESIN [02:59:06.340] {main} resin.home = d:\resin RESIN [02:59:06.340] {main} resin.root = d:\resin RESIN [02:59:06.340] {main} resin.conf = /d:/resin/conf/resin.conf RESIN [02:59:06.340] {main} RESIN [03:14:06.169] {resin-7} JDK detected deadlock. Restarting Resin. [15 minutes later is when Resin has detected the deadlock and restarts. --Rob] RESIN [03:14:06.169] {resin-7} javax .management .openmbean .CompositeDataSupport (compositeType = javax .management .openmbean .CompositeType (name = java .lang .management .ThreadInfo ,items = ((itemName = blockedCount ,itemType =javax.management.openmbean.SimpleType(name=java.lang.Long)), (itemName = blockedTime ,itemType =javax.management.openmbean.SimpleType(name=java.lang.Long)), (itemName = inNative ,itemType =javax.management.openmbean.SimpleType(name=java.lang.Boolean)), (itemName = lockInfo ,itemType = javax .management .openmbean .CompositeType (name = java .lang .management .LockInfo ,items = ((itemName = className ,itemType =javax.management.openmbean.SimpleType(name=java.lang.String)), (itemName = identityHashCode ,itemType =javax.management.openmbean.SimpleType(name=java.lang.Integer), (itemName = lockName ,itemType =javax.management.openmbean.SimpleType(name=java.lang.String)), (itemName = lockOwnerId ,itemType =javax.management.openmbean.SimpleType(name=java.lang.Long)), (itemName = lockOwnerName ,itemType =javax.management.openmbean.SimpleType(name=java.lang.String)), (itemName = lockedMonitors ,itemType = javax .management .openmbean .ArrayType (name = [Ljavax .management .openmbean .CompositeData ;,dimension = 1 ,elementType = javax .management .openmbean .CompositeType (name = java .lang .management .MonitorInfo ,items = ((itemName = className ,itemType =javax.management.openmbean.SimpleType(name=java
Re: [Resin-interest] Resin Pro 3.1.9 - JDK Deadlock on Startup
On Jun 18, 2009, at 5:22 PM, Rob Lockstone wrote: I've never seen this happen with Resin. But ever since upgrading to Resin Pro 3.1.9 (from Pro 3.0.21), it's happening several times per week with different servers during restarts. Environment: Windows 2003 64-bit Server (SP2), Resin Pro 3.1.9 (100 Server License), JDK 1.6.0_13 (64-bit) I looked in the 1.6.0_14 release notes and didn't see anything specific to deadlock situations that were fixed in the .14 release. I don't know if this is a problem with our code, or Resin, or the JDK, or some combination thereof. It might be a classloading-related deadlock. The log is horrible (it's straight JMX output), but I think it has some classloader classes that might be a problem. Other than the obvious, "Why is this happening and how can I fix it?" question, I'm also curious about the 15 minutes that it always takes resin to notice the deadlock and restart. Is this 15 minutes configurable? If so, where can I adjust it and what are the implications of making it < 15 minutes? The deadlock check is part of the functionality. There's an that defaults to 15 minutes, because the ping needs to wait for the server to start before pinging. I've added a bug report to at least clean up that log report. -- Scott Rob Here's an example of the arguments we pass to Java. Most of our servers are configured similarly with variations in the heap sizes. -server -verbose:gc -Xmn500m -Xms5000m -Xmx5000m -Xss128k -Xrs -Xloggc:log/gc.log -Xdebug -XX:+UseConcMarkSweepGC -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Dhttp.maxConnections=400 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9337 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=falsejvm-arg> -agentlib:resin And here's the portion of the log file from when a deadlock occurs. RESIN [02:58:38.369] {resin-destroy} Server[id=,cluster=app-tier] stopping [This is when the restart request is sent. --Rob] RESIN [02:58:38.416] {http--80-2843$1916052035} WebApp[] active RESIN [02:59:06.136] {main} Proxy Cache disk-size=1024M memory- size=64M [Resin starts to restart here. --Rob] RESIN [02:59:06.168] {main} PingThread[] starting, checking [] RESIN [02:59:06.340] {main} RESIN [02:59:06.340] {main} Windows 2003 5.2 amd64 RESIN [02:59:06.340] {main} Java(TM) SE Runtime Environment 1.6.0_13- b03, Cp1252, en RESIN [02:59:06.340] {main} Java HotSpot(TM) 64-Bit Server VM 11.3- b02, 64, mixed mode, Sun Microsystems Inc. RESIN [02:59:06.340] {main} user.name: SYSTEM RESIN [02:59:06.340] {main} resin.home = d:\resin RESIN [02:59:06.340] {main} resin.root = d:\resin RESIN [02:59:06.340] {main} resin.conf = /d:/resin/conf/resin.conf RESIN [02:59:06.340] {main} RESIN [03:14:06.169] {resin-7} JDK detected deadlock. Restarting Resin. [15 minutes later is when Resin has detected the deadlock and restarts. --Rob] RESIN [03:14:06.169] {resin-7} javax .management .openmbean .CompositeDataSupport (compositeType = javax .management .openmbean .CompositeType (name = java .lang .management .ThreadInfo ,items = ((itemName = blockedCount ,itemType =javax.management.openmbean.SimpleType(name=java.lang.Long)), (itemName = blockedTime ,itemType =javax.management.openmbean.SimpleType(name=java.lang.Long)), (itemName = inNative ,itemType =javax.management.openmbean.SimpleType(name=java.lang.Boolean)), (itemName = lockInfo ,itemType = javax .management .openmbean .CompositeType (name = java .lang .management .LockInfo ,items = ((itemName = className ,itemType =javax.management.openmbean.SimpleType(name=java.lang.String)), (itemName = identityHashCode ,itemType =javax.management.openmbean.SimpleType(name=java.lang.Integer), (itemName = lockName ,itemType =javax.management.openmbean.SimpleType(name=java.lang.String)), (itemName = lockOwnerId ,itemType =javax.management.openmbean.SimpleType(name=java.lang.Long)), (itemName = lockOwnerName ,itemType =javax.management.openmbean.SimpleType(name=java.lang.String)), (itemName = lockedMonitors ,itemType = javax .management .openmbean .ArrayType (name = [Ljavax .management .openmbean .CompositeData ;,dimension = 1 ,elementType = javax .management .openmbean .CompositeType (name = java .lang .management .MonitorInfo ,items = ((itemName = className ,itemType =javax.management.openmbean.SimpleType(name=java.lang.String)), (itemName = identityHashCode ,itemType =javax.management.openmbean.SimpleType(name=java.lang.Integer)), (itemName = lockedStackDepth ,itemType =javax.management.openmbean.SimpleType(name=java.lang.Integer)), (itemName = lockedStackFrame ,itemType = javax .management .openmbean .CompositeType (name = java .lang .StackTraceElement ,items = ((item
[Resin-interest] Resin Pro 3.1.9 - JDK Deadlock on Startup
I've never seen this happen with Resin. But ever since upgrading to Resin Pro 3.1.9 (from Pro 3.0.21), it's happening several times per week with different servers during restarts. Environment: Windows 2003 64-bit Server (SP2), Resin Pro 3.1.9 (100 Server License), JDK 1.6.0_13 (64-bit) I looked in the 1.6.0_14 release notes and didn't see anything specific to deadlock situations that were fixed in the .14 release. I don't know if this is a problem with our code, or Resin, or the JDK, or some combination thereof. Other than the obvious, "Why is this happening and how can I fix it?" question, I'm also curious about the 15 minutes that it always takes resin to notice the deadlock and restart. Is this 15 minutes configurable? If so, where can I adjust it and what are the implications of making it < 15 minutes? Rob Here's an example of the arguments we pass to Java. Most of our servers are configured similarly with variations in the heap sizes. -server -verbose:gc -Xmn500m -Xms5000m -Xmx5000m -Xss128k -Xrs -Xloggc:log/gc.log -Xdebug -XX:+UseConcMarkSweepGC -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Dhttp.maxConnections=400 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9337 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=falsearg> -agentlib:resin And here's the portion of the log file from when a deadlock occurs. RESIN [02:58:38.369] {resin-destroy} Server[id=,cluster=app-tier] stopping [This is when the restart request is sent. --Rob] RESIN [02:58:38.416] {http--80-2843$1916052035} WebApp[] active RESIN [02:59:06.136] {main} Proxy Cache disk-size=1024M memory- size=64M [Resin starts to restart here. --Rob] RESIN [02:59:06.168] {main} PingThread[] starting, checking [] RESIN [02:59:06.340] {main} RESIN [02:59:06.340] {main} Windows 2003 5.2 amd64 RESIN [02:59:06.340] {main} Java(TM) SE Runtime Environment 1.6.0_13- b03, Cp1252, en RESIN [02:59:06.340] {main} Java HotSpot(TM) 64-Bit Server VM 11.3- b02, 64, mixed mode, Sun Microsystems Inc. RESIN [02:59:06.340] {main} user.name: SYSTEM RESIN [02:59:06.340] {main} resin.home = d:\resin RESIN [02:59:06.340] {main} resin.root = d:\resin RESIN [02:59:06.340] {main} resin.conf = /d:/resin/conf/resin.conf RESIN [02:59:06.340] {main} RESIN [03:14:06.169] {resin-7} JDK detected deadlock. Restarting Resin. [15 minutes later is when Resin has detected the deadlock and restarts. --Rob] RESIN [03:14:06.169] {resin-7} javax .management .openmbean .CompositeDataSupport (compositeType = javax .management .openmbean .CompositeType (name = java .lang .management .ThreadInfo ,items = ((itemName = blockedCount ,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)), (itemName = blockedTime ,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)), (itemName = inNative ,itemType =javax.management.openmbean.SimpleType(name=java.lang.Boolean)), (itemName = lockInfo ,itemType = javax .management .openmbean .CompositeType (name = java .lang .management .LockInfo ,items = ((itemName = className ,itemType =javax.management.openmbean.SimpleType(name=java.lang.String)), (itemName = identityHashCode ,itemType =javax.management.openmbean.SimpleType(name=java.lang.Integer), (itemName = lockName ,itemType =javax.management.openmbean.SimpleType(name=java.lang.String)), (itemName = lockOwnerId ,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)), (itemName = lockOwnerName ,itemType =javax.management.openmbean.SimpleType(name=java.lang.String)), (itemName = lockedMonitors ,itemType = javax .management .openmbean .ArrayType (name = [Ljavax .management .openmbean .CompositeData ;,dimension = 1 ,elementType = javax .management .openmbean .CompositeType (name = java .lang .management .MonitorInfo ,items = ((itemName = className ,itemType =javax.management.openmbean.SimpleType(name=java.lang.String)), (itemName = identityHashCode ,itemType =javax.management.openmbean.SimpleType(name=java.lang.Integer)), (itemName = lockedStackDepth ,itemType =javax.management.openmbean.SimpleType(name=java.lang.Integer)), (itemName = lockedStackFrame ,itemType = javax .management .openmbean .CompositeType (name = java .lang .StackTraceElement ,items = ((itemName = className ,itemType =javax.management.openmbean.SimpleType(name=java.lang.String)), (itemName = fileName ,itemType =javax.management.openmbean.SimpleType(name=java.lang.String)), (itemName = lineNumber ,itemType =javax.management.openmbean.SimpleType(name=java.lang.Integer)), (itemName = methodName ,itemType =javax.management.openmbean.SimpleType(name=java.lang.String)), (itemName = nativeMethod ,itemType = javax .management .openmbean .Si
Re: [Resin-interest] Updating Hessian in Resin 4.0 deployments
On Jun 17, 2009, at 11:42 PM, Mattias Jiderhamn wrote: > Hessian was extracted to a separate hessian.jar in the Resin dist a > while back, which made it possible to upgrade Hessian without > changing Resin version. > For some reason hessian was moved back into resin.jar. Because having only two jars is more convenient for most people, and anyone sophisticated enough to want to change hessian is sophisticated enough to put it in front of resin.jar in the classpath. -- Scott > > > /Mattias > > Scott Ferguson wrote (2009-06-18 00:16): >> >> On Jun 17, 2009, at 2:10 PM, Rick Mann wrote: >> >> >>> On Jun 17, 2009, at 13:58:29, Scott Ferguson wrote: >>> >>> On Jun 17, 2009, at 1:48 PM, Rick Mann wrote: > If I download/build a separate Hessian library and drop it into my > WEB- > INF/lib directory, will it get used instead of the one built-in to > Resin? > No, you need to put the replacement in the CLASSPATH (so it's loaded before the resin.jar). In Java, the parent classloaders have priority (that order is needed because of class cast issues.) So any hessian in WEB-INF/lib would be ignored. >>> Hmm. I've always tried to steer far clear of putting anything on the >>> CLASSPATH when running servlet containers. I don't know if I learned >>> that back when I used Tomcat, or if it was something Resin >>> recommended. >>> >> Well, it's normally not a good idea, but it's how you would override >> hessian. >> >> >>> A better alternative would be for me to get to a place where I build >>> resin and run my build; this would allow me to insert logging to >>> help >>> me figure out problems when I run into them all across resin, let >>> alone just Hessian. But Hessian is my most urgent need right now. >>> >>> Are there instructions for building Resin anywhere? >>> >> You should be able to just download the source and use ant. I think >> we cleared up the dependencies (with the exception of 'ant dist'). >> >> -- Scott >> >> > > -- > > > ___ > 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] lighttpd and nginx
Understood Scott, thank you, Ronan Scott Ferguson escreveu: On Jun 17, 2009, at 6:14 AM, Ronan Lucio wrote: Hi Scott, Scott Ferguson escreveu: If you're looking at nginx for performance, you should benchmark Resin as a load-balancer as well, especially if you're using proxy caching. For 4.0, the performance numbers were fairly close (nginx slightly faster). Do you think Resin-4.0 is reliable for production? Not yet. We did add the FastCGI specifically for nginx. For 3.1, you'd need to use the nginx http proxy. It should be pretty close to the fastcgi efficiency. For all I have understood it seems it wont be release soon due so JEE-1.6 specifications. That's correct. For example, the JSR-299 (Java Injection) spec has changed its internal SPI pretty radically, causing a major refactor on our part. -- Scott Ronan ___ 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] Does dependency-check-intervalaffect jspchanges?
Ok, thanks for that Rob. Regards, Jens Dueholm Christensen Business Process and Improvement, Rambøll Survey IT From: resin-interest-boun...@caucho.com [mailto:resin-interest-boun...@caucho.com] On Behalf Of Rob Lockstone Sent: 18. juni 2009 01:09 To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Does dependency-check-intervalaffect jspchanges? I'd recommend setting the global dependency-check-interval and the jsp one and not worry about the inheritance aspect. That's what we do and it works fine. What you have below should do what you want. The only change I'd make is to use 60s instead of just 60. I'm not sure if resin assumes 'seconds' or not. Rob On Jun 17, 2009, at 01:46, Jens Dueholm Christensen wrote: Scott Ferguson wrote: JSP is handled separately and has its own check interval. The concepts are similar, of course, but the actual needs are different enough that it made more sense to configure them separately. Thanks Scott However, as Rob Lockstone points out regarding the jsp version of the setting, the default value is inherited - but from where? If I were to do something like (Resin 3.0) -1 60 (Resin 3.1/4) -1 60 I would still get the behaviour I want (ie. able to change resin.conf without restart, but still get on-the-fly recompile of jsp changes), or is the setting for jsp inherited from elsewhere (and thus the last dependency-check-interval is unnessecary)? Regards, Jens Dueholm Christensen Business Process and Improvement, Rambøll Survey IT ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] No sessions in Resin 4
Rick Mann wrote (2009-06-18 09:11): > On Jun 17, 2009, at 23:57:55, Mattias Jiderhamn wrote: > > >> Scott Ferguson wrote (2009-06-05 18:11): >> >>> On Jun 3, 2009, at 10:59 PM, Mattias Jiderhamn wrote: >>> >>> Done a bit more debugging and I have arrived at com.caucho.server.distcache.FileCacheManager.put() which does nothing but return null!? Should persistent-store type="file" work at all...? >>> Yikes. All of our testing for sessions was against Resin Pro, which >>> uses the "cluster" version. I've refactored the code, and added open >>> source testing for the basic session behavior. >>> >> I though I'd try this out by building Resin from trunk using Ant but >> I'm >> running into multiple issues when compiling with JDK 1.6.0_11. >> Is there documentation somewhere on building Resin from sources...? >> > > I just downloaded the 4.0 distro sources, and built successfully with > Java 1.6.0_07-b06-146 > That doesn't work here either. Some new errors, some same. > Haven't tried trunk, though. > Well, the session bug should be fixed in trunk so... Hopefully there is a new snapshot out when I get back from summer vacation. -- ___ 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 17, 2009, at 23:57:55, Mattias Jiderhamn wrote: > Scott Ferguson wrote (2009-06-05 18:11): >> >> On Jun 3, 2009, at 10:59 PM, Mattias Jiderhamn wrote: >> >>> Done a bit more debugging and I have arrived at >>> com.caucho.server.distcache.FileCacheManager.put() which does >>> nothing >>> but return null!? >>> Should persistent-store type="file" work at all...? >> >> Yikes. All of our testing for sessions was against Resin Pro, which >> uses the "cluster" version. I've refactored the code, and added open >> source testing for the basic session behavior. > I though I'd try this out by building Resin from trunk using Ant but > I'm > running into multiple issues when compiling with JDK 1.6.0_11. > Is there documentation somewhere on building Resin from sources...? I just downloaded the 4.0 distro sources, and built successfully with Java 1.6.0_07-b06-146 Haven't tried trunk, though. -- Rick ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest