Re: [Resin-interest] feature list comparison

[Bill Au]

http://caucho.com/resin-3.0/features/overview.xtp

Bill

On Fri, Dec 5, 2008 at 3:43 PM, Arthur Copeland <[EMAIL PROTECTED]
> wrote:

> Where can i find a detailed feature list that compares open source
> resin with pro version so that my organization can have a all the info
> for our decision on which version to use.
>
>
> iovation
> 111 SW Fifth Avenue
> Suite 3200
> Portland, OR 97204
> http://www.iovation.com/
>
> The information contained in this email message may be privileged,
> confidential and protected from disclosure. If you are not the intended
> recipient, any dissemination, distribution or copying is strictly
> prohibited. If you think that you have received this email message in error,
> please notify the sender by reply email and delete the message and any
> attachments.
>
>
> ___
> 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] Memory leak - in Resin?

[Bill Au]

I trick that I use to trouble shoot perm gen memory leak involves using
jconsole and , jmap, and jhat.  I would attach to resin with jconsole, then
reload the webapp a few times to trigger the perm gen leak.  That I will
stop the webapp completely, and then go to the memory tab to trigger some
full GC.  What I found is that I would need to trigger a few full GC back to
back in order for the garbage collector to actually clean up the perm gen.
At this point I take a heap dump with jmap and look at the heap dump with
jhat.  The webapp had been stopped and perm gen had been clean so if there
is no leak, classes loaded by the webapp classlloader should not be in the
heap dump anymore.  So if you still see them it mean there is a perm gen
leak.  In jhat the detail page for any leaked classes has a link to the
classloader which loaded that c lass.  Follow that link and you will see a
link for the reference chains from rootset (exclude weak ref) for the leaked
classloader.  That page will show you where the leak is.

Bill

On Fri, Jan 9, 2009 at 3:22 AM, Mattias Jiderhamn  wrote:

> Scott Ferguson wrote (2008-11-26 16:53):
> >
> > On Nov 24, 2008, at 11:08 PM, Mattias Jiderhamn wrote:
> >
> >> I'm still battling this PermGen leak and frankly I'm really starting
> >> to doubt that I know what I'm doing anymore. I'd be very happy if
> >> anyone would care to explain that to me...
> >>
> >> Since my last post Scott and I have discussed potential class loader
> >> leaks and some of them have been fixed in the 3.1.8 release. It seems
> >> there is (at least) one leak that didn't get fixed in 3.1.8. I have
> >> made a quick and dirty patch to avoid that leak. If anyone would care
> >> to try, the patch (which includes a few other things probably fixed
> >> in 3.1.8 already) can be found here:
> >> http://jiderhamn.se/resin-leak.patch
> >>
> >> However, even with that patch, it seems there is still some kind of
> >> PermGen leak that eventually leads to OutOfMemoryError. I have
> >> created a small application with the sole purpose of detecting these
> >> leaks. If anyone would care to try, it can be found here (sources
> >> included): http://jiderhamn.se/leak.war
> >> You will need to add some JARs to the WEB-INF/lib directory;
> >> preferrably a couple of large ones like spring.jar and hibernate.jar
> >> (don't use Resin JARs though).
> >> Then just drop the WAR in a clean installation of Resin 3.1.8
> >> (preferrably patched with the patch above).
> >> Hit http://...:nn/leak (once is enough)
> >> Force a redeploy by either deleting the webapps/leak dir or touch:ing
> >> leak.war
> >> Hit http://...:nn/leak again
> >> Repeat the last two steps for as long as you'd like
> >>
> >> What you should see - or at least what I see on one Linux machine and
> >> one Windows machine - is the (ClassLoadingMXBean) loadedClassCount
> >> and the (MemoryPoolMXBean) Used Perm Gen steadily increasing (while
> >> the unloadedClassCount remains pretty stable) for every redeploy,
> >> which indicates a classloader leak. But I just can't find that leak.
> >
> > Thanks.
> >
> > Right now, our code base is a bit stuck due to the WebBeans/OSGi
> > upgrade (for Resin 4.0.0, was 3.2.2).  Once that's cleaned up and I
> > can put up a snapshot I can take a look.
>
> Scott Ferguson wrote (2008-12-29 20:41):
> > I've just made an early Resin 4.0 snapshot available.
>
> Does this mean we can assume you will be able to look more closely at
> the memory leaks in 3.1 sometime soon...?
>
>  /Mattias
>
>
>
> >
> > -- Scott
> >>
> >>
> >> Now, here are the things really bugging me:
> >> 1. If I keep redeploying over and over, I will eventually get closer
> >> and closer to the Perm Gen Max (in some instances, I have seen the
> >> following behaivour instead turn up when Used reaches Init if Init is
> >> large enough). Then suddenly the unloadedClassCount is increased, but
> >> not with all the unused classes - only about the amount of one
> >> redeployment. Redeploy again, and it will increase another step.
> >> Meanwhile, the loadedClassCount remains pretty stable, since we are
> >> loading as many new classes as are unloaded. It's as if there was a
> >> FIFO queue/LRU cache of classloaders, so that the oldest one is
> >> garbage collected once there is not enough space for a new one.
> >> However, after a while there is (assumably) not enough space to
> >> create the new classloader before the old one is garbage collected,
> >> and I get OutOfMemoryError somewhere in the middle. Sometimes I am
> >> actually able to recover from this error by waiting for the GC to do
> >> it's job and then just try again.
> >>
> >> 2. Now I attached YourKit, looking for dangling classloaders as of
> >> the inital post. I found none. In fact, the Classes without Instances
> >> inspection only shows the classes in the added JARs from the last
> >> redeployment, so when tracing back to GC root, it goes via the
> >> current EnvironmentClassLoader which is correct. There are 

Re: [Resin-interest] Perf Issues

[Bill Au]

I would also enable garbage collection logging (-Xloggc:) to see
if your application is running slow because the JVM is spending a lot of
time doing garbage collection.

If you are running SUN Java 6, you can use the jmap command to do a heap
dump also.  Jmap is available in Java 5 but it doesn't always produce a
consistent heap dump.

Bill

On Fri, Mar 20, 2009 at 1:12 PM, Ronan Lucio  wrote:

> Scott,
>
> Scott Ferguson escreveu:
> > The /resin-admin has a heap dump which will give you a general idea of
> > what's taking the memory (you will need to add a -agentlib:resin to
> > enable it.
> >
> > That heap information is very important because it will very quickly
> > let you focus on the real issue.  Otherwise, it's almost impossible to
> > guess what the underlying problem is.
> >
>
> Thank you for the answer,
> I'll do that.
>
> 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

Re: [Resin-interest] Resin 4.0.0 release

[Bill Au]

I just noticed that the status for JSR313 is now listed as "Withdrawn".
What implication does that have on a stable release of 4.0?

Bill

On Thu, May 7, 2009 at 12:02 PM, Scott Ferguson  wrote:

> We've just released Resin 4.0.0 for download at http://caucho.com/download
> .
>
> Resin 4.0 has a large number of internal changes and enhancements over
> 3.1, and it is the development branch.  If you need a stable version
> of Resin, you should continue to use Resin 3.1.  The expected date for
> a stable version of Resin 4.0 is tied to the JavaEE spec dates for
> JavaEE 6, so it's a moving target.
>
> Major Features in Resin 4.0.0:
>
>   o Resin 10,000
> - 10,000 simultaneous connections
>
>   o Project Jar Repository
>  - uses Maven pom.xml dependencies to build classloaders
>  - replaces complex OSGi bundles with simple .jar management
>
>   o CanDI - Java Contexts and Dependency Injection (JSR-299)
> - resin.xml/web.xml config fully integrated with CanDI
> - Rewrite/Dispatch redesign using CanDI
> - Security redesign using CanDI
> - JMS Queue/Topic redesign using CanDI
>
>   o Protocol enhancements
> - FastCGI port and proxy
> - HTTP proxy
>
>   o Cloud Computing redesign
> - Dynamic servers
> - Distributed deployment with .git repository and BAM/HMTP
> * eclipse, ant, maven and /resin-admin deployment
> - Clustered session refactor with BAM/HMTP for dynamic servers
> - Clustered Cache (JCache)
> - Load Balance refactor for dynamic servers
> - Load Balance green connections
> - Remote JMX refactored to use BAM/HMTP
> - Watchdog refactored to use BAM/HMTP
> - BAM/HMTP rename and refactor
>
>   o Quercus
> - performance and compatibility work
> - Google App Engine support
>
>
> ___
> 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.0 release

[Bill Au]

I just found another JSR, JSR316, for Java EE 6:

http://jcp.org/en/jsr/detail?id=316

I guess I was looking at the wrong JSR before.

Bill

On Thu, May 7, 2009 at 3:08 PM, Bill Au  wrote:

> I just noticed that the status for JSR313 is now listed as "Withdrawn".
> What implication does that have on a stable release of 4.0?
>
> Bill
>
>
> On Thu, May 7, 2009 at 12:02 PM, Scott Ferguson  wrote:
>
>> We've just released Resin 4.0.0 for download at
>> http://caucho.com/download
>> .
>>
>> Resin 4.0 has a large number of internal changes and enhancements over
>> 3.1, and it is the development branch.  If you need a stable version
>> of Resin, you should continue to use Resin 3.1.  The expected date for
>> a stable version of Resin 4.0 is tied to the JavaEE spec dates for
>> JavaEE 6, so it's a moving target.
>>
>> Major Features in Resin 4.0.0:
>>
>>   o Resin 10,000
>> - 10,000 simultaneous connections
>>
>>   o Project Jar Repository
>>  - uses Maven pom.xml dependencies to build classloaders
>>  - replaces complex OSGi bundles with simple .jar management
>>
>>   o CanDI - Java Contexts and Dependency Injection (JSR-299)
>> - resin.xml/web.xml config fully integrated with CanDI
>> - Rewrite/Dispatch redesign using CanDI
>> - Security redesign using CanDI
>> - JMS Queue/Topic redesign using CanDI
>>
>>   o Protocol enhancements
>> - FastCGI port and proxy
>> - HTTP proxy
>>
>>   o Cloud Computing redesign
>> - Dynamic servers
>> - Distributed deployment with .git repository and BAM/HMTP
>> * eclipse, ant, maven and /resin-admin deployment
>> - Clustered session refactor with BAM/HMTP for dynamic servers
>> - Clustered Cache (JCache)
>> - Load Balance refactor for dynamic servers
>> - Load Balance green connections
>> - Remote JMX refactored to use BAM/HMTP
>> - Watchdog refactored to use BAM/HMTP
>> - BAM/HMTP rename and refactor
>>
>>   o Quercus
>> - performance and compatibility work
>> - Google App Engine support
>>
>>
>> ___
>> 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] Classpath Question

