You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by ma...@apache.org on 2019/06/06 20:46:31 UTC

[tomcat] branch master updated (dcf96d8 -> e967bbc)

This is an automated email from the ASF dual-hosted git repository.

markt pushed a change to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git.


    from dcf96d8  Decoupling the socket from the wrapper effectively achieves the task
     new ab1581d  Correct placeholder
     new e967bbc  Remove a source of potential deadlocks

The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 .../apache/coyote/http2/Http2AsyncUpgradeHandler.java   | 17 +++++++----------
 .../org/apache/tomcat/websocket/LocalStrings.properties |  2 +-
 webapps/docs/changelog.xml                              |  9 +++++++++
 3 files changed, 17 insertions(+), 11 deletions(-)


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Re: [tomcat] 02/02: Remove a source of potential deadlocks

Posted by Mark Thomas <ma...@apache.org>.
On 07/06/2019 10:51, Rémy Maucherat wrote:
> On Fri, Jun 7, 2019 at 11:00 AM Mark Thomas <markt@apache.org
> <ma...@apache.org>> wrote:
> 
>     On 06/06/2019 22:51, Mark Thomas wrote:
> 
>     <snip/>
> 
>     > I haven't quite tracked down the other deadlock yet. The timing gap is
>     > narrower so it is harder to capture. I have some ideas to work on
>     tomorrow.
> 
>     This is the stack trace:
> 
>     Essentially, something should call notify on the NioOperationState
>     instance but it never happens. I'm still trying to figure out the root
>     cause.
> 
> 
> This emulates a blocking write, so either there's really a problem
> notifying or it is that the client is no longer reading and the wait
> will eventually timeout. The state update seems properly synced and the
> notify is called when the operation is considered complete, this looks
> ok to me.

The only potential issue I found didn't seem to have any impact although
I've fixed it anyway.

The client might stop reading due to header corruption as a result of
the bug I re-introduced with the first deadlock fix. I have a
alternative fix that I'll commit shortly and then re-test.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Re: [tomcat] 02/02: Remove a source of potential deadlocks

Posted by Rémy Maucherat <re...@apache.org>.
On Fri, Jun 7, 2019 at 11:00 AM Mark Thomas <ma...@apache.org> wrote:

> On 06/06/2019 22:51, Mark Thomas wrote:
>
> <snip/>
>
> > I haven't quite tracked down the other deadlock yet. The timing gap is
> > narrower so it is harder to capture. I have some ideas to work on
> tomorrow.
>
> This is the stack trace:
>
> Essentially, something should call notify on the NioOperationState
> instance but it never happens. I'm still trying to figure out the root
> cause.
>

This emulates a blocking write, so either there's really a problem
notifying or it is that the client is no longer reading and the wait will
eventually timeout. The state update seems properly synced and the notify
is called when the operation is considered complete, this looks ok to me.

Rémy


>
> Mark
>
>
> "https-jsse-nio-8443-exec-9" #38 daemon prio=5 os_prio=0 cpu=21.95ms
> elapsed=469.80s tid=0x00007f7f3ca34000 nid=0x1306e in Object.wait()
> [0x00007f7ee568f000]
>    java.lang.Thread.State: TIMED_WAITING (on object monitor)
>         at java.lang.Object.wait(java.base@11.0.3/Native Method)
>         - waiting on <0x00000000c748f130> (a
> org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper$NioOperationState)
>         at
> org.apache.tomcat.util.net
> .SocketWrapperBase.vectoredOperation(SocketWrapperBase.java:1482)
>         - waiting to re-lock in wait() <0x00000000c748f130> (a
> org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper$NioOperationState)
>         at
> org.apache.tomcat.util.net
> .SocketWrapperBase.write(SocketWrapperBase.java:1403)
>         at
> org.apache.tomcat.util.net
> .SocketWrapperBase.write(SocketWrapperBase.java:1374)
>         at
>
> org.apache.coyote.http2.Http2AsyncUpgradeHandler.writeBody(Http2AsyncUpgradeHandler.java:214)
>         at
> org.apache.coyote.http2.Stream$StreamOutputBuffer.flush(Stream.java:949)
>         - locked <0x00000000c75d36a8> (a
> org.apache.coyote.http2.Stream$StreamOutputBuffer)
>         at
> org.apache.coyote.http2.Stream$StreamOutputBuffer.doWrite(Stream.java:859)
>         - locked <0x00000000c75d36a8> (a
> org.apache.coyote.http2.Stream$StreamOutputBuffer)
>         at
>
> org.apache.coyote.http2.Http2OutputBuffer.doWrite(Http2OutputBuffer.java:59)
>         at org.apache.coyote.Response.doWrite(Response.java:599)
>         at
>
> org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:329)
>         at
>
> org.apache.catalina.connector.OutputBuffer.appendByteArray(OutputBuffer.java:736)
>         at
> org.apache.catalina.connector.OutputBuffer.append(OutputBuffer.java:665)
>         at
>
> org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:376)
>         at
> org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:354)
>         at
>
> org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:96)
>         at
>
> org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:89)
>         at
>
> org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:1118)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

