Re: [Resin-interest] Environment class loader throwing a ClassNotFoundException when resin 4 is restarted
Hi Scott,
Thanks filing this as a bug. I ran some more tests and it looks like
its related to the HTTP session timing out or being invalidated. If a
request for that session occurs after the timeout, I see the
EnvironmentClassLoader exceptions.
Keith
On 04/04/2011 11:55 AM, Scott Ferguson wrote:
> On 04/04/2011 11:39 AM, Keith Fetterman wrote:
>> I am wondering if this problem is related to the HTTP session timing
>> out. In the ROOT web application, we have the session time out set to
>> 70 minutes:
>>
>> WEB-INF/web.xml
> Possibly. I've filed it as a bug.
>
> The Java deserializer requires a classloader handler for proper
> deserialization. It's possible that it's not properly handled in some
> contexts.
>
> -- Scott
>
>>>
>>> 70
>>>
>> I received another ClassNotFoundException from the
>> EnvironmentClassLoader after 30 minutes, which is the default session
>> timeout for most Web apps.
>>
>>
>> On 04/04/2011 11:19 AM, Keith Fetterman wrote:
>>> This problem seems to be more pervasive in Resin 4.0.16 pro. I am now
>>> seeing other application classes that the Resin EnvironmentClassLoader
>>> is trying to load but it can't find them. I am getting the error
>>> "java.lang.ClassNotFoundException" because the
>>> "EnvironmentClassLoader[resin-system:]" is trying to load it. In our
>>> resin.xml file, I have the application classes being loaded at at the
>>> Host level.
>>>
>>> Resin was started at 9:55 AM this morning. Since then, I have been
>>> testing our Website including checking out, which would require
>>> "com.marinersupply.common.store.struts.form.checkout.CheckoutCustomerInfoForm"
>>> class to be loaded. Then at 10:37 AM, resin throws the error:
>>>
[11-04-04 10:37:46.336] {http://*:8082-23} WARNING
com.caucho.server.session.SessionImpl
com.caucho.vfs.IOExceptionWrapper: java.lang.ClassNotFoundException:
com.marinersupply.common.store.struts.form.checkout.CheckoutCustomerInfoForm
in EnvironmentClassLoader[resin-system:]
>>> It looks like the error is occurring when resin is either serializing or
>>> deserializing the session. Is the EnvironmentClassLoader above the host
>>> class loader and if so, why is trying to load application classes? Is
>>> this a bug in resin 4.0.16?
>>>
>>>
[11-04-04 10:37:46.336] {http://*:8082-23} WARNING
com.caucho.server.session.SessionImpl
com.caucho.vfs.IOExceptionWrapper: java.lang.ClassNotFoundException:
com.marinersupply.common.store.struts.form.checkout.CheckoutCustomerInfoForm
in EnvironmentClassLoader[resin-system:]
at
com.caucho.vfs.IOExceptionWrapper.create(IOExceptionWrapper.java:64)
at
com.caucho.server.session.SessionImpl.load(SessionImpl.java:706)
at
com.caucho.server.session.SessionImpl.load(SessionImpl.java:642)
at
com.caucho.server.session.SessionManager.createSession(SessionManager.java:1332)
at
com.caucho.server.http.AbstractCauchoRequest.createSession(AbstractCauchoRequest.java:255)
at
com.caucho.server.http.AbstractCauchoRequest.getSession(AbstractCauchoRequest.java:198)
at
com.caucho.server.http.AbstractCauchoRequest.finishRequest(AbstractCauchoRequest.java:613)
at
com.caucho.server.http.HttpServletRequestImpl.finishRequest(HttpServletRequestImpl.java:1961)
at
com.caucho.server.http.AbstractHttpRequest.finishRequest(AbstractHttpRequest.java:1725)
at
com.caucho.server.http.HttpRequest.finishRequest(HttpRequest.java:1268)
at
com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:813)
at
com.caucho.network.listen.TcpSocketLink.dispatchRequest(TcpSocketLink.java:730)
at
com.caucho.network.listen.TcpSocketLink.handleRequest(TcpSocketLink.java:689)
at
com.caucho.network.listen.TcpSocketLink.handleRequestsImpl(TcpSocketLink.java:669)
at
com.caucho.network.listen.TcpSocketLink.handleRequests(TcpSocketLink.java:617)
at
com.caucho.network.listen.AcceptTask.doTask(AcceptTask.java:104)
at
com.caucho.network.listen.ConnectionReadTask.runThread(ConnectionReadTask.java:98)
Re: [Resin-interest] Multiple instances of the same webapp after redeploy in 4.0.16 (strange!!!)
On 04/04/2011 10:02 AM, Mattias Jiderhamn wrote:
> Scott Ferguson wrote (2011-04-04 18:47):
>> On 04/04/2011 12:43 AM, Mattias Jiderhamn wrote:
>>> While evaluating Resin 4.0.16 we are seeing something that makes me
>>> really concerned. It appears as if after a redeploy there can be two
>>> instances of our main app running.
>>>
>>> I was made aware of this by noticing that timed servlets (>> ... />) were having concurrency issues and logging the same event
>>> twice within the same second.
>>> This made me add some extra logging in a servlet,
>>> and I can actually see that at some reploys, the same web app is
>>> initialized twice - in different, concurrent threads and different
>>> classloaders.
>>> For example one instance may be initialized by
>>> Thread[http://*:8080-776,5,main] and at the same time (give or take
>>> a few seconds) another one by Thread[resin-366,5,main].
>>>
>>> I cannot deliberately recreate it by simply redeploying (which makes
>>> it less likely to be a configuration issue). But it happens about
>>> daily on our test server; possibly issuing requests on a session in
>>> the app while redeploying is a factor.
>>>
>>> We are not using versioning.
>>> dependency-check-interval is set to 20 seconds.
>>> The "extra" app does not appear in the admin console.
>>>
>>> How can we figure out what is going on here???
>>>
>>
>> Are you using version="true" and/or versioned web-apps? With
>> versioned web-apps, Resin is supposed to have two versions running at
>> the same time while it migrates sessions from the old version to the
>> new version.
>
> As stated above, we are not using versioning.
> (And if we we're, should the old version be re-initialized when
> deploying a new version...?)
Do you have logs for these events? The WebApp start/stop should be
logged at the info level and be in the jvm-default.log.
I can't yet see how this is happening, though I have found a related
issue with 503s.
The main thing I'd be looking for is:
{thread1} WebApp[/foo] start
{thread2} WebApp[/foo] stop
{thread2} WebApp[/foo] start
{threadX} WebApp[/foo] stop
VS
{thread1} WebApp[/foo] start
{thread2} WebApp[/foo] start
...
In other words, an actual simultaneous start compared to an erroneous
restart.
-- Scott
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Environment class loader throwing a ClassNotFoundException when resin 4 is restarted
On 04/04/2011 11:39 AM, Keith Fetterman wrote:
> I am wondering if this problem is related to the HTTP session timing
> out. In the ROOT web application, we have the session time out set to
> 70 minutes:
>
> WEB-INF/web.xml
Possibly. I've filed it as a bug.
The Java deserializer requires a classloader handler for proper
deserialization. It's possible that it's not properly handled in some
contexts.
-- Scott
>>
>> 70
>>
> I received another ClassNotFoundException from the
> EnvironmentClassLoader after 30 minutes, which is the default session
> timeout for most Web apps.
>
>
> On 04/04/2011 11:19 AM, Keith Fetterman wrote:
>> This problem seems to be more pervasive in Resin 4.0.16 pro. I am now
>> seeing other application classes that the Resin EnvironmentClassLoader
>> is trying to load but it can't find them. I am getting the error
>> "java.lang.ClassNotFoundException" because the
>> "EnvironmentClassLoader[resin-system:]" is trying to load it. In our
>> resin.xml file, I have the application classes being loaded at at the
>> Host level.
>>
>> Resin was started at 9:55 AM this morning. Since then, I have been
>> testing our Website including checking out, which would require
>> "com.marinersupply.common.store.struts.form.checkout.CheckoutCustomerInfoForm"
>> class to be loaded. Then at 10:37 AM, resin throws the error:
>>
>>> [11-04-04 10:37:46.336] {http://*:8082-23} WARNING
>>> com.caucho.server.session.SessionImpl
>>> com.caucho.vfs.IOExceptionWrapper: java.lang.ClassNotFoundException:
>>> com.marinersupply.common.store.struts.form.checkout.CheckoutCustomerInfoForm
>>> in EnvironmentClassLoader[resin-system:]
>> It looks like the error is occurring when resin is either serializing or
>> deserializing the session. Is the EnvironmentClassLoader above the host
>> class loader and if so, why is trying to load application classes? Is
>> this a bug in resin 4.0.16?
>>
>>
>>> [11-04-04 10:37:46.336] {http://*:8082-23} WARNING
>>> com.caucho.server.session.SessionImpl
>>> com.caucho.vfs.IOExceptionWrapper: java.lang.ClassNotFoundException:
>>> com.marinersupply.common.store.struts.form.checkout.CheckoutCustomerInfoForm
>>> in EnvironmentClassLoader[resin-system:]
>>> at
>>> com.caucho.vfs.IOExceptionWrapper.create(IOExceptionWrapper.java:64)
>>> at
>>> com.caucho.server.session.SessionImpl.load(SessionImpl.java:706)
>>> at
>>> com.caucho.server.session.SessionImpl.load(SessionImpl.java:642)
>>> at
>>> com.caucho.server.session.SessionManager.createSession(SessionManager.java:1332)
>>> at
>>> com.caucho.server.http.AbstractCauchoRequest.createSession(AbstractCauchoRequest.java:255)
>>> at
>>> com.caucho.server.http.AbstractCauchoRequest.getSession(AbstractCauchoRequest.java:198)
>>> at
>>> com.caucho.server.http.AbstractCauchoRequest.finishRequest(AbstractCauchoRequest.java:613)
>>> at
>>> com.caucho.server.http.HttpServletRequestImpl.finishRequest(HttpServletRequestImpl.java:1961)
>>> at
>>> com.caucho.server.http.AbstractHttpRequest.finishRequest(AbstractHttpRequest.java:1725)
>>> at
>>> com.caucho.server.http.HttpRequest.finishRequest(HttpRequest.java:1268)
>>> at
>>> com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:813)
>>> at
>>> com.caucho.network.listen.TcpSocketLink.dispatchRequest(TcpSocketLink.java:730)
>>> at
>>> com.caucho.network.listen.TcpSocketLink.handleRequest(TcpSocketLink.java:689)
>>> at
>>> com.caucho.network.listen.TcpSocketLink.handleRequestsImpl(TcpSocketLink.java:669)
>>> at
>>> com.caucho.network.listen.TcpSocketLink.handleRequests(TcpSocketLink.java:617)
>>> at
>>> com.caucho.network.listen.AcceptTask.doTask(AcceptTask.java:104)
>>> at
>>> com.caucho.network.listen.ConnectionReadTask.runThread(ConnectionReadTask.java:98)
>>> at
>>> com.caucho.network.listen.ConnectionReadTask.run(ConnectionReadTask.java:81)
>>> at
>>> com.caucho.network.listen.AcceptTask.run(AcceptTask.java:67)
>>> at
>>> com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:164)
>>>
Re: [Resin-interest] Environment class loader throwing a ClassNotFoundException when resin 4 is restarted
I am wondering if this problem is related to the HTTP session timing
out. In the ROOT web application, we have the session time out set to
70 minutes:
WEB-INF/web.xml
>
> 70
>
I received another ClassNotFoundException from the
EnvironmentClassLoader after 30 minutes, which is the default session
timeout for most Web apps.
On 04/04/2011 11:19 AM, Keith Fetterman wrote:
> This problem seems to be more pervasive in Resin 4.0.16 pro. I am now
> seeing other application classes that the Resin EnvironmentClassLoader
> is trying to load but it can't find them. I am getting the error
> "java.lang.ClassNotFoundException" because the
> "EnvironmentClassLoader[resin-system:]" is trying to load it. In our
> resin.xml file, I have the application classes being loaded at at the
> Host level.
>
> Resin was started at 9:55 AM this morning. Since then, I have been
> testing our Website including checking out, which would require
> "com.marinersupply.common.store.struts.form.checkout.CheckoutCustomerInfoForm"
> class to be loaded. Then at 10:37 AM, resin throws the error:
>
>> [11-04-04 10:37:46.336] {http://*:8082-23} WARNING
>> com.caucho.server.session.SessionImpl
>> com.caucho.vfs.IOExceptionWrapper: java.lang.ClassNotFoundException:
>> com.marinersupply.common.store.struts.form.checkout.CheckoutCustomerInfoForm
>> in EnvironmentClassLoader[resin-system:]
> It looks like the error is occurring when resin is either serializing or
> deserializing the session. Is the EnvironmentClassLoader above the host
> class loader and if so, why is trying to load application classes? Is
> this a bug in resin 4.0.16?
>
>
>> [11-04-04 10:37:46.336] {http://*:8082-23} WARNING
>> com.caucho.server.session.SessionImpl
>> com.caucho.vfs.IOExceptionWrapper: java.lang.ClassNotFoundException:
>> com.marinersupply.common.store.struts.form.checkout.CheckoutCustomerInfoForm
>> in EnvironmentClassLoader[resin-system:]
>> at
>> com.caucho.vfs.IOExceptionWrapper.create(IOExceptionWrapper.java:64)
>> at
>> com.caucho.server.session.SessionImpl.load(SessionImpl.java:706)
>> at
>> com.caucho.server.session.SessionImpl.load(SessionImpl.java:642)
>> at
>> com.caucho.server.session.SessionManager.createSession(SessionManager.java:1332)
>> at
>> com.caucho.server.http.AbstractCauchoRequest.createSession(AbstractCauchoRequest.java:255)
>> at
>> com.caucho.server.http.AbstractCauchoRequest.getSession(AbstractCauchoRequest.java:198)
>> at
>> com.caucho.server.http.AbstractCauchoRequest.finishRequest(AbstractCauchoRequest.java:613)
>> at
>> com.caucho.server.http.HttpServletRequestImpl.finishRequest(HttpServletRequestImpl.java:1961)
>> at
>> com.caucho.server.http.AbstractHttpRequest.finishRequest(AbstractHttpRequest.java:1725)
>> at
>> com.caucho.server.http.HttpRequest.finishRequest(HttpRequest.java:1268)
>> at
>> com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:813)
>> at
>> com.caucho.network.listen.TcpSocketLink.dispatchRequest(TcpSocketLink.java:730)
>> at
>> com.caucho.network.listen.TcpSocketLink.handleRequest(TcpSocketLink.java:689)
>> at
>> com.caucho.network.listen.TcpSocketLink.handleRequestsImpl(TcpSocketLink.java:669)
>> at
>> com.caucho.network.listen.TcpSocketLink.handleRequests(TcpSocketLink.java:617)
>> at
>> com.caucho.network.listen.AcceptTask.doTask(AcceptTask.java:104)
>> at
>> com.caucho.network.listen.ConnectionReadTask.runThread(ConnectionReadTask.java:98)
>> at
>> com.caucho.network.listen.ConnectionReadTask.run(ConnectionReadTask.java:81)
>> at
>> com.caucho.network.listen.AcceptTask.run(AcceptTask.java:67)
>> at
>> com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:164)
>> at
>> com.caucho.env.thread.ResinThread.run(ResinThread.java:130)
>> Caused by:
>> java.lang.ClassNotFoundException:
>> com.marinersupply.common.store.struts.form.checkout.CheckoutCustomerInfoForm
>> in EnvironmentClassLoader[resin-system:]
>>
Re: [Resin-interest] Environment class loader throwing a ClassNotFoundException when resin 4 is restarted
This problem seems to be more pervasive in Resin 4.0.16 pro. I am now
seeing other application classes that the Resin EnvironmentClassLoader
is trying to load but it can't find them. I am getting the error
"java.lang.ClassNotFoundException" because the
"EnvironmentClassLoader[resin-system:]" is trying to load it. In our
resin.xml file, I have the application classes being loaded at at the
Host level.
Resin was started at 9:55 AM this morning. Since then, I have been
testing our Website including checking out, which would require
"com.marinersupply.common.store.struts.form.checkout.CheckoutCustomerInfoForm"
class to be loaded. Then at 10:37 AM, resin throws the error:
> [11-04-04 10:37:46.336] {http://*:8082-23} WARNING
> com.caucho.server.session.SessionImpl
> com.caucho.vfs.IOExceptionWrapper: java.lang.ClassNotFoundException:
> com.marinersupply.common.store.struts.form.checkout.CheckoutCustomerInfoForm
> in EnvironmentClassLoader[resin-system:]
It looks like the error is occurring when resin is either serializing or
deserializing the session. Is the EnvironmentClassLoader above the host
class loader and if so, why is trying to load application classes? Is
this a bug in resin 4.0.16?
> [11-04-04 10:37:46.336] {http://*:8082-23} WARNING
> com.caucho.server.session.SessionImpl
> com.caucho.vfs.IOExceptionWrapper: java.lang.ClassNotFoundException:
> com.marinersupply.common.store.struts.form.checkout.CheckoutCustomerInfoForm
> in EnvironmentClassLoader[resin-system:]
>at
> com.caucho.vfs.IOExceptionWrapper.create(IOExceptionWrapper.java:64)
>at
> com.caucho.server.session.SessionImpl.load(SessionImpl.java:706)
>at
> com.caucho.server.session.SessionImpl.load(SessionImpl.java:642)
>at
> com.caucho.server.session.SessionManager.createSession(SessionManager.java:1332)
>at
> com.caucho.server.http.AbstractCauchoRequest.createSession(AbstractCauchoRequest.java:255)
>at
> com.caucho.server.http.AbstractCauchoRequest.getSession(AbstractCauchoRequest.java:198)
>at
> com.caucho.server.http.AbstractCauchoRequest.finishRequest(AbstractCauchoRequest.java:613)
>at
> com.caucho.server.http.HttpServletRequestImpl.finishRequest(HttpServletRequestImpl.java:1961)
>at
> com.caucho.server.http.AbstractHttpRequest.finishRequest(AbstractHttpRequest.java:1725)
>at
> com.caucho.server.http.HttpRequest.finishRequest(HttpRequest.java:1268)
>at
> com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:813)
>at
> com.caucho.network.listen.TcpSocketLink.dispatchRequest(TcpSocketLink.java:730)
>at
> com.caucho.network.listen.TcpSocketLink.handleRequest(TcpSocketLink.java:689)
>at
> com.caucho.network.listen.TcpSocketLink.handleRequestsImpl(TcpSocketLink.java:669)
>at
> com.caucho.network.listen.TcpSocketLink.handleRequests(TcpSocketLink.java:617)
>at
> com.caucho.network.listen.AcceptTask.doTask(AcceptTask.java:104)
>at
> com.caucho.network.listen.ConnectionReadTask.runThread(ConnectionReadTask.java:98)
>at
> com.caucho.network.listen.ConnectionReadTask.run(ConnectionReadTask.java:81)
>at
> com.caucho.network.listen.AcceptTask.run(AcceptTask.java:67)
>at
> com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:164)
>at
> com.caucho.env.thread.ResinThread.run(ResinThread.java:130)
>Caused by:
> java.lang.ClassNotFoundException:
> com.marinersupply.common.store.struts.form.checkout.CheckoutCustomerInfoForm
> in EnvironmentClassLoader[resin-system:]
>at
> com.caucho.loader.DynamicClassLoader.loadClass(DynamicClassLoader.java:1382)
>at
> com.caucho.loader.DynamicClassLoader.loadClass(DynamicClassLoader.java:1358)
>at
> java.lang.Class.forName0(Native Method)
>at
> java.lang.Class.forName(Class.java:247)
>
Re: [Resin-interest] Multiple instances of the same webapp after redeploy in 4.0.16 (strange!!!)
On 04/04/2011 10:02 AM, Mattias Jiderhamn wrote: > Scott Ferguson wrote (2011-04-04 18:47): >> On 04/04/2011 12:43 AM, Mattias Jiderhamn wrote: >>> While evaluating Resin 4.0.16 we are seeing something that makes me >>> really concerned. It appears as if after a redeploy there can be two >>> instances of our main app running. >>> >>> I was made aware of this by noticing that timed servlets (>> ... />) were having concurrency issues and logging the same event >>> twice within the same second. >>> This made me add some extra logging in a servlet, >>> and I can actually see that at some reploys, the same web app is >>> initialized twice - in different, concurrent threads and different >>> classloaders. >>> For example one instance may be initialized by >>> Thread[http://*:8080-776,5,main] and at the same time (give or take >>> a few seconds) another one by Thread[resin-366,5,main]. >>> >>> I cannot deliberately recreate it by simply redeploying (which makes >>> it less likely to be a configuration issue). But it happens about >>> daily on our test server; possibly issuing requests on a session in >>> the app while redeploying is a factor. >>> >>> We are not using versioning. >>> dependency-check-interval is set to 20 seconds. >>> The "extra" app does not appear in the admin console. >>> >>> How can we figure out what is going on here??? >>> >> >> Are you using version="true" and/or versioned web-apps? With >> versioned web-apps, Resin is supposed to have two versions running at >> the same time while it migrates sessions from the old version to the >> new version. > > As stated above, we are not using versioning. Thanks. I'd missed that. > (And if we we're, should the old version be re-initialized when > deploying a new version...?) No. Only the latest version should ever be initialized. Even if you were to restart Resin completely with multiple versions, only the latest version should be initialized. I've filed this as http://bugs.caucho.com/view.php?id=4474. -- Scott ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Multiple instances of the same webapp after redeploy in 4.0.16 (strange!!!)
Scott Ferguson wrote (2011-04-04 18:47): > On 04/04/2011 12:43 AM, Mattias Jiderhamn wrote: >> While evaluating Resin 4.0.16 we are seeing something that makes me >> really concerned. It appears as if after a redeploy there can be two >> instances of our main app running. >> >> I was made aware of this by noticing that timed servlets (> />) were having concurrency issues and logging the same event twice >> within the same second. >> This made me add some extra logging in a servlet, >> and I can actually see that at some reploys, the same web app is >> initialized twice - in different, concurrent threads and different >> classloaders. >> For example one instance may be initialized by >> Thread[http://*:8080-776,5,main] and at the same time (give or take a >> few seconds) another one by Thread[resin-366,5,main]. >> >> I cannot deliberately recreate it by simply redeploying (which makes >> it less likely to be a configuration issue). But it happens about >> daily on our test server; possibly issuing requests on a session in >> the app while redeploying is a factor. >> >> We are not using versioning. >> dependency-check-interval is set to 20 seconds. >> The "extra" app does not appear in the admin console. >> >> How can we figure out what is going on here??? >> > > Are you using version="true" and/or versioned web-apps? With versioned > web-apps, Resin is supposed to have two versions running at the same > time while it migrates sessions from the old version to the new version. As stated above, we are not using versioning. (And if we we're, should the old version be re-initialized when deploying a new version...?) -- ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Multiple instances of the same webapp after redeploy in 4.0.16 (strange!!!)
On 04/04/2011 12:43 AM, Mattias Jiderhamn wrote: > While evaluating Resin 4.0.16 we are seeing something that makes me > really concerned. It appears as if after a redeploy there can be two > instances of our main app running. > > I was made aware of this by noticing that timed servlets ( />) were having concurrency issues and logging the same event twice > within the same second. > This made me add some extra logging in a servlet, > and I can actually see that at some reploys, the same web app is > initialized twice - in different, concurrent threads and different > classloaders. > For example one instance may be initialized by > Thread[http://*:8080-776,5,main] and at the same time (give or take a > few seconds) another one by Thread[resin-366,5,main]. > > I cannot deliberately recreate it by simply redeploying (which makes > it less likely to be a configuration issue). But it happens about > daily on our test server; possibly issuing requests on a session in > the app while redeploying is a factor. > > We are not using versioning. > dependency-check-interval is set to 20 seconds. > The "extra" app does not appear in the admin console. > > How can we figure out what is going on here??? > Are you using version="true" and/or versioned web-apps? With versioned web-apps, Resin is supposed to have two versions running at the same time while it migrates sessions from the old version to the new version. -- Scott ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Multiple instances of the same webapp after redeploy in 4.0.16 (strange!!!)
While evaluating Resin 4.0.16 we are seeing something that makes me really concerned. It appears as if after a redeploy there can be two instances of our main app running. I was made aware of this by noticing that timed servlets () were having concurrency issues and logging the same event twice within the same second. This made me add some extra logging in a servlet, and I can actually see that at some reploys, the same web app is initialized twice - in different, concurrent threads and different classloaders. For example one instance may be initialized by Thread[http://*:8080-776,5,main] and at the same time (give or take a few seconds) another one by Thread[resin-366,5,main]. I cannot deliberately recreate it by simply redeploying (which makes it less likely to be a configuration issue). But it happens about daily on our test server; possibly issuing requests on a session in the app while redeploying is a factor. We are not using versioning. dependency-check-interval is set to 20 seconds. The "extra" app does not appear in the admin console. How can we figure out what is going on here??? -- ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