[Bill Au]

The command line arguments for starting Resin 4.0.x only applied to the
watchdog and NOT the actual resin process itself.  JVM command line
arguments are specified in resin.xml.  For example, in the command above,
$JAVA_MX and $JAVA_MS applies to the watchdog only.  I wouldn't increase the
default 32m max heap size of the watchdog since it does need much memory.

Bill

On Fri, Mar 19, 2010 at 5:53 PM, Aaron Freeman wrote:

> It's working now.  For completeness and to help others moving from 3.0.x
> to 3.1.x or 4.0.x you should change your startup script from this style
> (which relies on a wrapper.pl):
>
> $RESIN_HOME/bin/httpd.sh -verbose \
> -J-server \
> -J-Xmx$JAVA_MX \
> -J-Xms$JAVA_MS \
> -J-verbose:gc \
> -J-XX:MaxGCPauseMillis=5000 \
> -J-XX:GCTimeRatio=19 \
> -J-XX:+PrintGCTimeStamps \
> -J-Djava.security.egd=/dev/urandom \
> -J-cp=/opt/server/java/test.jar \
> -server-root $SERVER_ROOT \
> -Dresin.home=/opt/resin-pro-3.1.9 \
> -conf /opt/server/conf/resin.xml \
> $1
>
> To something like this:
>
> $JAVA_HOME/bin/java \
> -server \
> -Xmx$JAVA_MX \
> -Xms$JAVA_MS \
> -Djava.util.logging.manager=com.caucho.log.LogManagerImpl \
> -Djava.security.egd=/dev/urandom \
> -Dresin.home=${RESIN_HOME} \
> -jar ${RESIN_HOME}/lib/resin.jar \
> -conf ${SERVER_ROOT}/conf/resin.xml \
> $*
>
> And by the way that magically fixed my resin:type problem as well.
>
>
>
> ___
> 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-Pro-4.0.5 Admin

[Bill Au]

It is part of resin 4.x.  Make sure you have the following in your
resin.xml:

  

  
  

  

If you want to use a hostname other than localhost to access the UI, then
you will have to set resin_admin_external to true.

I have been looking at it since I am upgrading from 3.0 to 4 too.  It looks
very good.  Be sure to check it out.  It is nice that a lot of monitoring
stuff that we have had to add on top of resin is now part of it.

Bill


On Wed, Mar 24, 2010 at 2:15 PM, Rick Mann  wrote:

>
> On Mar 24, 2010, at 09:07:07, Aaron Freeman wrote:
>
> > Since we are upgrading from pro-3.0.23 to pro-4.0.5, we thought we would
> > take advantage of the resin-admin stuff.  However the docs aren't clear
> > on how that's supposed to happen.  This page says nothing about what to
> > install: http://caucho.com/resin-4.0/admin/resin-admin.xtp
> >
> > And this page seems to elude that I have to install another product? I
> > could have sworn we had this working in 4.0.0 without installing
> > Quercus.  http://caucho.com/resin-4.0/admin/resin-admin-console.xtp
>
> Quercus is part of Resin 4.x. You get it "for free."
>
> --
> Rick
>
>
>
> ___
> 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] Caucho website security heads up

[Bill Au]

Please update the admin PDF found on the download page as part of the
documentation rework.  Thanks.

Bill

On Wed, Apr 14, 2010 at 12:39 PM, Scott Ferguson  wrote:

> Stargazer wrote:
> > http://caucho.com/resin-4.0/admin/security.xtp is mighty secure indeed!
> > Thought you guys would want to know as this is a link off your front
> page.
> >
> Thanks. It looks like our doc system is out-of-sync with the docs
> themselves (we're in the middle reworking the documentation.) I'll need
> to upgrade the Resin version of caucho.com before that can be fixed.
>
> -- 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
>
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] Resin 4.0.x doc/config

[Bill Au]

In addition to admin and resin-doc, I noticed that there is also a config
webapp under doc.  Anyone knows what that is for?

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

Re: [Resin-interest] Resin 4.0.x doc/config

[Bill Au]

It is part of the tar ball:

$ tar tzvf resin-4.0.6.tar.gz |grep doc/config
drwxr-xr-x 0/0   0 2010-04-13 11:57:38 resin-4.0.6/doc/config/
drwxr-xr-x 0/0   0 2010-04-13 11:57:38
resin-4.0.6/doc/config/WEB-INF/
drwxr-xr-x 0/0   0 2010-04-13 11:57:38
resin-4.0.6/doc/config/WEB-INF/inc/
drwxr-xr-x 0/0   0 2010-04-13 11:57:38
resin-4.0.6/doc/resin-doc/WEB-INF/classes/com/caucho/doc/config/
-rw-r--r-- 0/01037 2010-04-13 11:57:38
resin-4.0.6/doc/config/WEB-INF/inc/apache.template
-rw-r--r-- 0/0 315 2010-04-13 11:57:38
resin-4.0.6/doc/config/WEB-INF/inc/common.php
-rw-r--r-- 0/0 444 2010-04-13 11:57:38
resin-4.0.6/doc/config/WEB-INF/inc/loadbalance.template
-rw-r--r-- 0/0 190 2010-04-13 11:57:38
resin-4.0.6/doc/config/WEB-INF/inc/log.php
-rw-r--r-- 0/01966 2010-04-13 11:57:38
resin-4.0.6/doc/config/WEB-INF/inc/management.php
-rw-r--r-- 0/01249 2010-04-13 11:57:38
resin-4.0.6/doc/config/WEB-INF/inc/resin.template
-rw-r--r-- 0/0 260 2010-04-13 11:57:38
resin-4.0.6/doc/config/WEB-INF/inc/server.php
-rw-r--r-- 0/03536 2010-04-13 11:57:38
resin-4.0.6/doc/config/default.css
-rw-r--r-- 0/01774 2010-04-13 11:57:38
resin-4.0.6/doc/config/index.php
-rw-r--r-- 0/06480 2010-04-13 11:57:38
resin-4.0.6/doc/resin-doc/doc/config-isp.xtp
-rw-r--r-- 0/0   17321 2010-04-13 11:57:38
resin-4.0.6/doc/resin-doc/doc/config-overview.xtp
-rw-r--r-- 0/02275 2010-04-13 11:57:38
resin-4.0.6/doc/resin-doc/doc/config-tags.xtp
-rw-r--r-- 0/0   37560 2010-04-13 11:57:38
resin-4.0.6/doc/resin-doc/doc/config-webapp.xtp
$

It is referenced in full.xml but is commented out  there.

Bill


On Fri, Apr 16, 2010 at 5:11 PM, Emil Ong  wrote:

> Hi Bill,
>
> I don't see that app.  What's in it?  Do you see a directory or an MBean
> or something else that refers to it?
>
> Thanks,
> Emil
>
> On Fri, Apr 16, 2010 at 11:26:28AM -0400, Bill Au wrote:
> > In addition to admin and resin-doc, I noticed that there is also a config
> > webapp under doc.  Anyone knows what that is for?
> >
> > Bill
>
> > ___
> > 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] resin 4.0.11

[Bill Au]

I just noticed that the tar balls for resin 4.0.11 is available in Caucho's
download area but the download page still show 4.0.10 as the latest.  Is
that just a case of the download page being outdated?  Are the 4.0.11 tar
balls official releases?

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

Re: [Resin-interest] Resin 4.0.14+ slow to boot

[Bill Au]

Soctt,
 Assuming this fix will be in 4.0.16, how soon will that be released?
We are looking to upgrade to Resin 4.  I would not want to have to do the
upgrade in 2 steps (first to 4.0.15, and then to 4.0.16 with this fix).  How
long is the startup delay anyway?

Bill

On Wed, Mar 2, 2011 at 12:10 PM, Scott Ferguson  wrote:

