tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <r...@apache.org>
Subject Re: Large File Transfer : Coyote Connector Crash [isHexDigit]
Date Wed, 26 Jun 2002 08:07:29 GMT
Craig R. McClanahan wrote:
> 
> On Tue, 25 Jun 2002, Jacob Hookom wrote:
> 
> 
>>Date: Tue, 25 Jun 2002 16:02:48 -0500
>>From: Jacob Hookom <hookomjj@uwec.edu>
>>Reply-To: Tomcat Users List <tomcat-user@jakarta.apache.org>
>>To: Tomcat Users List <tomcat-user@jakarta.apache.org>
>>Subject: RE: Large File Transfer : Coyote Connector Crash [isHexDigit]
>>
>>Remy Maucherat wrote:
>>
>>>Are you actualy using a POST with a URL FORM encoding ? In which case,
>>
>>>sorry, but it's a really bad idea to do that."
>>
>>Are there alternatives?  The goal of this process is to ease image
>>transfer to a publishing server by people who haven't a clue on how to
>>utilize ftp, or their mail servers do not permit large file attachments.
>>
>>My implementation is the same as the upload example included with the
>>struts-upload.war.  File transfers of 141MB will crash the VM at 114MB
>>for example.  So the file is reaching the server and midway through
>>'storing it', but crashes the VM midway through.
>>
> 
> 
> I hope you're not configuring things to load the entire incoming file into
> memory before saving it.  That's obviously going to cause you memory
> problems if you don't have enough heap space allocated in your JVM.
> 
> 
>>The only thing I notice is that the Coyote connector throws
>>java.io.CharConversionException: isHexDigit
>>
> 
> 
> As Remy suggests, it's almost impossible to do much debugging without
> seeing the stack trace.

Here's the stack trace:
java.io.CharConversionException: isHexDigit
	at
org.apache.tomcat.util.buf.UDecoder.convert(UDecoder.java:124)
	at org.apache.tomcat.util.buf.UDecoder.convert(UDecoder.java:87)
	at
org.apache.tomcat.util.http.Parameters.processParameters(Parameters.java
:408)
	at
org.apache.coyote.tomcat4.CoyoteRequest.parseRequestParameters(CoyoteReq
uest.java:1944)
	at
org.apache.coyote.tomcat4.CoyoteRequest.getParameterNames(CoyoteRequest.
java:942)
	at
org.apache.coyote.tomcat4.CoyoteRequest.getParameterMap(CoyoteRequest.ja
va:922)
	at
org.apache.coyote.tomcat4.CoyoteRequestFacade.getParameterMap(CoyoteRequ
estFacade.java:193)
	at
org.apache.catalina.core.ApplicationHttpRequest.setRequest(ApplicationHt
tpRequest.java:526)
	at
org.apache.catalina.core.ApplicationHttpRequest.<init>(ApplicationHttpRe
quest.java:126)
	at
org.apache.catalina.core.ApplicationDispatcher.wrapRequest(ApplicationDi
spatcher.java:918)
	at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDisp
atcher.java:414)
	at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispat
cher.java:355)
	at
org.apache.catalina.valves.ErrorDispatcherValve.custom(ErrorDispatcherVa
lve.java:391)
	at
org.apache.catalina.valves.ErrorDispatcherValve.status(ErrorDispatcherVa
lve.java:305)
	at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherVa
lve.java:180)
	at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:564)
	at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
:170)
	at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:564)
	at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468
)

That would seem to indicate that you're getting to an error page. Going 
there triggers the parameters parsing, and so it causes trouble.

Remy


--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message