Writing inline..

Niels Bo wrote:
We are not doing any stress load. Just a few normal users and there is
absolutly no load on the server. Besides this problem everything works.
I can also see the problem late in the evening, when I am the only user on the server.

I know, but stressing the server usually makes it a little more obvious to see where there could be trouble. If there are problems, sometimes it takes time for them to build up. And you might get the problems a times where it should be no problem..
We are not using filters but the WicketServlets and they are defined like
normal:

    <servlet>
        <servlet-name>PubApplicationServlet</servlet-name>
<servlet-class>org.apache.wicket.protocol.http.WicketServlet</servlet-class>
        <init-param>
            <param-name>applicationClassName</param-name>
            <param-value>oet.applications.pub.PubApplication</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>

    <servlet-mapping>
        <servlet-name>PubApplicationServlet</servlet-name>
        <url-pattern>/pub/*</url-pattern>
    </servlet-mapping>

and the other application in the same way, with just different application
class and url pattern.
Ahh okay.

Niels

Nino.Martinez wrote:
I guess you have tried using something like Jmeter to simulate a stressing environment? It could be a lot of stuff that clutters it up, like database acesss etc...

How does your filter mapping look like?

-regards Nino

Niels Bo wrote:
Hi

We have two WicketServlets/Applications in the same web application(war)
and
that
has worked fine until we deployed on the big production server (Weblogic
10).

What we see now is that the homepage from application A is sometime
showing
up
as response to request on urls that belong to the application B!
It is not a redirection. It is really the response that does not match
the
url requested,
and we have it logged and documented with "Fiddler".

It looks just as if Application A is "stuck" to a worker thread (in its
ThreadLocal current), but looking at the wicket source we cant see how
that
should happen.
This right now happens for maybe 10% of the requests on the production
server, while have only been able to recreate it once a day on a
development
server, so that makes it difficult to debug.

Any suggestions where and how to look for the error?
Is there a place where we can add an extra check to catch if the
Application
is stuck on a worker thread?

Niels
--
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to