> On 03/02/2011 02:53 AM, Mattias Jiderhamn wrote:
> > We're looking forward to upgrading from 4.0.10 to 4.0.15, but during
> > testing we notice 4.0.15 takes way longer to boot our application.
> > Results on different machines range from twice the time to 4-5 times as
> > long. It seems that the Spring/Hibernate initialization is taking most
> > of the time (just by debug outputs, no profiling yet)
> >
> > Narrowing it down, it changed between 4.0.13 and 4.0.14.
> >
> > Is anyone else seeing this? Would this be expected for any reason (like
> > XML parser, DTD resolving)???
> >
> > (We have primarily tested this on Windows with a Resin Pro license that
> > should be valid for the update)
>
> I may have just hit this and fixed it (I need to verify the specific
> change - there are two.)
>
> Resin's classloader does some analysis and caching to improve
> resource/class loading performance. This speeds up Spring/Hibernate
> initialization considerably. Some of that caching was causing problems
> with GC, so it was reversed. I'll see how it can be fixed.
>
> -- 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

[Resin-interest] Resin Pro 4.0.16

[Bill Au]

Just saw that 4.0.16 is now available in the download area.  I took a quick
look at Resin Pro 4.0.16.  It looks like the old "doc" directory is now
installed at "resin-doc".  From Makefile:

