Another day of troubleshooting, more information:

- We wrote a JSP that takes form data and displays it (simple text field,
POSTing to a JSP).  I can upload huge amounts without the same problem.  The
upload even exceeds the 1365 AJP packets that the file upload has been
limited to.

Questions:
1. The file upload uses "multipart/form-data" for the encoding type, the
text form does not.  Multipart/form-data is used by the O'Reilly servlet to
handle uploading binary.  Anyone have any specific knowlege on this
encoding?
2. Has anyone else run into problems uploading large binary files?
3. Is anyone out there getting these messages ;) ?  Frustration is running
rampant here.
4. Is there anymore information I can provide that would help troubleshoot
this?  Can anyone think of a different series of actions to identify the
root cause of this problem?


Thanks,
john


-----Original Message-----
From: John Roth [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 10, 2002 10:31 AM
To: 'Tomcat Users List'
Subject: REPOST: XXX Assert failed, buff too small -- Help!!


I am *still* troubleshooting this issue, and am in dire need of help.  Is
anyone out there uploading large files via SSL/HTTPS?

New discoveries:
1. Added some debugging code to Ajp13.class to output buff, length, etc.,
results are as follows:
   JR: Array: buff(from)=[B@7f92f5, pos(fromIndex)=6, dest(to)=[B@9505f,
0(toIndex), length(count)=8186
   JR: Buff: length=8186, Buff: 8192

   ... repeats for all 1364 correct AJP packets, then ...

   JR: Array: buff(from)=[B@7f92f5, pos(fromIndex)=6, dest(to)=[B@9505f,
0(toIndex), length(count)=8186
   JR: Buff: length=65311, Buff: 8192
   XXX Assert failed, buff too small: length=65311, Buff: 8192
   JR: Array: buff(from)=[B@7f92f5, pos(fromIndex)=6, dest(to)=[B@9505f,
0(toIndex), length(count)=65311
   ... then the AIOOB exception in the application log.
2. Have upgraded Tomcat from 4.0.1 to 4.0.3
3. Have upgraded to yet the latest ISAPI_REDIRECT(or).dll
4. Have explored all IIS registry settings without being able to change the
results at all.
5. Tried other servlets besides O'Reilly with the same result (not
surprising, the error occurs in AJP or isapi_redirect - still can't narrow
down chain of events).
6. ASP pages used for upload do not have this problem (albeit they are
considerably slower).

Desparately looking for help or advice!!

Thanks,
John Roth, Director net.Media
Provider Solutions Corp.

-----Original Message-----
From: John Roth [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 03, 2002 3:40 PM
To: Tomcat User Group (E-mail)
Subject: RE: XXX Assert failed, buff too small


After two weeks, I am still troubleshooting the same problem uploading files
via https where the filesize is greater than 10.7MB.  I am not having much
luck determining the order in which to problem flows, but the following
things are happening:

1. stdout.log records "XXX Assert failed, buff too small" after which
ajp13Packet.class exceptions with AIOOBE.
2. isapi_redirect gets a ReadClient failed, followed shortly by
ServerSupportFunction failed.
3. IIS sends a reset flag to the client.
4. Socket timeout as client acks the reset flag.

I am not able to determine the chain of events, ie: IIS reset/Client
reset->ReadClient fails->AIOOBE or AIOOBE->ReadClient fails->IIS
reset/Client reset.
We are using the O'Reilly multipart upload servlet, and it has been upgraded
to the latest version.  The same thing happens when testing with other JSP
based solutions (such as JSPSmartUpload) but not with ASP-based uploads.

The next series of questions is this:
1. I noticed that 4.0.3 includes a significantly changed ajp connector.  Had
anyone been using is successfully or know if the changes address this issue?
2. Any ideas on how to more closely determine to order of the described
order of events? Some of the logs reports milliseconds, most don't, so I
can't seem to absolutely determine the order of events.
3. I have adjusted several TCP parameters in the Windows registry, but
nothing seems to change the fact that the error always occurs on the 1365th
AJP packet.  None of the buffers within isapi_redirect.dll appear to
correlate to this number.  Anyone familiar with the inner workings of
isapi_redirect (dated feb 14, 2002)?

Any desperately needed help would be appreciated.

Thanks,
john


-----Original Message-----
From: John Roth [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 20, 2002 4:39 PM
To: Tomcat User Group (E-mail)
Subject: XXX Assert failed, buff too small


We are having a problem with Tomcat using an upload servlet to upload
potentially large files (up to 100MB).  The servlet works fine for all file
sizes in the following instances:
http://servername/app/UploadFiles.jsp
http://servername:8080/app/UploadFiles.jsp
but when using https (ie: https://servername/app/UploadFiles.jsp, we get
'Page Cannot Be Displayed'.  A summary of the error logs is below:

IIS_Redirect.Log
----------------
 [Wed Mar 20 15:49:20 2002]  [jk_ajp13_worker.c (206)]: sending to ajp13
#8192
 [Wed Mar 20 15:49:20 2002]  [jk_ajp13_worker.c (258)]: received from ajp13
#3
 [Wed Mar 20 15:49:20 2002]  [jk_isapi_plugin.c (426)]: Into
jk_ws_service_t::read
 [Wed Mar 20 15:49:20 2002]  [jk_isapi_plugin.c (426)]: Into
jk_ws_service_t::read

 ... this repeats 1364 times, everytime, before the following: ...

 [Wed Mar 20 15:49:20 2002]  [jk_ajp13_worker.c (206)]: sending to ajp13
#8192
 [Wed Mar 20 15:49:20 2002]  [jk_ajp13_worker.c (258)]: received from ajp13
#3
 [Wed Mar 20 15:49:20 2002]  [jk_isapi_plugin.c (426)]: Into
jk_ws_service_t::read
 [Wed Mar 20 15:49:20 2002]  [jk_isapi_plugin.c (426)]: Into
jk_ws_service_t::read
 [Wed Mar 20 15:49:20 2002]  [jk_isapi_plugin.c (460)]:
jk_ws_service_t::read, ReadClient failed

stdout.log
----------
 Starting service Tomcat-Standalone-(Staging)
 Apache Tomcat/4.0.1
 [Ajp13] bad read: -103
 XXX Assert failed, buff too small

Note: Yes, I have been following the list, and I don't know what causes -103
either, but with the exception of this servlet, our app has been running
great for months, with several dozen -103's a day.  The XXX Assert Failed is
new.

tomcat_log.log
--------------
2002-03-20 15:34:02 UploadFiles: init
2002-03-20 15:34:15 jsp: init
2002-03-20 15:34:15 Ajp13Processor[8009][6] process: invoke
java.net.SocketException: Connection aborted by peer: socket write error
        at java.net.SocketOutputStream.socketWrite(Native Method)
        at java.net.SocketOutputStream.write(SocketOutputStream.java:83)
        at org.apache.ajp.Ajp13.send(Ajp13.java:959)
        at org.apache.ajp.Ajp13.finish(Ajp13.java:808)
        at
org.apache.ajp.tomcat4.Ajp13Response.finishResponse(Ajp13Response.java:192)
        at org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:373)
        at org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:424)
        at java.lang.Thread.run(Thread.java:484)

Application Log
---------------
2002-03-20 15:34:03,253 [Ajp13Processor[8009][6]] DEBUG
com.psc.ams.servlets.PSCUploadFilesByExtension - clearing dir
e:/****/staging\jroth
2002-03-20 15:34:03,253 [Ajp13Processor[8009][6]] DEBUG
com.psc.ams.servlets.PSCUploadFilesByExtension - attempting to delete file
e:\****\staging\jroth\11MB.txt
2002-03-20 15:34:15,190 [Ajp13Processor[8009][6]] ERROR
com.psc.ams.servlets.PSCUploadFilesByExtension - Unexpected Exception
occured in PSCUploadFiles.doPost().
java.lang.ArrayIndexOutOfBoundsException
        at java.lang.System.arraycopy(Native Method)
        at org.apache.ajp.Ajp13Packet.getBytes(Ajp13Packet.java:459)
        at org.apache.ajp.Ajp13.refillReadBuffer(Ajp13.java:641)
        at org.apache.ajp.Ajp13.doRead(Ajp13.java:540)
        at org.apache.ajp.tomcat4.Ajp13InputStream.read(Ajp13InputStream.java:95)
        at javax.servlet.ServletInputStream.readLine(ServletInputStream.java:138)
        at
com.oreilly.servlet.MultipartInputStreamHandler.readLine(MultipartInputStrea
mHandler.java:63)
        at
com.oreilly.servlet.MultipartRequest.readAndSaveFile(MultipartRequest.java:4
21)
        at
com.oreilly.servlet.MultipartRequest.readNextPart(MultipartRequest.java:522)
        at
com.oreilly.servlet.MultipartRequest.readRequest(MultipartRequest.java:610)
        at com.oreilly.servlet.MultipartRequest.<init>(MultipartRequest.java:146)
        at
com.psc.ams.servlets.PSCUploadFilesByExtension.doPost(PSCUploadFilesByExtens
ion.java:480)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
        at
org.apache.catalina.servlets.InvokerServlet.serveRequest(InvokerServlet.java
:446)
        at
org.apache.catalina.servlets.InvokerServlet.doPost(InvokerServlet.java:216)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
        at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:247)
        at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:193)
        at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va:243)
        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
        at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
        at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
        at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
va:201)
        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
        at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
        at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
        at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2344)
        at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164
)
        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
        at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.
java:170)
        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