Re: [tomcat] 02/02: Remove a source of potential deadlocks

Posted by Mark Thomas <ma...@apache.org>.
On 06/06/2019 22:51, Mark Thomas wrote:

<snip/>

> I haven't quite tracked down the other deadlock yet. The timing gap is
> narrower so it is harder to capture. I have some ideas to work on tomorrow.

This is the stack trace:

Essentially, something should call notify on the NioOperationState
instance but it never happens. I'm still trying to figure out the root
cause.

Mark


"https-jsse-nio-8443-exec-9" #38 daemon prio=5 os_prio=0 cpu=21.95ms
elapsed=469.80s tid=0x00007f7f3ca34000 nid=0x1306e in Object.wait()
[0x00007f7ee568f000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
        at java.lang.Object.wait(java.base@11.0.3/Native Method)
        - waiting on <0x00000000c748f130> (a
org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper$NioOperationState)
        at
org.apache.tomcat.util.net.SocketWrapperBase.vectoredOperation(SocketWrapperBase.java:1482)
        - waiting to re-lock in wait() <0x00000000c748f130> (a
org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper$NioOperationState)
        at
org.apache.tomcat.util.net.SocketWrapperBase.write(SocketWrapperBase.java:1403)
        at
org.apache.tomcat.util.net.SocketWrapperBase.write(SocketWrapperBase.java:1374)
        at
org.apache.coyote.http2.Http2AsyncUpgradeHandler.writeBody(Http2AsyncUpgradeHandler.java:214)
        at
org.apache.coyote.http2.Stream$StreamOutputBuffer.flush(Stream.java:949)
        - locked <0x00000000c75d36a8> (a
org.apache.coyote.http2.Stream$StreamOutputBuffer)
        at
org.apache.coyote.http2.Stream$StreamOutputBuffer.doWrite(Stream.java:859)
        - locked <0x00000000c75d36a8> (a
org.apache.coyote.http2.Stream$StreamOutputBuffer)
        at
org.apache.coyote.http2.Http2OutputBuffer.doWrite(Http2OutputBuffer.java:59)
        at org.apache.coyote.Response.doWrite(Response.java:599)
        at
org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:329)
        at
org.apache.catalina.connector.OutputBuffer.appendByteArray(OutputBuffer.java:736)
        at
org.apache.catalina.connector.OutputBuffer.append(OutputBuffer.java:665)
        at
org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:376)
        at
org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:354)
        at
org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:96)
        at
org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:89)
        at
org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:1118)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Re: [tomcat] 02/02: Remove a source of potential deadlocks

Posted by Mark Thomas <ma...@apache.org>.
On 06/06/2019 22:19, Rémy Maucherat wrote:
> On Thu, Jun 6, 2019 at 10:46 PM <markt@apache.org
> <ma...@apache.org>> wrote:
> 
>     This is an automated email from the ASF dual-hosted git repository.
> 
>     markt pushed a commit to branch master
>     in repository https://gitbox.apache.org/repos/asf/tomcat.git
> 
>     commit e967bbc7f106f8ec5384a294d98d5cbc44b474f1
>     Author: Mark Thomas <markt@apache.org <ma...@apache.org>>
>     AuthorDate: Thu Jun 6 21:45:30 2019 +0100
> 
>         Remove a source of potential deadlocks
> 
>         SocketWrapperBase.vectoredOperation acquires the (read|write)
>     Semaphore
>         and then locks the SocketWrapper during completion before the
>     Semaphore
>         is release. If the SocketWrapper is locked on some, but not all,
>     paths
>         before acquiring the Semaphore, a deadlock becomes possible.
> 
>         Fixed by removing the initial lock on SocketWrapper since the
>     Semaphores
>         make it unnecessary.
> 
> 
> I wished it worked, as this sync lowers performance a lot, but
> unfortunately it doesn't. The lock ensures that HPACK behaves and that
> everything gets written in order, more or less.
> Details and test is in https://bz.apache.org/bugzilla/show_bug.cgi?id=61740
> It fails again after removing the sync.

