briefly before (I think on a BZ issue) but needs a
wider discussion before taking action - if we do anything.
It has been suggested that there isn't much benefit to maintaining the
NIO2 connector and that we could simplify maintenance by removing it
(deprecating in 11.0.x, removing in 12.0.x)
Mark Thomas wrote:
> >>> All,
> >>>
> >>> This was mentioned briefly before (I think on a BZ issue) but needs a
> >>> wider discussion before taking action - if we do anything.
> >>>
> >>> It has been suggested that there isn'
.
It has been suggested that there isn't much benefit to maintaining the
NIO2 connector and that we could simplify maintenance by removing it
(deprecating in 11.0.x, removing in 12.0.x). The current code structure
would be retained should there ever be an NIO3 or similar that we wanted
to add.
NI
.
> >
> > It has been suggested that there isn't much benefit to maintaining the
> > NIO2 connector and that we could simplify maintenance by removing it
> > (deprecating in 11.0.x, removing in 12.0.x). The current code structure
> > would be retained should ther
Mark,
On 5/13/25 11:20 AM, Mark Thomas wrote:
All,
This was mentioned briefly before (I think on a BZ issue) but needs a
wider discussion before taking action - if we do anything.
It has been suggested that there isn't much benefit to maintaining the
NIO2 connector and that we
On Tue, May 13, 2025 at 5:22 PM Mark Thomas wrote:
>
> All,
>
> This was mentioned briefly before (I think on a BZ issue) but needs a
> wider discussion before taking action - if we do anything.
>
> It has been suggested that there isn't much benefit to maintaining the
On 2025/05/13 15:20:48 Mark Thomas wrote:
> All,
>
> This was mentioned briefly before (I think on a BZ issue) but needs a
> wider discussion before taking action - if we do anything.
>
> It has been suggested that there isn't much benefit to maintaining the
> NIO2 c
All,
This was mentioned briefly before (I think on a BZ issue) but needs a
wider discussion before taking action - if we do anything.
It has been suggested that there isn't much benefit to maintaining the
NIO2 connector and that we could simplify maintenance by removing it
(deprecati
https://bz.apache.org/bugzilla/show_bug.cgi?id=63765
Remy Maucherat changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bz.apache.org/bugzilla/show_bug.cgi?id=63765
--- Comment #7 from Remy Maucherat ---
(In reply to Rainer Jung from comment #6)
> Can't say whether it is safe though.
It likely sounds safe to unwrap first (it would do an underflow and cause a
read) reading some previous comment:
https://gi
https://bz.apache.org/bugzilla/show_bug.cgi?id=63765
--- Comment #6 from Rainer Jung ---
(In reply to Remy Maucherat from comment #1)
> This looked like the usual not-unwrapping-enough "IO" issue, so changing the
> initial value of unwrapBeforeRead to true in SecureNio2Channel.reset avoids
> it.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63765
--- Comment #5 from Rainer Jung ---
And here Nio2 using TLS 1.2:
...
24-Sep-2019 15:16:55.232 FINE [https-openssl-nio2-8443-exec-4]
org.apache.tomcat.util.net.SocketWrapperBase.populateReadBuffer Socket:
[org.apache.tomcat.util.net.Nio2Endpoin
https://bz.apache.org/bugzilla/show_bug.cgi?id=63765
--- Comment #4 from Rainer Jung ---
For comparison the Nio (not NIO2) log snippet where the request works:
24-Sep-2019 13:54:40.068 FINE [https-openssl-nio-8443-Acceptor]
org.apache.tomcat.util.threads.LimitLatch.countUpOrAwait Counting
up[htt
https://bz.apache.org/bugzilla/show_bug.cgi?id=63765
--- Comment #3 from Rainer Jung ---
I can also reproduce on SLES 12 and RHEL 7 but not on Solaris.
For me it does not happen with a real remote connection, but always with local
ones and with connections from another virtual guest on the same
https://bz.apache.org/bugzilla/show_bug.cgi?id=63765
--- Comment #2 from Coty Sutherland ---
> I cannot reproduce this that reliably personally, it may be only visible on
> localhost.
Weird. I can reproduce this between two machines as well, so it doesn't seem to
be a lo only issue.
--
You ar
https://bz.apache.org/bugzilla/show_bug.cgi?id=63765
--- Comment #1 from Remy Maucherat ---
This looked like the usual not-unwrapping-enough "IO" issue, so changing the
initial value of unwrapBeforeRead to true in SecureNio2Channel.reset avoids it.
Not sure if it is 100% safe (although it looks r
https://bz.apache.org/bugzilla/show_bug.cgi?id=63765
Bug ID: 63765
Summary: NIO2 Connector with OpenSSL 1.1.1 hangs with TLSv1.3
Product: Tomcat 9
Version: 9.0.x
Hardware: PC
OS: Linux
Status: NEW
https://bz.apache.org/bugzilla/show_bug.cgi?id=63182
Remy Maucherat changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bz.apache.org/bugzilla/show_bug.cgi?id=63182
--- Comment #6 from Remy Maucherat ---
The bugzilla is properly entered, you don't need to ping about it or update it
anymore.
That being said, the pattern used is at best inefficient, unlike writes where
it can have uses.
--
You are receivi
. |returns true, when NIO2
||connector being used and
||the read operation
||performed outside the
https://bz.apache.org/bugzilla/show_bug.cgi?id=61751
--- Comment #19 from Markus Dörschmidt ---
Thank you very much. The bug is fixed!
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe,
https://bz.apache.org/bugzilla/show_bug.cgi?id=61751
Mark Thomas changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://bz.apache.org/bugzilla/show_bug.cgi?id=61751
Mark Thomas changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://bz.apache.org/bugzilla/show_bug.cgi?id=61751
--- Comment #16 from Remy Maucherat ---
I added a follow up: http://svn.apache.org/viewvc?rev=1824201&view=rev
As this didn't happen with the regular JSSE engine, I think the missing
underflow status is the root cause (the unwrap loops in Secu
https://bz.apache.org/bugzilla/show_bug.cgi?id=61751
--- Comment #15 from Remy Maucherat ---
On second thought, this will need to be revisited as the blocking read of
SecureNio2Channel is supposed to block until it returns non 0. Of course, the
algorithm is complex already ...
I will add a TODO c
https://bz.apache.org/bugzilla/show_bug.cgi?id=61751
--- Comment #14 from Remy Maucherat ---
Great job on that fix ! :)
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-uns
https://bz.apache.org/bugzilla/show_bug.cgi?id=61751
Mark Thomas changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://bz.apache.org/bugzilla/show_bug.cgi?id=61751
--- Comment #12 from Mark Thomas ---
I've found the root cause. A blocking read obtained bytes from the network but
after unwrapping there were zero application bytes. Since this is a blocking
read, more network bytes should be read and unwrapp
https://bz.apache.org/bugzilla/show_bug.cgi?id=61751
--- Comment #11 from Mark Thomas ---
Thanks for the additional information. I can now reproduce this (thanks to
Microsoft for the free azure credits).
I have two clean Tomcat 9.0.x builds. One locally, one on Azure. Key config is
HTTPS / OpenS
.
I got the bug in an environment with these conditions:
1. Server and client have to be in different networks with a gateway between
2. Tomcat needs NIO2 connector handling HTTPs
When I send an XML file to "/xml" of my example application using CURL, I get
an server-side error about a
https://bz.apache.org/bugzilla/show_bug.cgi?id=61751
Remy Maucherat changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Resolution|---
https://bz.apache.org/bugzilla/show_bug.cgi?id=61831
--- Comment #4 from Remy Maucherat ---
Ok, maybe. Let us know if you find some elements demonstrating an issue in
Tomcat.
--
You are receiving this mail because:
You are the assignee for the bug.
--
https://bz.apache.org/bugzilla/show_bug.cgi?id=61831
Piotr changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Resolution|---
https://bz.apache.org/bugzilla/show_bug.cgi?id=61831
Remy Maucherat changed:
What|Removed |Added
Status|REOPENED|NEEDINFO
--
You are receiving this m
https://bz.apache.org/bugzilla/show_bug.cgi?id=61831
Oleg changed:
What|Removed |Added
Resolution|WORKSFORME |---
Status|RESOLVED
https://bz.apache.org/bugzilla/show_bug.cgi?id=61831
Remy Maucherat changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bz.apache.org/bugzilla/show_bug.cgi?id=61831
Oleg changed:
What|Removed |Added
CC||yaol...@gmail.com
--
You are receiving this ma
https://bz.apache.org/bugzilla/show_bug.cgi?id=61831
Bug ID: 61831
Summary: NIO2 connector becomes intermittently unresponsive
after some period of time
Product: Tomcat 8
Version: 8.0.47
Hardware: All
OS
https://bz.apache.org/bugzilla/show_bug.cgi?id=61751
--- Comment #8 from Mark Thomas ---
I can't reproduce this problem with the given test case either. I've tested:
- NIO2
- 8.5.x trunk
- http and https
- https with OpenSSL (Tomcat native 1.2.16, OpenSSL ubuntu latest)
- https with JSSE
- Java 1
https://bz.apache.org/bugzilla/show_bug.cgi?id=61751
--- Comment #7 from Remy Maucherat ---
As I said, I tried the same connector with your test upload, it worked for me.
This issue is not very well presented IMO, for instance it seems to imply it is
a NIO2 + OpenSSL issue only, but in the end t
https://bz.apache.org/bugzilla/show_bug.cgi?id=61751
--- Comment #6 from Markus Dörschmidt ---
The real web application uses Spring Webservices 2.4.0.
The SOAP request contains a base64-encoded binary element.
The SOAP request never reaches the Webservice framework, because parsing the
XML docu
https://bz.apache.org/bugzilla/show_bug.cgi?id=61751
--- Comment #5 from Remy Maucherat ---
This works for me.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@
https://bz.apache.org/bugzilla/show_bug.cgi?id=61751
--- Comment #4 from Markus Dörschmidt ---
I attached a simple web application to reproduce the code.
Try sending XML data to application using curl:
curl -X POST -k --header "Content-Type: text/xml;charset=UTF-8" --data
@"test.xml"
After ca
https://bz.apache.org/bugzilla/show_bug.cgi?id=61751
--- Comment #3 from Markus Dörschmidt ---
Created attachment 35539
--> https://bz.apache.org/bugzilla/attachment.cgi?id=35539&action=edit
Minimal code to reproduce bug
--
You are receiving this mail because:
You are the assignee for the bug
https://bz.apache.org/bugzilla/show_bug.cgi?id=61751
Mark Thomas changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #2 from Mark Thomas
https://bz.apache.org/bugzilla/show_bug.cgi?id=61751
--- Comment #1 from Remy Maucherat ---
Do you think you could give some pointers on reproduction ?
In the past there was BZ57799 which was caused by an unexpected interaction
with use of available() by the framework.
--
You are receiving this
https://bz.apache.org/bugzilla/show_bug.cgi?id=61751
Bug ID: 61751
Summary: NIO2 connector cuts incoming request
Product: Tomcat 8
Version: 8.5.16
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
https://bz.apache.org/bugzilla/show_bug.cgi?id=60014
Remy Maucherat changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Resolution|---
https://bz.apache.org/bugzilla/show_bug.cgi?id=60014
--- Comment #5 from Andrea Vettori ---
I must add an information that may be important. The server where I did the
testing and the production server are both CentOS7 linux installation with
OpenSSL version 'OpenSSL 1.0.1e-fips 11 Feb 2013'.
To
https://bz.apache.org/bugzilla/show_bug.cgi?id=60014
--- Comment #4 from Andrea Vettori ---
Ok so I attached a test case. It's a simple Servlet that prints the request
body and a stripped down version of my form that calls the servlet.
With Apr connector I get the full string of (encoded) parame
https://bz.apache.org/bugzilla/show_bug.cgi?id=60014
--- Comment #2 from Andrea Vettori ---
Created attachment 34163
--> https://bz.apache.org/bugzilla/attachment.cgi?id=34163&action=edit
Test Case Sources
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60014
--- Comment #3 from Andrea Vettori ---
Created attachment 34164
--> https://bz.apache.org/bugzilla/attachment.cgi?id=34164&action=edit
Test Case War
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60014
Mark Thomas changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #1 from Mark Thomas
https://bz.apache.org/bugzilla/show_bug.cgi?id=60014
Christopher Schultz changed:
What|Removed |Added
Summary|Nio2 Connector with SLL |NIO2 Connector with SSL
https://bz.apache.org/bugzilla/show_bug.cgi?id=60014
Bug ID: 60014
Summary: Nio2 Connector with SLL (OpenSSL) truncates post data
Product: Tomcat 8
Version: 8.5.4
Hardware: PC
OS: Linux
Status: NEW
https://bz.apache.org/bugzilla/show_bug.cgi?id=59650
--- Comment #8 from Remy Maucherat ---
That's a useful clarification actually, the standard executor is not an
ExecutorService, there's another thread pool in there that is an
ExecutorService. It is likely I'll adjust the connector startup logg
https://bz.apache.org/bugzilla/show_bug.cgi?id=59650
--- Comment #7 from Ravi Sanwal ---
I partly understand what you said. AND as I mentioned in my previous comment
about the workaround, there is a way out.
Your statement, however, about the tomcat standard executor being an
ExecutorService (for
https://bz.apache.org/bugzilla/show_bug.cgi?id=59650
--- Comment #6 from Remy Maucherat ---
So you're saying effectively that the NIO2 connector would be better off if it
used *two* separate executors: one ExecutorService internally (NIO2 needs one),
and an external executor. And most proce
https://bz.apache.org/bugzilla/show_bug.cgi?id=59650
--- Comment #5 from Ravi Sanwal ---
Typo in previous comment.
It should be.
We should at lease fix the connector documentation for this behavior and
explain that it is better to not use an external executor *but* an internal one
specific to th
https://bz.apache.org/bugzilla/show_bug.cgi?id=59650
--- Comment #4 from Ravi Sanwal ---
Can it at least give the user some control put a cap on the number of threads?
May be I am not explaining my problem correctly.
Regardless.
Tomcat NIO2 connector still doesn't follow the rules of a de
|--- |WONTFIX
Status|REOPENED|RESOLVED
--- Comment #3 from Remy Maucherat ---
The NIO2 connector only works with an ExecutorService that is exclusive to this
connector. A side effect of the design really.
--
You are receiving this mail because
eated (with the provided thread pool) and eventually it
ends up using the default case. Which is an unbounded thread pool.
In addition to this undesired behavior, for NIO2 connector, these threads (the
ones to process async IO) are reused as-is to process new requests. If we have
configured an exe
|--- |INVALID
OS||All
--- Comment #1 from Remy Maucherat ---
The NIO2 connector wraps the executor as the thread group, this executor should
respect the thread count limits, etc.
// Create worker collection
if
https://bz.apache.org/bugzilla/show_bug.cgi?id=59650
Bug ID: 59650
Summary: NIO2 connector does not respect executor bounds,
reuses NIO.2 threads for processing request on
connections
Product: Tomcat 8
Version
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
Remy Maucherat changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
--- Comment #35 from Justin ---
(In reply to Remy Maucherat from comment #34)
> Created attachment 33247 [details]
> Test patch
>
> With debug.
Excellent, this patch has resolved the problem. I tested both HTTP and HTTPS. I
see no exceptions
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
Remy Maucherat changed:
What|Removed |Added
Attachment #33243|0 |1
is obsolete|
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
Remy Maucherat changed:
What|Removed |Added
Status|NEEDINFO|NEW
--- Comment #33 from Remy Maucher
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
Justin changed:
What|Removed |Added
Attachment #33241|0 |1
is obsolete|
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
Remy Maucherat changed:
What|Removed |Added
Attachment #33234|0 |1
is obsolete|
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
--- Comment #30 from Justin ---
Created attachment 33242
--> https://bz.apache.org/bugzilla/attachment.cgi?id=33242&action=edit
stderr for /trunk@1711734 with debug code
Previous attachment was catalina.out. stdout has only:
> Read pending
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
--- Comment #29 from Remy Maucherat ---
The debug info is not there however.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-ma
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
Justin changed:
What|Removed |Added
Attachment #32830|0 |1
is obsolete|
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
--- Comment #27 from Justin ---
Created attachment 33240
--> https://bz.apache.org/bugzilla/attachment.cgi?id=33240&action=edit
Client exceptions for /trunk@1711734
Thanks for the patch! I exported, applied, built, ran.
--
You are receivin
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
--- Comment #26 from Remy Maucherat ---
Created attachment 33234
--> https://bz.apache.org/bugzilla/attachment.cgi?id=33234&action=edit
Debug code
If the exception does not occur, the code can be added to SecureNio2Channel.
--
You are rece
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
--- Comment #25 from Remy Maucherat ---
When I say in the channel read, I mean here for the debug code:
org.apache.tomcat.util.net.Nio2Channel.read(Nio2Channel.java:133)
--
You are receiving this mail because:
You are the assignee for the bu
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
--- Comment #24 from Remy Maucherat ---
Hum, it's not trunk, it's branch 8 head. Anyway, the SSL thing was just
coincidental, never mind.
It would be nice in the channel read to capture the previous stack trace (throw
and catch an exception, p
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
--- Comment #23 from Justin ---
(In reply to Remy Maucherat from comment #21)
> This could use another trunk retest.
Built, ran /trunk@1711357. Client now throws exception connected to non-SSL
port too...
2015-10-29 16:44:58,287 exception [T
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
--- Comment #22 from Remy Maucherat ---
Investigating another issue, it seems possible this one is caused by a timeout
exception that gets swallowed, followed by a new read attempt. It is not really
a Tomcat bug if the theory is correct.
In tr
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
--- Comment #21 from Remy Maucherat ---
This could use another trunk retest.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-ma
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
Yilong Li changed:
What|Removed |Added
CC||yilong.li@runtimeverificati
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
--- Comment #20 from Mark Thomas ---
(In reply to Robert M from comment #19)
> We are running into this same issue in our application and I just started to
> debug the problem. The one additional piece of information I can add is that
> I only
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
--- Comment #19 from Robert M ---
We are running into this same issue in our application and I just started to
debug the problem. The one additional piece of information I can add is that I
only get this error when I have SSL enabled in the con
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
--- Comment #18 from Justin ---
> Without a test case this is going to sit in the NEEDINFO state.
Understandable. Regardless of whether there is a test case, there is a bug
causing exceptions in Tomcat 8 latest. I may not be the only one who c
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
--- Comment #17 from Mark Thomas ---
(In reply to Remy Maucherat from comment #16)
> Without a relatively simple test case, I think this should be closed for the
> time being. There has to be some concurrency involved and the framework
> really
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
--- Comment #16 from Remy Maucherat ---
Without a relatively simple test case, I think this should be closed for the
time being. There has to be some concurrency involved and the framework really
gets in the way.
--
You are receiving this mai
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
--- Comment #15 from Justin ---
Retested and reconfirmed problem with /trunk@1685924. Attached exceptions.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
--- Comment #14 from Justin ---
Created attachment 32830
--> https://bz.apache.org/bugzilla/attachment.cgi?id=32830&action=edit
Exceptions
--
You are receiving this mail because:
You are the assignee for the bug.
--
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
--- Comment #13 from Mark Thomas ---
Any update now 8.0.23 is released? Still waiting on a test case or steps to
reproduce.
--
You are receiving this mail because:
You are the assignee for the bug.
---
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
--- Comment #12 from Remy Maucherat ---
Since there's no test case, it is worth retesting again [with trunk] since the
previous fix caused a regression.
--
You are receiving this mail because:
You are the assignee for the bug.
--
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
--- Comment #11 from Justin ---
(In reply to Remy Maucherat from comment #9)
> Also, testing on Tomcat trunk may not be useless.
Same errors with Tomcat 8.0.21. When I build/run /trunk@1675728, I get:
23-Apr-2015 17:55:46.105 INFO [http-nio2-
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
Mark Thomas changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #10 from Mark Thoma
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
--- Comment #9 from Remy Maucherat ---
Also, testing on Tomcat trunk may not be useless.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsub
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
--- Comment #8 from Remy Maucherat ---
So the pending flag seems correct. The difference with non SSL is thus
unexplained, and this needs a (simple) testcase.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
--- Comment #7 from Justin ---
(In reply to Remy Maucherat from comment #6)
> Unrelated (but useful) fixes merged in Tomcat 8 as r1672626.
I exported from ^/trunk@1672808, removed both "throw ReadPendingException" from
SecureNio2Channel, built
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
--- Comment #3 from Remy Maucherat ---
As part of the investigation I fixed some issues (r1672297) which will be
backported to Tomcat 8, but I don't see any way for the read pending flag to
have a bad state. Without some test, the issue will ev
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
--- Comment #2 from Justin ---
There are no such problems when dropping SSL.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-ma
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
Remy Maucherat changed:
What|Removed |Added
OS||All
--- Comment #1 from Remy Mauchera
https://bz.apache.org/bugzilla/show_bug.cgi?id=57799
Bug ID: 57799
Summary: MessageCreationException: Couldn't create SOAP message
with Nio2 connector protocol
Product: Tomcat 8
Version: 8.0.15
Hardwar
Hi,
With some fixes in, I think the status is now better than what the
"welcome" message says, which is: The NIO2 connector is currently
EXPERIMENTAL and should not be used in production
In preparation for the next build, I would like to update it to: The NIO2
connector is currentl
100 matches
Mail list logo
