RE: Coyote:: ArrayIndexOutOfBoundsException
You can see the fix in CVS - it was just a case of moving a few lines of code within the commit() method. Thanks to Remy for that! Neil. -- Neil MilneHippo IT Consultants Ltd -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tomcat 4.1.12 ArrayIndexOutOfBoundsException in InternalOutputBuffer.write()
Hi I'm seeing an occasional ArrayIndexOutOfBoundsException in the org.apache.coyote.http11.InternalOutputBuffer write method. It appears that the buffer holding the response headers (which has a default size of 32000 bytes) is occasionally overflowing. I can't reliably repeat this so I'm not sure under what circumstances it occurs - I have to hammer the site for a while to get it to repeat! I added some logging to the code to see what the buf byte array had in it just as it was about to overflow and it appears to have multiple responses of the form: HTTP/1.1 200 OK Content-Type: text/html;charset=ISO-8859-1 Cache-Control: no-cache, post-check=0, pre-check=0 Pragma: no-cache Expires: Thu, 01 Dec 1994 16:00:00 GMT Transfer-Encoding: chunked Date: Thu, 21 Nov 2002 12:02:39 GMT Server: Apache Coyote/1.0 Transfer-Encoding: chunked Date: Thu, 21 Nov 2002 12:02:39 GMT Server: Apache Coyote/1.0 Transfer-Encoding: chunked Date: Thu, 21 Nov 2002 12:02:39 GMT Server: Apache Coyote/1.0 Transfer-Encoding: chunked Date: Thu, 21 Nov 2002 12:02:39 GMT Server: Apache Coyote/1.0 with an arbitrary number of repeats of the last three lines. I'm not sure why the buffer would have more than one response in it, and I'm not sure why the transfer encoding, date and server lines are repeated so often. Any ideas? Since I've only just started looking at the source I'm not really familiar enough with the flow of the code to know if this is expected behaviour. I guess a short term fix would be to resize buf as required rather than just assuming it has the capacity, but it would be nice to know why so much stuff ends up in the array sometimes! Any ideas? Neil -- Neil MilneHippo IT Consultants Ltd -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Connection pooling doesn't work for me ... Help !!
I'm using the JNDI Datasource setup fine with Tomcat 4.0.3 and Sybase. In server.xml I have: Resource name=jdbc/db auth=Container type=javax.sql.ConnectionPoolDataSource/ ResourceParams name=jdbc/db parameter namedriverClassName/name valuecom.sybase.jdbc2.jdbc.SybDriver/value /parameter parameter nameuser/name valueuser/value/parameter !-- other driver specific db params... -- parameter nameinitialPoolSize/name value5/value/parameter /ResourceParams There's no need to specify a factory as Tomcat has a Datasource resource factory built in. Note that I've used the ConnectionPoolDataSource class - not sure if this makes a difference. HTH Neil. - Original Message - from: Martin Jacobson [EMAIL PROTECTED] date: Thursday, June 13, 2002 1:40 pm subject: Re: Connection pooling doesn't work for me ... Help !! anthony.dodd wrote: Hi I've posted a solution see Generic DataSource Resource Factory Available. JDBC Data Source on the tomcat user maillist. Tony Yes, but... Like many others on this list, I too have been unable to get the std JNDI DataSource thingy working; as an interim measure, I implemented a workaround (which does at least work!), but I refuse to be defeated! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Connection pooling doesn't work for me ... Help !!
Nikola Milutinovic wrote: Note that I've used the ConnectionPoolDataSource class - not sure if this makes a difference. Well, yes and no. The actual class should be CPDS, but your application shouldn't specifically ask for it, but for DataSource. The container will use CPDS and cast it to DS for your use. Yes, I'm not using that class in my code, I'm just using DataSource. I was referring to the setup in server.xml. Neil -- Neil Milne Hippo IT Consultants Ltd -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Problem with load-on-startup and jsp pages
Hi I'm running Tomcat 4.0.3 in standalone mode and I can't get a JSP page to load on startup. I've put together a test webapp which has one servlet and one jsp page both set to load on startup via the webapp web.xml file and only the servlet is started when the webapp is loaded. Here's the web.xml: web-app display-nameTest area/display-name servlet servlet-namesvstart/servlet-name servlet-classStartup/servlet-class load-on-startup1/load-on-startup /servlet servlet servlet-namejsstart/servlet-name jsp-file/index.jsp/jsp-file load-on-startup2/load-on-startup /servlet /web-app In the tomcat log for this webapp I can see the following: 2002-06-12 08:00:18 StandardWrapper[:default]: Loading container servlet default 2002-06-12 08:00:18 default: init 2002-06-12 08:00:18 StandardWrapper[:invoker]: Loading container servlet invoker 2002-06-12 08:00:18 invoker: init 2002-06-12 08:00:18 invoker: init: Associated with Context '' 2002-06-12 08:00:18 jsstart: init 2002-06-12 08:00:18 jsp: init 2002-06-12 08:00:18 StandardContext[]: Starting completed Which implies that the jsp init method was run, but it hasn't been since there is no output to stdout from the jspInit method until I actually visit the jsp page via a browser. Meanwhile, the servlet (class Startup above) has run its init method fine and produced stdout output ok, even though it's not mentioned in the webapp log. Is this a known problem? I've looked in the source code for the superclass for the JSP pages and jspInit should be called from the init method so that seems to imply that the init method hasn't been called either for the compiled servlet. I also can't see the compiled servlet code in the $CATALINA_HOME/work directory until I access the jsp via a browser. I've tried varying the startup order, and only having jsp in the startup without any luck. Any help appreciated! Thanks, Neil. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