64)
        at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170
)
        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
64)
        at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:462)
        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
64)
        at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
        at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
        at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
:163)
        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
        at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
        at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
        at org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:371)
        at org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:424)
        at java.lang.Thread.run(Thread.java:484)

Environment:
------------
- Win2000 Server, patched up to latest levels
- Tomcat 4.0.1 Binary distribution, running as a service
- IIS 5.0, using ISAPI_Redirect.dll dated 12/08/01 (Thank you Henri Gomez!)
- SSL Enabled through IIS
- I have several servers with similar environments.  Some servers have
multiple logical web servers with multiple Tomcat instances.  This
particular server has only one instance of each.  However, the same behavior
is observed on any server/instance with SSL.

Facts:
------
1] This only happens on https://, all other forms work fine.
2] This only happens on files larger than just under 11MB (11,172,378 bytes,
plus or minus a few bytes for filename payload).
3] The "Assert Failed" error comes from Ajp13.java, Ajp13Packet.java, or
MsgAjp.java.  I am not a Java programmer (yes, another one of those
'systems' guys), but was able to dig throught the source to find the actual
system.out lines.
4] 11,172,378 / 1364 = 8191+-, the same size as the ajp packet.  Why 1364
ajp packets?  Anything smaller works fine.
5] Any help will result in the helper receiving a free drink from the helpee
next time the helper is in Tampa, FL!

Thanks in advance,
John Roth, Director net.Media
Provider Solutions Corp.


--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>


--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>


--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

Reply via email to