This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1275403 - [GSS](6.4.z) Http11NioProtocol error with SSL and multipart requests
[GSS](6.4.z) Http11NioProtocol error with SSL and multipart requests
Status: CLOSED CURRENTRELEASE
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Web (Show other bugs)
6.4.2
x86_64 Linux
medium Severity high
: CR1
: EAP 6.4.11
Assigned To: baranowb
Radim Hatlapatka
: Reopened
Depends On:
Blocks: 1316573 eap6411-payload
  Show dependency treegraph
 
Reported: 2015-10-26 15:52 EDT by Vítor Corrêa
Modified: 2017-01-17 08:12 EST (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-01-17 08:12:39 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
test project (12.60 KB, application/zip)
2015-11-05 06:30 EST, Vítor Corrêa
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2427381 None None None 2016-07-06 08:56 EDT

  None (edit)
Description Vítor Corrêa 2015-10-26 15:52:52 EDT
Description of problem:

Multipart Request upload component fail with ssl connector and Http11NioProtocol protocol

Version-Release number of selected component (if applicable):
6.4.2 

How reproducible:

i'm working on the bits and will upload the sample to reproduce it.

Steps to Reproduce:

Steps to Reproduce:
1. Start EAP and set NIO2 connector ( /subsystem=web/connector=http:write-attribute(name=protocol, value=org.apache.coyote.http11.Http11NioProtocol) and reload)

2. Deploy ws.war . Access localhost:8080/ws 
 

3. Upload a file


Actual results:

org.apache.commons.fileupload.FileUploadException
Caused by: java.io.EOFException: JBWEB002011: Socket read failed
		 at org.apache.coyote.http11.InternalNioInputBuffer.fill0(InternalNioInputBuffer.java:538) [jbossweb-7.5.9.Final-redhat-1.jar:7.5.9.Final-redhat-1]
		 at org.apache.coyote.http11.InternalNioInputBuffer.access$200(InternalNioInputBuffer.java:51) [jbossweb-7.5.9.Final-redhat-1.jar:7.5.9.Final-redhat-1]
		 at org.apache.coyote.http11.InternalNioInputBuffer$InputBufferImpl.doRead(InternalNioInputBuffer.java:573) [jbossweb-7.5.9.Final-redhat-1.jar:7.5.9.Final-redhat-1]
		 at org.apache.coyote.http11.filters.IdentityInputFilter.doRead(IdentityInputFilter.java:116) [jbossweb-7.5.9.Final-redhat-1.jar:7.5.9.Final-redhat-1]
		 at org.apache.coyote.http11.InternalNioInputBuffer.doRead(InternalNioInputBuffer.java:459) [jbossweb-7.5.9.Final-redhat-1.jar:7.5.9.Final-redhat-1]
		 at org.apache.coyote.Request.doRead(Request.java:438) [jbossweb-7.5.9.Final-redhat-1.jar:7.5.9.Final-redhat-1]
		 at org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:361) [jbossweb-7.5.9.Final-redhat-1.jar:7.5.9.Final-redhat-1]
		 ... 83 more


Expected results:

successful upload.

Additional info:
Comment 10 Radim Hatlapatka 2015-11-04 05:04:13 EST
I was trying to reproduce the issue and only thing I was able to hit is the BUFFER_OVERFLOW issue described in https://bugzilla.redhat.com/show_bug.cgi?id=1266247.

I tried to reproduce this with both simple file upload via jsp + servlet and via websockets. The only issue, I am hitting is BUFFER_OVERFLOW issue described in https://bugzilla.redhat.com/show_bug.cgi?id=1266247.

The upload failure I am getting with EAP 6.4.4. With EAP 6.4.5.CP.CR1 it works as the BUFFER_OVERFLOW issue is fixed.

Note, I am NOT getting the exception mentioned in description. I am doing the uploads over https/wss using NIO2 connector.

Could you please confirm whether those two issues are the same or provide the web application promised in description showing the different error.
Comment 13 Vítor Corrêa 2015-11-05 06:30 EST
Created attachment 1090028 [details]
test project
Comment 15 Radim Hatlapatka 2015-11-09 10:13:59 EST
Yes, I am able to reproduce it, the exception was from servlet error output and not in server logs, that is reason why I haven't been able to confirm it at  first that this is actually the same issue as BZ#1266247. No I have confirmed that this is actually duplicate of it, thereby closing as duplicate.

*** This bug has been marked as a duplicate of bug 1266247 ***
Comment 21 Justin Pittman 2016-08-10 17:42:58 EDT
We still had a large file upload fail against Vitor's attached test app project (ws.war) despite hot patching to CP# 5.  We also tried CP# 6 & 7.  After hot patching to CP#9, the file uploaded without exception.  The exception thrown was still EOFException: JBWEB002011: Socket read failed.

We did not try the reproducer war from the original Bug https://bugzilla.redhat.com/show_bug.cgi?id=1266247
Comment 23 Masafumi Miura 2016-08-22 23:11 EDT
Created attachment 1193120 [details]
BZ1275403-proposed-patch.diff
Comment 25 Radim Hatlapatka 2016-08-29 10:44:29 EDT
Justin, I tried reproducing the issue and I was able to hit it, unfortunately not reliably as Coty is, even though I have also modified the latency on my loopback interface and tried it remotely from another computer in the same network.

Either way it seems it is not duplicate in the end.
Comment 37 Peter Mackay 2016-10-04 05:25:39 EDT
Verified with EAP 6.4.11.CP.CR1
Comment 38 Petr Penicka 2017-01-17 08:12:39 EST
Retroactively bulk-closing issues from released EAP 6.4 cummulative patches.

Note You need to log in before you can comment on or make changes to this bug.