mkdir -p $(resin_root)/resin-doc; \
cp -r $(CP_U_FLAG) doc/* $(resin_root)/resin-doc; \

But resin.xml is still using "doc" as opposed to "resin-doc":

  
  

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

Re: [Resin-interest] 4.0.21 release

[Bill Au]

How soon can we expect 4.0.22?  I am wondering if I should want for that or
go with 4.0.21 for the time being.  We just got hit by bug 4701 again.  I
want to pick for the fix for that which is in 4.0.21 but I don't want the
solution to be worse than the problem itself.  How wide-reaching is bug
4726?

Bill

On Wed, Aug 24, 2011 at 3:14 PM, Scott Ferguson  wrote:

> On 08/24/2011 11:32 AM, Olaf Krische wrote:
> > Hello,
> >
> > i have a WAR "accounts.war". I move it into webapps of a fresh
> installation of resin 4.0.21, and then i get this on a POST request (GET
> works)
> >
> java.lang.UnsupportedOperationException: com.caucho.vfs.JniStream@2542880d
> >  at
> com.caucho.vfs.StreamImpl.getAvailable(StreamImpl.java:145)
> >  at
> com.caucho.vfs.ReadStream.getAvailable(ReadStream.java:328)
> > ...
> >
>
> Thanks. I've filed this as http://bugs.caucho.com/view.php?id=4726.
>
> We'll be releasing a quick 4.0.22 for this.
>
> The issue, by the way, was introduced related to changes with the async
> end-of-socket detection, and the regression test to reproduce this is a
> bit more complicated than I'd have expected.
>
> -- Scott
>
> > And just to verify, i downloaded as well a fresh resin 4.0.20, moved the
> same WAR into webapps, no problems at all.
> >
> > The full stacktrace is here:
> >
> > - http://www.ecopatz.de/jvm-default20110824.log
> >
> > Any idea?
> >
>
>
>
> ___
> 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] [4.0.25] tremendously increases my server load when starts-up

[Bill Au]

Scott,

What would trigger the JVM bug having to do with the IP addresses?  I want
to make sure that I am not affected before I upgrade.

What version of JVM does that affect?

Bill

On Mon, Feb 6, 2012 at 11:34 AM, Scott Ferguson  wrote:

> **
> Can you try the snapshot
> http://caucho.com/download/resin-pro-4_0-snap.tar.gz?
>
> The IP bug was a red-herring. There is a timing issue with
> threading/clustering.
>
> That snapshot is not suitable for production (several known regression
> failures), but it can be used to verify the startup bug.
>
> -- Scott
>
>
> On 02/03/2012 01:45 AM, smallufo wrote:
>
> Hi
> This is my ip addresses :
>
>  $ ifconfig
> eth0  Link encap:Ethernet  HWaddr 00:50:08:02:FA:8E
>   inet addr:192.168.2.2  Bcast:192.168.2.255  Mask:255.255.255.0
>   inet6 addr: fe80::250:8ff:fe02:fa8e/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:856152 errors:0 dropped:0 overruns:0 frame:0
>TX packets:460283 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:122552727 (116.8 MiB)  TX bytes:284641238 (271.4 MiB)
>   Interrupt:233 Base address:0xc000
>
>  eth1  Link encap:Ethernet  HWaddr 00:60:6E:60:07:4B
>   inet addr:192.168.1.104  Bcast:192.168.1.255  Mask:255.255.255.0
>   inet6 addr: fe80::260:6eff:fe60:74b/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:11431817 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:13056593 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:3686915772 (3.4 GiB)  TX bytes:1152022111 (1.0 GiB)
>
>  loLink encap:Local Loopback
>   inet addr:127.0.0.1  Mask:255.0.0.0
>   inet6 addr: ::1/128 Scope:Host
>   UP LOOPBACK RUNNING  MTU:16436  Metric:1
>   RX packets:201560031 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:201560031 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:0
>   RX bytes:1693844049 (1.5 GiB)  TX bytes:1693844049 (1.5 GiB)
>
>  All are local addresses , no VM installed.
>
>
>  2012/2/3 Scott Ferguson 
>
>>  On 02/02/2012 06:53 PM, smallufo wrote:
>>
>> I cannot operate my server when I start resin 4.0.25
>> The load is so high that the server almost hangs there...
>> Even a "ls" is so sluggish...
>> It happens even in a clean install (no other webapps installed , just
>> default resin.xml settings)
>>
>>
>>  It might be related to a JVM bug having to do with the IP addresses.
>> What do you IP addresses look like? Are there any virtual ones.
>>
>> -- Scott
>>
>>
>>
>>  $ uname -a
>> Linux dev 2.6.18-164.6.1.el5 #1 SMP Tue Nov 3 16:18:27 EST 2009 i686 i686
>> i386 GNU/Linux
>>
>>   /var/log/resin $ head watchdog-manager.log
>> [2012/02/03 00:08:14.368] {main}
>> [2012/02/03 00:08:14.369] {main} Resin-4.0.25 (built Tue, 24 Jan 2012
>> 11:09:58 PST)
>> [2012/02/03 00:08:14.370] {main}
>> [2012/02/03 00:08:14.370] {main} Linux 2.6.18-164.6.1.el5 i386
>> [2012/02/03 00:08:14.370] {main} Java(TM) SE Runtime Environment
>> 1.6.0_22-b04, UTF-8, zh
>> [2012/02/03 00:08:14.371] {main} Java HotSpot(TM) Server VM 17.1-b03, 32,
>> mixed mode, Sun Microsystems Inc.
>>
>>
>>
>>
>> 2012/2/3 Scott Ferguson 
>>
>>>   On 02/02/2012 08:12 AM, smallufo wrote:
>>>
>>> When I execute 'resinctl start'  , I notice my server almost hangs 
>>> And the server load is very high :
>>>
>>>  $ w
>>>  00:07:51 up 46 days,  6:07,  3 users,  load average: 526.31, 298.59,
>>> 121.04
>>> USER TTY  FROM  LOGIN@   IDLE   JCPU   PCPU WHAT
>>> smallufo pts/1destiny  Wed166:09   2.91s  1.92s top
>>> smallufo pts/2destiny  Wed221.00s  2.67s  0.01s w
>>> smallufo pts/3destiny  Wed233:36   7:07   6:56
>>>  /usr/java/jdk/bin/java -jar /usr/local/share/resin-4.0.25/lib/resin.jar
>>> -root-directory /hom
>>>
>>>  The load peaks to 500 or even higher !
>>> After 5 or more minutes , the load goes down...
>>>
>>>
>>>  Can you get a thread dump?
>>>
>>> Or better yet, if you have resin-pro, get a "resinctl pdf-report
>>> --profile".
>>>
>>> -- Scott
>>>
>>>
>>>  It does not happen in 4.0.19 !
>>>
>>>
>>> ___
>>> resin-interest mailing 
>>> listresin-interest@caucho.comhttp://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 
>> listresin-interest@caucho.comhttp://maillist.caucho.com/mailman/listinfo/resin-interest
>>
>>
>>
>> ___
>> resin-interest mailing list
>> resin-interest@caucho.com
>> http://maillist.cau

Re: [Resin-interest] Out of PermGen space

[Bill Au]

Out of PermGen space is almost always caused by a classloader leak which
occurs when a webapp is reloaded.  It could be caused by either your own
code, third-party code, or in some case Java core classes.

You need to take heap dumps before and after webapp reload and use a heap
analyzer to see what is holding onto the leaked classloader(s).

Bill

On Tue, Apr 24, 2012 at 5:41 PM, Chris Pratt wrote:

> Well, yes and no.  As I understand the problem, it really got bad around
> the Java 5 timeframe because of the addition of Enumerations to the
> language.  What Resin does (and all auto-reloading Java containers do) is
> to create a ClassLoader that contains all the code for your application.
>  When it senses a change to your code, it loads that new code into a brand
> new ClassLoader and releases the old one to be garbage collected once it's
> done processing it's active requests.  The problem is that, since
> Enumerations are guaranteed to work with the == operator, even when
> serialized/deserialized between different computers, Java treats them
> special, by keeping them in the Permanent Generation (so their internal
> ID's won't change).  Unfortunately, each time the app is loaded a new set
> of Enumerations takes up more space in the precious PermGen until it
> finally blows its lid.  So, theoretically, you could use less PermGen by
> limiting Enumeration use, but that's really not a realistic response.
>  Before Java became property of Oracle, there was some talk about fixing
> this problem at the JVM level, but I haven't heard anything in quite a
> while.
>   (*Chris*)
>
>
> On Tue, Apr 24, 2012 at 1:54 PM, Rick Mann  wrote:
>
>> When I'm making changes to the code of a webapp, Resin kindly reloads it
>> for me. I can usually get a handful of reloads in before Resin complains
>> about being out of PermGen space.
>>
>> Is there something I'm doing wrong in my app that it leaks like this?
>>
>> --
>> Rick
>>
>>
>> ___
>> 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] Out of PermGen space

[Bill Au]

If it is not a leak (classes are being cleaned up upon webapp reload but a
large number is being created), simply increase max perm size.

Bill

On Wed, Apr 25, 2012 at 11:47 PM, Matt White  wrote:

> On 4/24/2012 5:13 PM, Bill Au wrote:
>
> Wow, something I'm actually qualified to talk about on this list! :)
>
>
> > Out of PermGen space is almost always caused by a classloader leak which
> > occurs when a webapp is reloaded.  It could be caused by either your own
> > code, third-party code, or in some case Java core classes.
>
> I debug PermGen errors quite a bit. Some of our apps have a cache of
> dynamically generated classes (Drools does this) that, if held onto long
> enough, will make the the JVM run out of PermGen. This isn't really a
> mistake, it's just how it works, sadly.
>
>
> > You need to take heap dumps before and after webapp reload and use a
> > heap analyzer to see what is holding onto the leaked classloader(s).
>
> That's how I debug them. Take a series of heap dumps and start comparing
> the differences between them -- YourKit even makes this easy for you
> with a tool that diffs heap dumps.
>
> - Matt
>
> ___
> 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] Old files not removed at redeploy

[Bill Au]

This has been fixed in 4.0.31:

http://bugs.caucho.com/view.php?id=5193

As a temporary work-around, you can remove
expand-preserve-fileset="WEB-INF/work/**" from your resin.xml.  But that
will remove all compiled JSP causing them to be recompiled even if they
have not changed in the new war.

Bill

On Wed, Sep 12, 2012 at 7:30 AM, Mattias Jiderhamn <
mj-li...@expertsystems.se> wrote:

> We're in the process of setting up a new server and have installed Resin
> 4.0.29 from RPM. We have made minimal changes to the config to get up
> and running, and are facing an issue we haven't seen on any other Resin
> installation: When a .war is redeployed it seems the contents of the new
> .war is extracted, although the old content is not removed.
>
> This means, for example, if a JAR file is updated from foo-1.0.jar to
> foo-1.1.jar, when deployed on the new server we will have both
> foo-1.0.jar and foo-1.1.jar (and thus foo-1.0.jar will be used and this
> causes problems).
>
> Restarting Resin doesn't help. Once a file ends up in the expanded
> directory, I can only get rid of it by manual delete.
> Resin is currently running as root, so I can't really see how it could
> be an access issue.
>
> I have increased Resin logging but can't find anything abnormal in there.
>
> Are there any settings that can affect this?
> Anything I should look for in the log? (Any particular Resin package I
> should limit the logging to?)
>
> --
>
>
>
>
> ___
> 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 service threads!

[Bill Au]

On RHEL4, you need to use the -L option of ps to see threads:

ps -AL

BillOn 9/29/06, Swaminathan Subramanian <[EMAIL PROTECTED]> wrote:
Hello!I am running Resin 3.0 on Linux (RHE 4). My resin.conffor threads is as follows:500
10But, when I run ps -A, I see only one resin process.
Am I missing something here?Thanks in advance!-SS__Do You Yahoo!?Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com___resin-interest mailing listresin-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] ResinServer.destroy()

[Bill Au]

Both httpd.sh and wrapper.pl has the "-no-auto-restart" command line option.
Use that to disable automatic server restart.

BillOn 10/3/06, Shane Cruz <[EMAIL PROTECTED]> wrote:
>I am using the following codes, but somehow, resin keeps restarting.Any >help is very appreciated.The perl wrapper (wrapper.pl) is probably restarting the JVM when itrealizes it is not longer running.  You probably need to modify the perl
script or not use it at all.___resin-interest mailing listresin-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] ResinServer.destroy()

[Bill Au]

I have never run resin on Windows (and if I am lucky enough I am hoping I never will ;-)

Are you using httpd.exe to start resin?  I think it supports the same command line option
as httpd.sh.

BillOn 10/3/06, maildli <[EMAIL PROTECTED]> wrote:
Bill,Thanks for your valuable information.  It gives me a better idea.  I amlooking into the configuration and I couldn't find any helpful info.However, I am running on Windows, it doesn't recognize the
"-no-auto-restart" as a command line option.  Do you have any idea?  Can Imodify the wrapper.pl file to set the default as no-auto-restart?-DianaBill Au wrote:>> Both httpd.sh
 and wrapper.pl has the "-no-auto-restart" command line> option.> Use that to disable automatic server restart.>> Bill>> On 10/3/06, Shane Cruz <
[EMAIL PROTECTED]> wrote:>> >I am using the following codes, but somehow, resin keeps restarting.>> Any >help is very appreciated. The perl wrapper (
wrapper.pl) is probably restarting the JVM when it>> realizes it is not longer running.  You probably need to modify the perl>> script or not use it at all. ___
>> 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>>--View this message in context: http://www.nabble.com/ResinServer.destroy%28%29-tf2373440.html#a6626598
Sent from the Resin mailing list archive at Nabble.com.___resin-interest mailing list
resin-interest@caucho.comhttp://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] Easy way to tell resin to use -source 1.4 for 1 webapp

[Bill Au]

Specify that in the "args" attribute of .

Bill

http://caucho.com/resin-3.0/config/env.xtp#javacOn 10/5/06, Eric Carlson <
[EMAIL PROTECTED]> wrote:I pulled a webapp from the pre-1.5 days and it used enum (well the
soap libs used did as in org.apache.axis.enum.Stype.WRAPPER). I getthe error saying I should use -source 1.4 - is there an easy way to dothis for just 1 web app please? Thanks.___
resin-interest mailing listresin-interest@caucho.comhttp://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] Deadlocks Part 2

[Bill Au]

A thread dump is a snap shot of the JVM at a particular moment in time.
I find it useful to take consective thread dumps about 5 seconds apart.
That gives a moving picture of the JVM.  You may want to vary the number
of dumps or the time apart.

The thing to look for is how long are the threads waiting for a lock.
Lots of time I found things to be transient.  (ie the first dump showing many
threads waiting for lock(s) but in the dump 5 seconds later they are done).

You can use the thread id to following what is happening to a thread over
multiple thread dumps.

BillOn 10/13/06, sksamuel <[EMAIL PROTECTED]> wrote:
Further to my deadlocks issue,Is it normal to have lots of threads waiting for a lock on SSL sockets? Iknow I don't have that many people trying to connect through SSL - certainlythe number of threads waiting is disproportionate to the number of visitors.
Example:"resin-tcp-connection-127.0.0.1:6802-15" daemon prio=1 tid=0x095bbb80nid=0x7dbf waiting for monitor entry [0xa0c09000..0xa0c0a0b0] at java.net.PlainSocketImpl.accept(PlainSocketImpl.java
:382) - waiting to lock <0x681975a0> (a java.net.SocksSocketImpl) at java.net.ServerSocket.implAccept(ServerSocket.java:450) at java.net.ServerSocket.accept(ServerSocket.java:421) at com.caucho.vfs.QServerSocketWrapper.accept
(QServerSocketWrapper.java:97) at com.caucho.server.port.Port.accept(Port.java:798) at com.caucho.server.port.TcpConnection.run(TcpConnection.java:492) at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:516)
 at com.caucho.util.ThreadPool.run(ThreadPool.java:442) at java.lang.Thread.run(Thread.java:595)I also have a few threads waiting for a lock on ServletMapping - again isthat normal? Example:
"resin-tcp-connection-*:80-85" daemon prio=1 tid=0xb1edba48 nid=0x13a5waiting for monitor entry [0xac862000..0xac862eb0] atcom.caucho.server.dispatch.ServletConfigImpl.createServlet(ServletConfigImpl.java
:577) - waiting to lock <0x6a01ad00> (acom.caucho.server.dispatch.ServletMapping) atcom.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:97) at org.global7.epublisher.iface.filters.RewriteFilter.doFilter
(UnknownSource) atcom.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:70) atcom.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:173) atcom.caucho.server.dispatch.ServletInvocation.service
(ServletInvocation.java:229) at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:274) at com.caucho.server.port.TcpConnection.run(TcpConnection.java:511) - locked <0x6d819818> (a java.lang.Object
) at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:516) at com.caucho.util.ThreadPool.run(ThreadPool.java:442) at java.lang.Thread.run(Thread.java:595)___
resin-interest mailing listresin-interest@caucho.comhttp://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] Deadlocks Part 2

[Bill Au]

I would look at the first thread dump and find the thread holding the locks that all the other
threads were waiting on.  If there were more than one, I will
start with the lock on which the most threads are waiting on. 
Using the thread id, I would trace the life span of the thread
holding the lock in the rest of the thread dumps to see how long it was holding the lock.
If the same thread held the lock through out, there may be some
external factor slowing it down.  In this case it is doing file
I/O so I would for things like file system running out of space or the
file size getting too big.

Since your problem may be related to log archiving, can you disable
that feature to see if it makes any different.  Very often I found
that a complete different bottleneck may surface when you remove one
that is the most obvious.  Hopefully that is not your case.

BillOn 10/14/06, sksamuel <[EMAIL PROTECTED]> wrote:
>A thread dump is a snap shot of the JVM at a particular moment in time.> I find it useful to take consective thread dumps about 5 seconds apart.> That gives a moving picture of the JVM.  You may want to vary the number
> of dumps or the time apart.>> The thing to look for is how long are the threads waiting for a lock.> Lots of time I found things to be transient.  (ie the first dump showing> many> threads waiting for lock(s) but in the dump 5 seconds later they are
> done).>> You can use the thread id to following what is happening to a thread over> multiple thread dumps.Thanks for the reply Bill. I've done what you suggested and now have thread
dumps spanning a minute. There are many threads still sat in the waiting formonitor stage, any advice on where I go next to try and figure out what thedeadlock is ?___
resin-interest mailing listresin-interest@caucho.comhttp://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 2.1 Timer thread

[Bill Au]

If you start your own threads, be sure to stop it when the webapp is reloaded without stopping resin.  Otherwise, you will have a thread leak.  Each thread has a reference to its classloader,so all the classes loaded by that classloader will be be unloaded then the webapp is reloaded.
Eventually the permanent space of the JVM will run out.BillOn 10/30/06, Riccardo Cohen <[EMAIL PROTECTED]
> wrote:I prefer to use a separate thread launched by cron, out of resin.
I used to create a servlet that implements Runnable and that execute some tasks atspecified time, but as there is no need to receive http requests or answer anyway, whybothering with the whole Resin mechanism ? A simple java class can do the work.
Of course you do not have the database bool or ejb manager, but is it absolutely necessaryfor backoffice and transaction tasks ?Pauly Shore wrote:> I'm trying to work out a good clean way of creating a Timer thread inside a
> Resin 2.1.17 web container.> Does anyone know a good way of implementing this?>> I have a requirement to perform some work-intensive background processing> inside my web app, but it's too intensive to be done during a normal
> request/response cycle in my web application, so I'm looking for a way to> 'spawn off' the processing - either into a Timer thread running in the> background, or in a separate background thread that will not delay the
> response from the HTTP request coming in.>> I could just spawn off a thread inside my request handler, but I fear this> is bad practice inside a web container, where the threads are managed by the
> container itself.>> Resin 3.0 has some lovely features like JCA and the Work Management API for> managing long-working threads which would solve my problem but unfortunately> I just can't upgrade at this point.
>> Any help would be greatly appreciated. Thanks.>> Pauly>>> PS. I'm using Resin 2.1.17 with Java 1.4.2_10 on Win XP (and also on Red Hat> Linux).> My web app is mostly Struts/JSP with Oracle JDBC Thin drivers.
>--Très cordialement,Riccardo Cohenligne directe : 02-47-49-63-24---Articquehttp://www.articque.com
Moulin des Roches37230 Fondettes - Francetel : 02-47-49-90-49fax : 02-47-49-91-49___resin-interest mailing list
resin-interest@caucho.comhttp://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] web.xml and resin-web.xml

[Bill Au]

We use both web.xml and resin-web.xml for exactly the purpose that you have described.It has been working well for us.resin-web.xml is actually only an  in app-default.xml.  So you can change its name or location, or have more than one if you like.
BillOn 10/30/06, Thomas Moorer <[EMAIL PROTECTED]> wrote:
Hi,I have a question about web apps and a resin-web.xml file. Is it possible, to have multiple xml files in the WEB-INF directory (
web.xml and resin-web.xml)? I'd like to have standard web app stuff in the web.xml and resin specific config items in the other (such and quercus and other resin specific config items).
How would that be configured?Thomas  

Thomas C. Moorer, Jr.
Sleepycat Solutions, LLC
http://www.sleepycatsolutions.com
 
___resin-interest mailing listresin-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 jvm problem

[Bill Au]

As you increase the heap size, the time it takes to do a full gc will also
increase.
You can check your gc.log to see what that is like.

Is the 500 error reported by your Apache frontend?  If so, anything in
resin's log
file when that was happening?

By the way, what version of Java are you running?

Bill

On 1/5/07, Akila Amarathunga <[EMAIL PROTECTED]> wrote:


Hi All,

I have resin 3..0.21 install in a RH el4 and use apache as a frontend.
My problem with the default setting resin works ok but it gives an
'outofmemory' error when application usage is high. So I added following
in my httpd.sh,

args="-J-Xms64m -J-Xmx512m -J-verbose:gc -Xloggc:gc.log"

Then i didn't get the 'outofmemory' error but after sometime resin stop
responding. When trying to conenct to application it gives http error
'500' saying server not available due to maintenance.
Then I removed args and after that i didn't get the '500' error code
(but the memory problem is still there).

Please guys could you tell me what causes this problem ?

Thanks,
Akila


___
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 3.0.22 with cybersource SCMP ICSClient request exception

[Bill Au]

This is most likely a classloader related issue.  Where is your cybersource
jar installed?
Resin 3.0.x comes with javamail-14.jar in $RESIN_HOME/lib so you have on
need to
install and use mail.jar.

Bill


On 1/18/07, Huitang Li <[EMAIL PROTECTED]> wrote:


Hi,

Previously our cybersource SCMP codes worked with jdk 1.4.2 and resin
2.1.11.

Then, we switched to jdk 1.5.0_10 and resin 3.0.22, and we got this
exception when trying to sending out a SMCP request:

java.lang.NoClassDefFoundError: com/sun/mail/util/LineOutputStream

[14:45:48.875] at
javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:1333)

[14:45:48.875] at
javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:845)

[14:45:48.875] at
com.cybersource.security.mime.MimeParser.encode(MimeParser.java:145)

[14:45:48.875] at
com.cybersource.security.message.scmp.SCMPMessaging.composeSCMPMessage(
SCMPMessaging.java:82)


[14:45:48.875] at
com.cybersource.ics.client.ICSClientMessageManager.sendMessage(
ICSClientMessageManager.java:232)


[14:45:48.875] at
com.cybersource.ics.client.ICSClientMessageManager.send(
ICSClientMessageManager.java:155)


[14:45:48.875] at
com.cybersource.ics.client.ICSClient.send(ICSClient.java:318)

Actually, mail.jar is in classpath. However, it could not find the class
com/sun/mail/util/LineOutputStream

Any idea?

Thanks.


___
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] Send 503 when servlet init is very long

[Bill Au]

You should be able to cause those requests to fail by setting read-timeout
and write-timeout
in .  But it probably won't be a 503.

Be careful if you do decide to start a background thread from your servlet.
There was a recent thread on the mailing list about that.

Bill

On 2/8/07, Daniel López <[EMAIL PROTECTED]> wrote:


Hi,

Not sure if that would work for you or not, but another option would be
to move that initial process to a background thread and then your app
can check itself if the init has finished or not, and answer with a
nicer message "initalisation in progress, please wait..." etc, rather
than holding the container initialisation for that long.

The problem I see with halting resin init-process is that if you add
other servlets or other applications in the same container, they might
have to wait for that long, even if they could be answering requests
already. Moreover, doing it on your own would also make your web app
container-agnostic, you would not depend on the container holding other
servlets or not, returning 503s or not...

Just an idea,
D.

Bryan Engel escribió:
> Hi,
>
> I have a servlet running on Resin 3.0.14 that takes a very long in init
> (up to 15 minutes).  As soon as init has finished, all the requests that
> came in during that time are processed, even it they are minutes old.
>
> I tried using the following in my resin.conf file but this didn't do
> anything:
>  
>   5s
>   ...
>
> Is there a way to make resin turn away these requests with 503s or
> similar until init is finished?
>
> Thanks in advance.


___
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] default servlet mapping

[Bill Au]

You need a  block to define a servlet with the name default.
This should come before 


 default
 _package.classname_


Take a look at the DirectoryServlet in resin.conf as an example.

Bill

On 3/8/07, Ioannis Cherouvim <[EMAIL PROTECTED]> wrote:



Hello

I have a webapp which uses a servlet to catch all urls for processing
(front controller).
The pattern for this servlet is: /

Before that I need to tell the container that all static content will
pass from the default servlet (or fileservlet in resin).

In tomcat and jetty I do that using:

default*.swf

default*.html

default*.htm

But when I try that in resin I get:
WEB-INF/web.xml:89: `default' is an unknown servlet-name.
servlet-mapping requires that the named servlet be defined in a
 configuration before the .

I also tried 'file' instead of 'default' as I think that the
fileservlet of resin is called 'file', but no luck.

Any ideas?

thanks,
Ioannis


___
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] Too many open files

[Bill Au]

You can also use the lsof command to find out what is being opened.
Network connections count as open files too.

Bill

On 3/15/07, sksamuel <[EMAIL PROTECTED]> wrote:


I'm assuming this is on Linux or something else that's Unixy.  You can
find out what your limit for open files is by typing "ulimit -a".
Here's an example from one of my systems:

.

Do a "man bash" and search for "ulimit" if you want more details.





Thanks very much for your help Jose.

Sam.


___
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 3.0.x, 64bit CPU and Linux

[Bill Au]

We use Resin 3.0 on both 32-bit Intel and 64-bit AMD Red Hat Enterprise
Linux 4
and don't see any difference in terms of stability and reliability between
32-bit and 64-bit.  Be sure to use 3.0.23 though.  Earlier versions of 3.0.x
have buggy version of the configure script that does not always work on
64-bit machine.  Here is one such bug for 3.0.22:

http://bugs.caucho.com/view.php?id=1465

The problem is not limited to 3.0.22.

We use a very big JVM heap on the 64-bit machine, something that we simply
cannot do on a 32-bit machine.

Bill

On 4/17/07, Keith Fetterman <[EMAIL PROTECTED]> wrote:


We currently run resin 3.0.19 in production on a single x86 32 bit CPU
running Red Hat Enterprise 3 Linux.

We are thinking about upgrading the hardware to a 64 bit CPU so we can
leverage the expanded memory footprint of the JVM.  We will continue to
use Linux.

Is anyone experiencing problems running Resin 3.0.x on the 64 bit
Intel/AMD servers running Linux.  If so, please share your experiences
with me.  I would like to know if this is a good move or not.

Thanks,
Keith

--
-
Keith Fetterman  206-780-5670
Mariner Supply, Inc. [EMAIL PROTECTED]
http://www.go2marine.com


___
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] LDAPAuthenticator with ActiveDirectory

[Bill Au]

I ended up writing my own authenticator extending Caucho's
AbstractAuthenticator
because I need to use ldaps and need some custom functionality.
Things should work if the default PROVIDER_URL is good for you (ie
ldap://localhost:389).

Bill

On 5/3/07, Riccardo Cohen <[EMAIL PROTECTED]> wrote:


Hi
I'm also interested in LDAP authentification, our new customer is a big
organization, and they want our application to use LDAP services for
authentification. I must say that I know very few about this.

I could not find any class in resin's doc about LDAP, but found a page
here from "Ferg" :

http://bugs.caucho.com/view.php?id=666

It seems rather complex for me, as I'm reading these pages, I would need
to include Acegi framework, then Spring framework, and finally a Resin
adaptor which is a whole project itself...

For my application, I only need a very simple java class getting current
user name from LDAP, so a web user that is already authenticated does
not have to retype its login/password...

But I really don't know if it can be as simple as that... !

cilquirm wrote:
> Does anyone have any experience using Caucho's LDAPAuthenticator with
> ActiveDirectory?
>
> Still continuing on my quest to investigate possible ActiveDirectory
> authentication options.
>
> Any help would be appreciated.
>
>
> Thanks,
> -a

--
Très cordialement,

Riccardo Cohen
ligne directe : 02-47-49-63-24
---
Articque
http://www.articque.com
149 av Général de Gaulle
37230 Fondettes - France
tel : 02-47-49-90-49
fax : 02-47-49-91-49


___
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] LDAPAuthenticator with ActiveDirectory

[Bill Au]

There are many tutorials/examples on the web.  This one covers both security
and searches:

http://java.sun.com/products/jndi/tutorial/ldap/

Bill

On 5/3/07, Riccardo Cohen <[EMAIL PROTECTED]> wrote:


All right, but if I want to write my own one, I need to know ldap
protocole :)... where do you find this ?


Bill Au wrote:
> I ended up writing my own authenticator extending Caucho's
> AbstractAuthenticator
> because I need to use ldaps and need some custom functionality.
> Things should work if the default PROVIDER_URL is good for you (ie
> ldap://localhost:389).
>
> Bill
>
> On 5/3/07, *Riccardo Cohen* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> Hi
> I'm also interested in LDAP authentification, our new customer is a
big
> organization, and they want our application to use LDAP services for
> authentification. I must say that I know very few about this.
>
> I could not find any class in resin's doc about LDAP, but found a
page
> here from "Ferg" :
>
> http://bugs.caucho.com/view.php?id=666
>
> It seems rather complex for me, as I'm reading these pages, I would
> need
> to include Acegi framework, then Spring framework, and finally a
Resin
> adaptor which is a whole project itself...
>
> For my application, I only need a very simple java class getting
current
> user name from LDAP, so a web user that is already authenticated
does
> not have to retype its login/password...
>
> But I really don't know if it can be as simple as that... !
>
> cilquirm wrote:
>  > Does anyone have any experience using Caucho's LDAPAuthenticator
with
>  > ActiveDirectory?
>  >
>  > Still continuing on my quest to investigate possible
ActiveDirectory
>  > authentication options.
>  >
>  > Any help would be appreciated.
>  >
>  >
>  > Thanks,
>  > -a
>
> --
> Très cordialement,
>
> Riccardo Cohen
> ligne directe : 02-47-49-63-24
> ---
> Articque
> http://www.articque.com
> 149 av Général de Gaulle
> 37230 Fondettes - France
> tel : 02-47-49-90-49
> fax : 02-47-49-91-49
>
>
> ___
> 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

--
Très cordialement,

Riccardo Cohen
ligne directe : 02-47-49-63-24
---
Articque
http://www.articque.com
149 av Général de Gaulle
37230 Fondettes - France
tel : 02-47-49-90-49
fax : 02-47-49-91-49


___
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] XML View Question

[Bill Au]

Here is the link to an article on SDN on trimDirectiveWhitespaces:
http://java.sun.com/developer/technicalArticles/J2EE/jsp_21/

Please be aware that with trimDirectiveWhitespaces enabled, all
whitespaces between two JSP tag are removed.  So something like:

 

will output:

HelloWorld

instead of:

Hello World


Bill

On 5/8/07, Scott Ferguson <[EMAIL PROTECTED]> wrote:
>
> On May 8, 2007, at 9:51 AM, Aaron Freeman wrote:
>
> > Can anybody provide me with any links/hints on this?
>
> JSP 2.1 has a trimDirectiveWhitespace option for the <%@ page %>
> tag.  That would be the cleanest way to remove the extra whitespace.
>
> -- Scott
>
> >
> > Thanks,
> >
> > Aaron
> >
> >
> >> -Original Message-
> >> From: [EMAIL PROTECTED]
> >> [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Freeman
> >> Sent: Thursday, May 03, 2007 10:59 AM
> >> To: resin-interest@caucho.com
> >> Subject: [Resin-interest] XML View Question
> >>
> >> We have a controller JSP that looks like this:
> >>
> >>  Begin Controller  <%@ taglib
> >> uri="http://java.sun.com/jsp/jstl/core"; prefix="c" %> <%@
> >> taglib uri="http://java.sun.com/jsp/jstl/functions"; prefix="fn" %>
> >>
> >> 
> >>
> >> ... do some logic 
> >>
> >> 
> >>
> >> 
> >> 
> >>
> >> 
> >> 
> >> 
> >> <%-- An exception occured. --%>
> >> 
> >>  
> >> 
> >>
> >> 
> >>  End Controller 
> >>
> >> Then our xml/_view.jsp would look something like this:
> >>
> >>  Begin xml/_view.jsp   >> version="2.0">
> >>
> >> http://java.sun.com/jsp/jstl/core";
> >> prefix="c" />
> >>
> >> 
> >> 
> >> 
> >>
> >> ... output some XML tags 
> >>
> >> 
> >> 
> >>
> >> 
> >>  End xml/_view.jsp 
> >>
> >> The problem is sometimes the end result has a bunch of white
> >> space at the beginning of the document and sometimes the
> >>  generates lots of linefeeds which cause XML
> >> parsers to fail.  What is the proper way to dump an XML view
> >> such that there are no linefeeds in between the XML tags and
> >> there isn't a lot of whitespace above the XML?
> >>
> >> 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] clearing cache manually or in code

[Bill Au]

In 3.0.x, the server mbean has a clearCache() and a clearCacheByPattern(host,
url) method in com.caucho.server.resin.mbean.ServletServerMBean.  The name
of the mbean should be resin:type=Server,name=default

Bill

On 5/31/07, Bernard Bernstein <[EMAIL PROTECTED]> wrote:


We are using the Resin proxy cache by setting Expire headers on some
files (jsp files that generate css and some javascript).
Occasionally, we want to get a new version of these files loaded, but
we don't want to set a short expiration time for the occasional
change in something.

For example.

We might have a .jsp file that is the stylesheet, where we can set
the font size through some frontend setting. We want that page to be
cached most of the time, but when someone changes that font, we don't
want them to need to wait for an hour for the cached version to
expire before everyone sees the new font size. We also don't want the
overhead of executing the jsp for every pageview.

The jsp file itself isn't changing, so resin wouldn't necessarily
know that the page has expired. So, is there any way we can
programmatically clear that page cache, or all cached pages for that
matter.

Looking through archives I see discussion of adding:

true

to a webapp setup, but that doesn't seem to work anymore now that
we're starting to use 3.1 (I haven't tested on 3.0 which we are using
in production).

I've also tried calling
com.caucho.server.resin.ServletServer.clearCache() and doesn't seem
to compile.

I'm using jconsole to look at the jmx-accessible beans, but I don't
see anything there that can help with this either.

What is the modern way to clear the cache during runtime? I'm having
some trouble finding an answer, so I thought I'd ask here.

Thanks,


Bernie



___
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] ssl port

[Bill Au]

With the SSL port set up in Resin, relative redirect on a https request
should go to the SSL port.  Is that not the case?

Bill

On 6/1/07, Michael Fortin <[EMAIL PROTECTED]> wrote:


Hello,

We have our servers setup behind a load balancer and the load balancer
does all the encryption for ssl.  All traffic inside our network is on
port 8080.  If I do a relative redirect on a request from a secure url
it returns an insecure url.  To try and fix this I setup another http
port in the resin conf for 8443 and set the load balancer to send secure
traffic to that port.  Tomcat has a isSecure flag on it's connector to
tell the request it's a secure request even though it's already
decrypted.  Does resin have something like that?  Will resin know to
make a secure link on that port?

Resin version 3.0.18
JDK 1.5.0_10
Linux

Thanks
Michael


___
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] ssl port

[Bill Au]

There is a  under 

http://www.caucho.com/resin-3.0/config/resin.xtp#host

You may have to use that to set the port number for SSL.

Bill

On 6/1/07, Michael Fortin <[EMAIL PROTECTED]> wrote:


Hi Bill,

Thanks for the response.  Honestly, I haven't tested it just yet.  I
didn't see a 'secure' attribute on the  config element so I just
wanted to confirm that 8443 will implicitly be secure even though I'm
not setting an encryption handler.  I didn't see anything here
(http://caucho.com/resin-3.0/security/ssl.xtp#notneeded)  about it.
I'll be back if it doesn't work.

Thanks again,
Michael


Bill Au wrote:
> With the SSL port set up in Resin, relative redirect on a https
> request should go to the SSL port.  Is that not the case?
>
> Bill
>
> On 6/1/07, *Michael Fortin * <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> Hello,
>
> We have our servers setup behind a load balancer and the load
balancer
> does all the encryption for ssl.  All traffic inside our network is
on
> port 8080.  If I do a relative redirect on a request from a secure
> url
> it returns an insecure url.  To try and fix this I setup another
http
> port in the resin conf for 8443 and set the load balancer to send
> secure
> traffic to that port.  Tomcat has a isSecure flag on it's
> connector to
> tell the request it's a secure request even though it's already
> decrypted.  Does resin have something like that?  Will resin know to
> make a secure link on that port?
>
> Resin version 3.0.18
> JDK 1.5.0_10
> Linux
>
> Thanks
> Michael
>
>
> ___
> 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

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

Re: [Resin-interest] importing java.io, java.util packages in JSPs

[Bill Au]

We actually bite the bullet and fixed all our JSPs when we migrated from
WebLogic to Resin.
The version of WebLogic we were using allow us to do things like:

<%@ page import="
   java.util.*;
   import java.net.URL,
   java.io.*
" %>

which is clearly not JSP spec compliant.  We decided to make all our JSPs
and Java code spec compliant to make our application vendor independent.

Bill

On 6/27/07, Karthik Gajjala <[EMAIL PROTECTED]> wrote:


 Hi,

While migrating from Weblogic to Resin, I have noticed that Resin requires
us to explicitly import

the basic Java language packages like io, util. This makes sense as a
software developer.

We have 100's of JSPs developed by our Web Developers who did not do this
and Weblogic used

to do this by default when generating the output Java file from JSP. Is
there a way in Resin to

do the same?. Something better than painfully editing the JSP files to add
these imports J

Regards,

*Karthik Gajjala*

Director of Engineering

Vendio Inc.

408-718-6503 (Cell)

AIM : karthikgajjala


___
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] web.xml for resin 3.0.23/servlet 2.4: is an unexpected tag

[Bill Au]

 is an Resin extension to web.xml so try this:

http://caucho.com/ns/resin";>
  ...


Bill

On 9/26/07, Kimberly Nicholls <[EMAIL PROTECTED]> wrote:
>
>  I am having trouble upgrading my web.xml to use servlet 2.4 instead of
> 2.3.  I removed the doctype, and added the schema stuff to the web-app
> tag. I'm getting this error:
>
> SEVERE com.caucho.config.LineConfigException: WEB-INF/web.xml:16:
>  is an unexpected tag (parent  starts at 5).
>
> I didn't move the access-log tag, and according to
> http://www.caucho.com/resin-3.0/config/log.xtp#access-log, it should be a
> child of web-app.
>
> Here's the top part of my web.xml:
>
> 
>   xmlns="http://java.sun.com/xml/ns/j2ee";
>  
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>  xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
> http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd";
> >
>
>  resin:type="com.company.CustomLogger"/>
>
> If I comment out the access-log tag, I get the same error with a
> rewrite-dispatch tag further down in the file ( is an
> unexpected tag).  I noticed that access-log and rewrite-dispatch are not
> in the   syntax info that gets written to the error log.  Where
> should they go?
>
> Kimberly Nicholls
>
> ___
> 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] Compelling reasons to use Resin?

[Bill Au]

I have also heard that Tomcat's performance has been improved.  Has anyone
actually done a head-to-head performance comparison between the latest
version of Resin and Tomcat?  I had wanted to do one but have not been able
to find the time.  If I ever get around to do so, I will post my findings
here.

Bill

On 10/16/07, Hari Selvarajan <[EMAIL PROTECTED]> wrote:
>
> Greetings,
>
> I've been a Resin advocate for several years now. When I first did a
> performance comparison between Resin 2 and Tomcat, Resin's performance
> simply blew me away. Like many other people on this list, I imagine I
> switched entirely to recommending resin as the application server for
> all the projects I've worked on. They were all small startups so it
> didn't count towards hundreds of licenses, but still.
>
> Now, at another startup that I'm working with - with a licensed version
> of Resin Pro for our one app server -I'm being asked to justify the use
> of Resin over Tomcat, specially as look to grow and add additional
> servers. We use Resin only as a servlet container, so its EJB and PHP
> capabilities are not a justification. Googling around leads me to
> believe that Tomcat has gotten a lot faster recently, with NIO support
> in 6.0.x, and that the performance gap may have narrowed of late.
>
> So I seek the collective wisdom of the list: what are some of the
> compelling reasons that led you to choose Resin Pro over other
> application servers, and Tomcat in particular? Is anyone aware of recent
> benchmarks that compare resin and tomcat?
>
> To close, I should say that I personally love resin - its elegance,
> configuration simplicity and developer-friendliness. It's just that I'm
> trying to find a reason to convince management why we should use it over
> the "free" application server.
>
> Many thanks,
>
> - Hari
>
>
> ___
> 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 3.1 independent instances

[Bill Au]

You could use a different watchdog-port for each of your instance:

http://www.caucho.com/resin/doc/server-tags.xtp#watchdog-port

Bill


On Feb 7, 2008 12:27 PM, Daniel Lopez <[EMAIL PROTECTED]> wrote:

> Would then be the recommended way to work to set all watchdog ports on
> all resin.conf files to be the same one? I'm thinking that might be
> causing some of the issues as "side effect".
>
> I understand the reason to use a well-known port, but sometimes the
> instances stop responding due to some application misbehaving (in our
> case, usually a DB breaks connections the wrong way and ends up
> blocking the JVM) and that's the time to kill the process manually. We
> have some scripts to check the status of the OS processes as sometimes
> the applications themselves, as bad patients, are not reliable on
> answering about their status :). Having an option to hard-kill
> instances have been proven very useful through the years, with this or
> any long lived processes. It's not an issue specific to Resin or any
> other server.
>
> My only issue was the watchdog process reporting instances to be up
> when they were not, as this woud mean it would not startup the new
> instance. So thanks for creating the bug reports, I'll keep an eyem on
> them to upgrade again.
>
> S!
> D.
>
>
> >> So my question would be... is there any configuration setting I can
> >> use
> >> with 3.1 to have several instances totally independent, so I can
> >> start/stop/kill one of them without affecting the rest? Unfortunately,
> >> sharing ONE resin.conf file is not an option and using ONE instance is
> >> not an option as well.
> >
> > That's the purpose of the watchdog-port.  The start/stop program needs
> > a well-known port so it can tell the instance to shut down.  The old
> > 3.0 method used pid files to handle the same situation.
> >
> > -- 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] Managing separate watchdog processes in 3.1.5

[Bill Au]

http://www.caucho.com/resin/doc/resin-watchdog.xtp

I also want to run multiple independent instances on the same machine.
Scott and company, I think it will be useful to include an example of that
in the resin 3.1 documentation for the watchdog process.
This is a big change from Resin 3.0 which took me a while to figure out.

Bill

On Mon, Mar 10, 2008 at 5:19 PM, Eric Kreiser <[EMAIL PROTECTED]> wrote:

>  Is there a way to specify what IP the watchdog-port will bind to?
>
> I want to be able to have a number of sites/instances of resin running on
> a machine
> I want all of them to run independent of each other
>
> so to keep them independent, I need to specify a watchdog-port... but if I
> do... it binds to the main ip of the machine... so in my scenario, I would
> need to assign each resin instance a unique port number.
>
> Is there a better way for me to handle this?
>
> Thanks
> Eric Kreiser
>
>
>
> ___
> 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] Managing separate watchdog processes in 3.1.5

[Bill Au]

Sorry, I had misread your original question.

Bill

On Tue, Mar 11, 2008 at 9:27 AM, Eric Kreiser <[EMAIL PROTECTED]> wrote:

>  I had found the ... my issue with this is that when it
> binds to the IP, it binds to the main IP of the server... so if I have say
> 10 sites running on a machine, I would need to keep track of 10 unique port
> numbers to assign to each resin instance.  In my case, each of the 10 resin
> instances are bound to different IP addresses on the server, so I would much
> prefer a way to specify that the watchdog port bind to the same IP the resin
> server is using for the sites themselves.
>
> Bill Au wrote:
>
> 
>
> http://www.caucho.com/resin/doc/resin-watchdog.xtp
>
> I also want to run multiple independent instances on the same machine.
> Scott and company, I think it will be useful to include an example of that
> in the resin 3.1 documentation for the watchdog process.
> This is a big change from Resin 3.0 which took me a while to figure out.
>
> Bill
>
> On Mon, Mar 10, 2008 at 5:19 PM, Eric Kreiser <[EMAIL PROTECTED]> wrote:
>
> >  Is there a way to specify what IP the watchdog-port will bind to?
> >
> > I want to be able to have a number of sites/instances of resin running
> > on a machine
> > I want all of them to run independent of each other
> >
> > so to keep them independent, I need to specify a watchdog-port... but if
> > I do... it binds to the main ip of the machine... so in my scenario, I would
> > need to assign each resin instance a unique port number.
> >
> > Is there a better way for me to handle this?
> >
> > Thanks
> > Eric Kreiser
> >
> >
> >
> > ___
> > resin-interest mailing list
> > resin-interest@caucho.com
> > http://maillist.caucho.com/mailman/listinfo/resin-interest
> >
> >
> --
>
> ___
> resin-interest mailing [EMAIL 
> PROTECTED]://maillist.caucho.com/mailman/listinfo/resin-interest
>
>
> --
>
> *Eric S. Kreiser**
> *Senior Software Architect
>
>
> *M**z**inga**
> *5095 Ritter Road • Mechanicsburg, PA  17055
> ---
> *Call my office:* 717.790.0400 x4256
> *Fax me:* 717.790.0401
> *Email me:* [EMAIL PROTECTED]
> *Learn more:* http://mzinga.com/v/ekreiser/
> *Toll Free:* 800.869.5763
>
>
>
> ___
> 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] Memory and slowdown...

[Bill Au]

I would take some threads dump during heavy load to see what is going on.
Jconsole with the JTop plug-in can show you the threads that are using the
most CPU.

Bill

On Tue, Apr 8, 2008 at 12:06 AM, Knut Forkalsrud <[EMAIL PROTECTED]>
wrote:

>
>  On Apr 7, 2008, at 9:18 AM, Sandeep Ghael wrote:
>
> -Xdebug
>
>
> In my experience the debug switch sometimes causes the JVM to behave
> erratically under heavy load.  I would get rid of it and try again.
>
> -Knut
>
>
>
> ___
> 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] Can Resin redirect to a completely different URL?

[Bill Au]

I got move-permanently and redirect to work across webapps but am not able
to get forward to do so.  Is that possible at all with Resin?  I am asking
since I am not sure all the clients access my webapps can handle 301/302 to
redo request to the new URL.  For example, curl by default does not do so.
You need to run curl with the -L/--location option in order for this to
work.

Bill

On Wed, Aug 23, 2006 at 4:44 PM, Rob Lockstone <[EMAIL PROTECTED]> wrote:

> Ahh, great! I tried just plain  again, Scott!
>
> Rob
>
> On Aug 23, 2006, at 13:38 , Scott Ferguson wrote:
>
> >
> > On Aug 23, 2006, at 1:25 PM, Rob Lockstone wrote:
> >
> >> We're running Resin 3.0.21 Pro standalone and need to be able to
> >> redirect an incoming page request to a completely different server,
> >> e.g.:
> >>
> >> http://mysite.mydomain.com/blah/blah.html ---> http://
> >> differentSite.differentDomain.com/blah/blah.html
> >>
> >> I've been able to use the rewrite-dispatch tag for the other
> >> redirects, but this new one has me a bit perplexed. Any ideas?
> >
> > Sure, you can use:
> >
> > 
> >   http://blah.com"/>
> > 
> >
> > -- 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] How to remove new line preamble in JSP

[Bill Au]

Resin does support the trimDirectiveWhitespaces configuration parameter
which is defined in the JSP 2.1 specifications.

http://java.sun.com/developer/technicalArticles/J2EE/jsp_21/

Bill

On Wed, Jun 4, 2008 at 6:05 AM, bisoa <[EMAIL PROTECTED]> wrote:

>
> It seems like I have to code without white spaces! Tomcat's way may not be
> uiversal and may not work on other application servers.
> --
> View this message in context:
> http://www.nabble.com/How-to-remove-new-line-preamble-in-JSP-tp17640964p17643305.html
> Sent from the Resin mailing list archive at Nabble.com.
>
>
>
> ___
> 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] Need expert to help with JVM troubleshooting

[Bill Au]

Take some thread dumps when your CPU utilization is high too see whats'
going on inside that JVM during that time.

Bill

On Thu, Jul 10, 2008 at 4:57 PM, Adam Allgaier <[EMAIL PROTECTED]> wrote:

> We're having stability issues with our app running on Resin, characterized
> by climbing memory usage, and 100% CPU utilization, and frequent server
> crashes.  We're looking for an expert who will be willing to help us.  Any
> recommendations on where we can find one?
>
> Thank you,
> Adam Allgaier
>
>
>
>
>
>
> ___
> 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] Announcing Resin Administration training

[Bill Au]

Is the focus of this course on 3.1 only or will 3.0 be covered as well.

Bill

On Wed, Aug 27, 2008 at 9:00 PM, Emil Ong <[EMAIL PROTECTED]> wrote:

> We're proud to announce the beginning of a new training program at
> Caucho.  We've partnered with Marakana to do the first course, which
> will be on Resin Administration.  I, Emil Ong, will be teaching the
> course October 22-24 at Marakana's San Francisco facilities.  The space
> is limited to 10 students in order to assure a good student:teacher
> ratio.  If you sign up by Sept 7, you'll get a nice discount, so it's
> worth your while to sign up soon to get a spot.
>
> There's a page here with more information about the course, including a
> detailed outline of topics to be covered:
>
>
> http://marakana.com/training/resin/caucho_resin_administration.html?a=caucho
>
> You can also sign up for the course from that page.
>
> This is just the beginning of our training program.  We're also
> exploring other courses such as Development using Resin and an in depth
> Quercus course.  Additional dates for this administration course are
> also being considered.  Input on future courses is appreciated!
>
> Thanks everyone and see you in San Francisco!
> Emil
>
> 
>
> Emil Ong
> Chief Evangelist
> Caucho Technology, Inc.
> Tel. (858) 456-0300
> mailto:[EMAIL PROTECTED]
> http://blog.caucho.com/
>
> Caucho: Reliable Open Source
> --> Resin: application server
> --> Quercus: PHP in Java
> --> Hessian Web Services
>
>
> ___
> 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 Pro licencing and support

[Bill Au]

With the pro license, you get better performance from both resin and
quercus.

Bill

On Thu, Sep 4, 2008 at 12:52 PM, Rob Lockstone <[EMAIL PROTECTED]> wrote:

> We have a 100 Server Pro license and are very happy with it.
>
> Back in the day, there was no "Pro" version (as I recall). But as
> Resin has matured, having the Pro version has become more important if
> you're going to be using Resin in a production environment, or even if
> you just want to become familiar with the capabilities/features of the
> Pro version for future use.
>
> I agree, if you can afford to license Pro, it's definitely good to
> support further development. As you can tell, Resin is, and has been
> for years, frequently updated with bug fixes and new features, so you
> wouldn't be investing in a product that languishes for months or years
> with no new releases.
>
> Rob
>
> On Sep 4, 2008, at 08:29, Heimo Laukkanen wrote:
>
> > Hi all,
> >
> > I have to say that I'm extremely impressed with my tests with resin
> > and quercus - and have started to wonder, whether licencing the pro
> > version would actually be worth it - if nothing else, then just to
> > support the development :-D
> >
> > What is the general feeling among people using Resin: do you use pro
> > version or manage with open source versions? Have you been happy with
> > the nromal support , or have you invested in priority support?
> >
> > I've previosly been using mostly Sun Glassfish, but Resin has some
> > neat features and small footprint to be very interesting tool to be
> > used. My main interest though for Resin is Quercus - the ability to
> > use php-frontend with existing skillsets from contractors, and build
> > robust Java-backend. And eventhough Quercus can be used in other
> > appservers too, the fact that it would be supported and tested on
> > resin weights a  lot.
> >
> > -huima
> >
>
>
>
> ___
> 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