Rick Mann wrote: > Hmm, I can't seem to post longer email to the list. Here's a link to my last > post: > > http://pastie.org/private/2c4lrjuj4oybdtzmj4gbzw > Thanks. There is a size limit for the list.
That trace looks normal, assuming the *.216 and *.217 are your two HTTP ports. I assume that's the connection-refused state? Each one has several threads in the nativeAccept() state. The situation that would be a problem is if there are no threads for the port waiting in accept(). When you're in a connection-refused, can you try both addresses, just to make sure? (It's possible, too, that netstat might show something in that state.) The JNI is used in Resin-OS for ports/sockets because we needed the JNI capability to handle the setuid (and we decided setuid really should be in Resin-OS.) And it may be better to set the <thread-idle-max> for your older OS to something smaller, like 10 or 15, because that OS may not be as good with lots of threads. -- Sctt > > On Mar 18, 2010, at 15:33:08, Rick Mann wrote: > > >> I replied with the thread dump, but don't see it appearing in the list. >> Seems like the list server is flaky. >> >> On Mar 18, 2010, at 14:37:25, Scott Ferguson wrote: >> >> >>> Rick Mann wrote: >>> >>>> Slower is subjective. Unfortunately, I can't currently run the old server >>>> to actually measure times, but it's just slowwwww. I can see individual >>>> requests (images, CSS, etc) taking a long time to be fulfilled, whereas >>>> before, the pages would just come up fully rendered. Time to first render >>>> is longer, too. >>>> >>>> >>> "finer" logging might show the issue, but there's a good chance it's >>> related to the connection issue. >>> >>>> I left the server running late last night, tried to make requests of it >>>> this morning, but I just got "server not responding" errors in the >>>> browser. Mind you, these were not timeouts, but actual connection refusals. >>>> >>>> >>> Thanks. Refusing connections is a more helpful description. >>> >>> If possible, can you get a thread dump in that situation? There are a >>> couple of possible scenarios: >>> >>> 1. After a while, Resin no longer has a thread listening for an >>> accept(). (for example, if it doesn't properly spawn a new thread.) >>> 2. The JVM is truly frozen. >>> >>> It is possible, by the way, that the older Linux is having trouble with >>> the threading. They made huge improvements in the kernel's threading >>> after the version you're using. >>> >>>> logs show nothing with this config: >>>> >>>> >>>> <logger name="com.caucho.servlets" level="warning"/> >>>> <logger name="" level="warning"/> >>>> >>>> >>> Ok, although, the "warning" level would only show pretty serious issues. >>> >>>> So, that's an interesting and scary thought. However, I'm not using Resin >>>> Professional, so I thought I didn't get native sockes. >>>> >>>> >>> Ok. That's one less variable. The main issue is the connection failures. >>> That could cause your slowness as well. For example, if only one thread >>> is listening for connections for some reason, the server would appear to >>> be very slow. >>> >>> -- Scott >>> >>>>>> root 20511 0.0 5.1 226964 26396 pts/2 S 10:54 0:00 >>>>>> /usr/java/bin/java -jar /usr/local/resin/lib/resin.jar -conf >>>>>> /var/resin/resin.xml -log-directory /var/logs/resin -root-directory >>>>>> /var/resin/root -J-verbosegc console >>>>>> >>>>>> root 20517 0.0 6.8 450916 35108 pts/2 S 10:54 0:00 >>>>>> /usr/local/java-versions/jdk1.6.0_07/bin/java -server >>>>>> -Djava.awt.headless=true -Dfile.encoding=utf-8 -Dresin.server=1 >>>>>> -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=/usr/local/resin/ -Xss1m -Xmx256m >>>>>> -verbosegc -verbosegc com.caucho.server.resin.Resin --root-directory >>>>>> /var/resin/root -conf /var/resin/resin.xml -socketwait 34280 >>>>>> -log-directory /var/logs/resin -root-directory /var/resin/root console >>>>>> >>>>>> >>>>>> I can't find where the -Xss1m and -Xmx256m are being set. According to >>>>>> the admin manual, it should default to -Xss2m. >>>>>> >>>>>> >>>>>> >>>>> You can change that in the resin.xml with a <jvm-arg>-Xss1m</jvm-arg>. >>>>> >>>>> >>>> I used to have exactly those values specified in resin.xml, and thought >>>> perhaps that was part of the problem, so I commented them out (to let the >>>> JVM and resin pick defaults). I was still seeing those in the command, >>>> though, and didn't know where they were coming from. That was something I >>>> had not been specifying in my 3.0.23 installation, and so I thought they >>>> were causing more problems than they were solving. >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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