Thanks for the pointer.

This needs some more thought since with the sync you get deadlocks.

I haven't quite tracked down the other deadlock yet. The timing gap is
narrower so it is harder to capture. I have some ideas to work on tomorrow.

I think it would be useful to ID the other deadlock before thinking too
hard about how to solve the problem above as it may introduce additional
complications.

Mark


> 
> Rémy
>  
> 
>     ---
>      .../apache/coyote/http2/Http2AsyncUpgradeHandler.java   | 17
>     +++++++----------
>      webapps/docs/changelog.xml                              |  9 +++++++++
>      2 files changed, 16 insertions(+), 10 deletions(-)
> 
>     diff --git
>     a/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
>     b/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
>     index 969bfda..8a57c53 100644
>     --- a/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
>     +++ b/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
>     @@ -169,16 +169,13 @@ public class Http2AsyncUpgradeHandler extends
>     Http2UpgradeHandler {
>          @Override
>          void writeHeaders(Stream stream, int pushedStreamId,
>     MimeHeaders mimeHeaders,
>                  boolean endOfStream, int payloadSize) throws IOException {
>     -        // This ensures the Stream processing thread has control of
>     the socket.
>     -        synchronized (socketWrapper) {
>     -            AsyncHeaderFrameBuffers headerFrameBuffers =
>     (AsyncHeaderFrameBuffers)
>     -                    doWriteHeaders(stream, pushedStreamId,
>     mimeHeaders, endOfStream, payloadSize);
>     -            if (headerFrameBuffers != null) {
>     -                socketWrapper.write(BlockingMode.SEMI_BLOCK,
>     protocol.getWriteTimeout(),
>     -                        TimeUnit.MILLISECONDS, null,
>     SocketWrapperBase.COMPLETE_WRITE,
>     -                        applicationErrorCompletion,
>     headerFrameBuffers.bufs.toArray(BYTEBUFFER_ARRAY));
>     -                handleAsyncException();
>     -            }
>     +        AsyncHeaderFrameBuffers headerFrameBuffers =
>     (AsyncHeaderFrameBuffers)
>     +                doWriteHeaders(stream, pushedStreamId, mimeHeaders,
>     endOfStream, payloadSize);
>     +        if (headerFrameBuffers != null) {
>     +            socketWrapper.write(BlockingMode.SEMI_BLOCK,
>     protocol.getWriteTimeout(),
>     +                    TimeUnit.MILLISECONDS, null,
>     SocketWrapperBase.COMPLETE_WRITE,
>     +                    applicationErrorCompletion,
>     headerFrameBuffers.bufs.toArray(BYTEBUFFER_ARRAY));
>     +            handleAsyncException();
>              }
>              if (endOfStream) {
>                  stream.sentEndOfStream();
>     diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
>     index 7f55e3d..d65a1f3 100644
>     --- a/webapps/docs/changelog.xml
>     +++ b/webapps/docs/changelog.xml
>     @@ -45,6 +45,15 @@
>        issues do not "pop up" wrt. others).
>      -->
>      <section name="Tomcat 9.0.22 (markt)" rtext="in development">
>     +  <subsection name="Coyote">
>     +    <changelog>
>     +      <fix>
>     +        Remove a source of potential deadlocks when using HTTP/2
>     when the
>     +        Connector is configured with <code>useAsyncIO</code> as
>     +        <code>true</code>. (markt)
>     +      </fix>
>     +    </changelog>
>     +  </subsection>
>      </section>
>      <section name="Tomcat 9.0.21 (markt)" rtext="release in progress">
>        <subsection name="Catalina">
> 
> 
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>     <ma...@tomcat.apache.org>
>     For additional commands, e-mail: dev-help@tomcat.apache.org
>     <ma...@tomcat.apache.org>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Re: [tomcat] 02/02: Remove a source of potential deadlocks

Posted by Rémy Maucherat <re...@apache.org>.
On Thu, Jun 6, 2019 at 10:46 PM <ma...@apache.org> wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> markt pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
>
> commit e967bbc7f106f8ec5384a294d98d5cbc44b474f1
> Author: Mark Thomas <ma...@apache.org>
> AuthorDate: Thu Jun 6 21:45:30 2019 +0100
>
>     Remove a source of potential deadlocks
>
>     SocketWrapperBase.vectoredOperation acquires the (read|write) Semaphore
>     and then locks the SocketWrapper during completion before the Semaphore
>     is release. If the SocketWrapper is locked on some, but not all, paths
>     before acquiring the Semaphore, a deadlock becomes possible.
>
>     Fixed by removing the initial lock on SocketWrapper since the
> Semaphores
>     make it unnecessary.
>

I wished it worked, as this sync lowers performance a lot, but
unfortunately it doesn't. The lock ensures that HPACK behaves and that
everything gets written in order, more or less.
Details and test is in https://bz.apache.org/bugzilla/show_bug.cgi?id=61740
It fails again after removing the sync.

Rémy


> ---
>  .../apache/coyote/http2/Http2AsyncUpgradeHandler.java   | 17
> +++++++----------
>  webapps/docs/changelog.xml                              |  9 +++++++++
>  2 files changed, 16 insertions(+), 10 deletions(-)
>
> diff --git a/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
> b/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
> index 969bfda..8a57c53 100644
> --- a/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
> +++ b/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
> @@ -169,16 +169,13 @@ public class Http2AsyncUpgradeHandler extends
> Http2UpgradeHandler {
>      @Override
>      void writeHeaders(Stream stream, int pushedStreamId, MimeHeaders
> mimeHeaders,
>              boolean endOfStream, int payloadSize) throws IOException {
> -        // This ensures the Stream processing thread has control of the
> socket.
> -        synchronized (socketWrapper) {
> -            AsyncHeaderFrameBuffers headerFrameBuffers =
> (AsyncHeaderFrameBuffers)
> -                    doWriteHeaders(stream, pushedStreamId, mimeHeaders,
> endOfStream, payloadSize);
> -            if (headerFrameBuffers != null) {
> -                socketWrapper.write(BlockingMode.SEMI_BLOCK,
> protocol.getWriteTimeout(),
> -                        TimeUnit.MILLISECONDS, null,
> SocketWrapperBase.COMPLETE_WRITE,
> -                        applicationErrorCompletion,
> headerFrameBuffers.bufs.toArray(BYTEBUFFER_ARRAY));
> -                handleAsyncException();
> -            }
> +        AsyncHeaderFrameBuffers headerFrameBuffers =
> (AsyncHeaderFrameBuffers)
> +                doWriteHeaders(stream, pushedStreamId, mimeHeaders,
> endOfStream, payloadSize);
> +        if (headerFrameBuffers != null) {
> +            socketWrapper.write(BlockingMode.SEMI_BLOCK,
> protocol.getWriteTimeout(),
> +                    TimeUnit.MILLISECONDS, null,
> SocketWrapperBase.COMPLETE_WRITE,
> +                    applicationErrorCompletion,
> headerFrameBuffers.bufs.toArray(BYTEBUFFER_ARRAY));
> +            handleAsyncException();
>          }
>          if (endOfStream) {
>              stream.sentEndOfStream();
> diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
> index 7f55e3d..d65a1f3 100644
> --- a/webapps/docs/changelog.xml
> +++ b/webapps/docs/changelog.xml
> @@ -45,6 +45,15 @@
>    issues do not "pop up" wrt. others).
>  -->
>  <section name="Tomcat 9.0.22 (markt)" rtext="in development">
> +  <subsection name="Coyote">
> +    <changelog>
> +      <fix>
> +        Remove a source of potential deadlocks when using HTTP/2 when the
> +        Connector is configured with <code>useAsyncIO</code> as
> +        <code>true</code>. (markt)
> +      </fix>
> +    </changelog>
> +  </subsection>
>  </section>
>  <section name="Tomcat 9.0.21 (markt)" rtext="release in progress">
>    <subsection name="Catalina">
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

[tomcat] 02/02: Remove a source of potential deadlocks

Posted by ma...@apache.org.
This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git

commit e967bbc7f106f8ec5384a294d98d5cbc44b474f1
Author: Mark Thomas <ma...@apache.org>
AuthorDate: Thu Jun 6 21:45:30 2019 +0100

    Remove a source of potential deadlocks
    
    SocketWrapperBase.vectoredOperation acquires the (read|write) Semaphore
    and then locks the SocketWrapper during completion before the Semaphore
    is release. If the SocketWrapper is locked on some, but not all, paths
    before acquiring the Semaphore, a deadlock becomes possible.
    
    Fixed by removing the initial lock on SocketWrapper since the Semaphores
    make it unnecessary.
---
 .../apache/coyote/http2/Http2AsyncUpgradeHandler.java   | 17 +++++++----------
 webapps/docs/changelog.xml                              |  9 +++++++++
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java b/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
index 969bfda..8a57c53 100644
--- a/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
+++ b/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
@@ -169,16 +169,13 @@ public class Http2AsyncUpgradeHandler extends Http2UpgradeHandler {
     @Override
     void writeHeaders(Stream stream, int pushedStreamId, MimeHeaders mimeHeaders,
             boolean endOfStream, int payloadSize) throws IOException {
-        // This ensures the Stream processing thread has control of the socket.
-        synchronized (socketWrapper) {
-            AsyncHeaderFrameBuffers headerFrameBuffers = (AsyncHeaderFrameBuffers)
-                    doWriteHeaders(stream, pushedStreamId, mimeHeaders, endOfStream, payloadSize);
-            if (headerFrameBuffers != null) {
-                socketWrapper.write(BlockingMode.SEMI_BLOCK, protocol.getWriteTimeout(),
-                        TimeUnit.MILLISECONDS, null, SocketWrapperBase.COMPLETE_WRITE,
-                        applicationErrorCompletion, headerFrameBuffers.bufs.toArray(BYTEBUFFER_ARRAY));
-                handleAsyncException();
-            }
+        AsyncHeaderFrameBuffers headerFrameBuffers = (AsyncHeaderFrameBuffers)
+                doWriteHeaders(stream, pushedStreamId, mimeHeaders, endOfStream, payloadSize);
+        if (headerFrameBuffers != null) {
+            socketWrapper.write(BlockingMode.SEMI_BLOCK, protocol.getWriteTimeout(),
+                    TimeUnit.MILLISECONDS, null, SocketWrapperBase.COMPLETE_WRITE,
+                    applicationErrorCompletion, headerFrameBuffers.bufs.toArray(BYTEBUFFER_ARRAY));
+            handleAsyncException();
         }
         if (endOfStream) {
             stream.sentEndOfStream();
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 7f55e3d..d65a1f3 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -45,6 +45,15 @@
   issues do not "pop up" wrt. others).
 -->
 <section name="Tomcat 9.0.22 (markt)" rtext="in development">
+  <subsection name="Coyote">
+    <changelog>
+      <fix>
+        Remove a source of potential deadlocks when using HTTP/2 when the
+        Connector is configured with <code>useAsyncIO</code> as
+        <code>true</code>. (markt)
+      </fix>
+    </changelog>
+  </subsection>
 </section>
 <section name="Tomcat 9.0.21 (markt)" rtext="release in progress">
   <subsection name="Catalina">


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[tomcat] 01/02: Correct placeholder

Posted by ma...@apache.org.
This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git

commit ab1581d5bebba31048a75eb2948251e22be02c17
Author: Mark Thomas <ma...@apache.org>
AuthorDate: Wed Jun 5 11:51:12 2019 +0100

    Correct placeholder
---
 java/org/apache/tomcat/websocket/LocalStrings.properties | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/java/org/apache/tomcat/websocket/LocalStrings.properties b/java/org/apache/tomcat/websocket/LocalStrings.properties
index ff2043f..820f06c 100644
--- a/java/org/apache/tomcat/websocket/LocalStrings.properties
+++ b/java/org/apache/tomcat/websocket/LocalStrings.properties
@@ -104,7 +104,7 @@ wsSession.timeout=The WebSocket session [{0}] timeout expired
 
 wsSession.closed=The WebSocket session [{0}] has been closed and no method (apart from close()) may be called on a closed session
 wsSession.created=Created WebSocket session [{0}]
-wsSession.doClose=Closing WebSocket session [{1}]
+wsSession.doClose=Closing WebSocket session [{0}]
 wsSession.duplicateHandlerBinary=A binary message handler has already been configured
 wsSession.duplicateHandlerPong=A pong message handler has already been configured
 wsSession.duplicateHandlerText=A text message handler has already been configured


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org