JRun errors in split environment
Hey guys,
I think I have emailed back and forth with a couple of you on the topic of
the requestContext methods in Jato 1.1 to see whether or not they can be
giving us some of the problems we are having in our testing environment. In
development we are running on local boxes and using JRun 3.0 as a webserver
and the back-end app server. We have had no problems with navigation,
multiple login, or session info, etc..
Now is testing we have Iplanet 4.0 as we webserver (on one machine) and the
JRun services running on another machine. Now I know Todd Fast has
commented on some of the exceptions we were getting in our BofaDirect
application and said they were a JRun configuration issue. But I guess my
suggestion runs a little bit deeper and my question lies in this situation.
We can create an "ArrayIndexOutofBounds" problem sometimes....but we solved
for the time being. The exceptions we get now is seen like this whenever
one is navigating around pages:
And no it does not only happen in one place or another. It has happened in
different projects and at different times in the session. Here is one
example...
An unhandled exception occured - Handler method "handleBtEnterRequest" threw
an\
unknown exception
Exception within exception. Response has already been committed
JRun Session ID from Request Manager = 151014980781102286
Total request time = 528 ms
Now we can make this happen at any point where we navigate quickly from page
to page. There is rarely any CORBA involved in loading these pages and you
can break JRun just by moving around , single login.
So can it be? The com.iplanet.jato.view.RequestHandlingViewBase.java .
Now the only reason as to why I ask this is because if a child is trying to
be instantiated, and the page is trying to load java code from JATO into
JRun to be process in one request ....and the Iplanet server (which is
separate entirely) keeps on queuing requests to the JRun server/JATO. So is
it possible that the webserver is causing the JATO package to overload
children instantiation when a user screams through pages quickly?
Eric Hagopian
Bank of America Direct
<a href="/group/SunONE-JATO/post?protectID=070212020098035125169242065176231253000 098083009039175188023077067046010218229239098201196026">eric.hagopian@b...< ;/a>
312.974.6411
[2591 byte] By [
Guest] at [2007-11-25 9:28:28]
Eric et al.--
> An unhandled exception occured - Handler method "handleBtEnterRequest"
threw
> an\
> unknown exception
> Exception within exception. Response has already been committed
> JRun Session ID from Request Manager = 151014980781102286
> Total request time = 528 ms
The critical information in this message is this:
> Exception within exception. Response has already been committed
This normally happens if someone does two forwards in one request, or tries
to forward late in the rendering of a page (due to a insufficient buffer
size). We've also seen this in some containers under error conditions--the
container is buggy such that if it tries to write an exception message to
the output stream it generates this same error. Therefore, I don't know if
we can take this message as the primary error; it may be a secondary error.
What doesn't make sense at all is that this error only occurs under load.
My only guess is that the log might help clear this up. If that's the same
log you'd sent earlier, then my reading is that it's a JRun-ism (I didn't
mean to sound dismissive in my prior email). Could it perhaps be that JRun
is constantly reloading classes (for some unknown reason) and thus cannot
keep up under the test load? One way to test this would be to put some
System.out messages in the static initializer of your view bean classes and
see if they appear more than once in the log/console. Perhaps you could
also try a test run with a different container like Resin
(<a href="http://www.caucho.com">http://www.caucho.com</a>) and see if you get the same results.
Just for kicks, and to rule it out as a potential problem, you might also
want to set a larger buffer size on the pages that seem to have a problem
(are they large pages?):
<%@ page buffer=60kb %>
Another thing to try would be to surround the code in your
"handleBtEnterRequest" method with a try...catch (Throwable) and log any
exception in detail yourself (make sure to rethrow it). Are all the errors
you receive occurring inside event handler methods? For example, some
containers may have a problem doing something like appending our app message
buffer to the bottom of the outgoing page (which is why it can be
unilaterally turned off).
> Now we can make this happen at any point where we navigate quickly from
page
> to page. There is rarely any CORBA involved in loading these pages and
you
> can break JRun just by moving around , single login.
> So can it be? The com.iplanet.jato.view.RequestHandlingViewBase.java .
> Now the only reason as to why I ask this is because if a child is trying
to
> be instantiated, and the page is trying to load java code from JATO into
> JRun to be process in one request ....and the Iplanet server (which is
> separate entirely) keeps on queuing requests to the JRun server/JATO. So
is
> it possible that the webserver is causing the JATO package to overload
> children instantiation when a user screams through pages quickly?
Under normal circumstances, there shouldn't be any class loading except
during the first-touch request. If something like the scenario you've
indicated is occurring then the container is definitely not operating in a
way we would expect for a deployment configuration.
Also, child instantiation is extremely cheap, so it shouldn't cause any
problems whatsoever; and besides, each request is (should be) isolated in
its own thread, and everythig inside that thread is happening synchronously
without outside influence or interaction. There is no central interaction
for, say, child instantiation. In the end, each request thread has its own
copy of all the objects it needs and there is no way that requests could
"back up" against any JATO object. The only exception might be under the
abnormal class loading situation I mentioned above.
My best recommendation right now would be to either test in a different
container or comb the logs to try to find some other error that could be
causing the message you see as a secondary error.
Todd
--
Todd Fast
Senior Engineer
Sun/Netscape Alliance
<a href="/group/SunONE-JATO/post?protectID=189233080150035131169232031248130090006 048031198039130252055210">todd.fast@e...</a>
Guest at 2007-7-1 16:33:59 >
