[Bug 63931] The remote endpoint was in state [TEXT_FULL_WRITING] which is an invalid state

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63931

--- Comment #6 from Saurav Singh  ---
Can I expect any help from apahe team to understand what's wrong going on?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 63625] Unable to start Tomcat 7.0.96 (stop by 0xc0000005)

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63625

--- Comment #25 from Tony Yan  ---
Does it mean that Tomcat 7.0.96 32bit is not working because the Tomcat7.exe
has defect?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 63625] Unable to start Tomcat 7.0.96 (stop by 0xc0000005)

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63625

--- Comment #24 from Tony Yan  ---
(In reply to Mark Thomas from comment #23)
> I've just updated Tomcat to use Commons Daemon 1.2.1 where this is fixed.
> 
> Fixed in:
> - master for 9.0.25 onwards
> - 8.5.x for 8.5.46 onwards
> - 7.0.x for 7.0.97 onwards

So, the fix in 7.0.97, how about 7.0.96? Tomcat 7.0.97 is not released yet.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 8.5.49

[Konstantin Kolinko]

вт, 19 нояб. 2019 г. в 01:42, Mark Thomas :
>
> On 18/11/2019 22:01, Rémy Maucherat wrote:
> > On Mon, Nov 18, 2019 at 10:22 PM Mark Thomas  > > wrote:
>
> > Is porting the multipoller removal to 7.0 really doable ?
>
> I don't know. I haven't looked at the code yet. I do have an alternative
> fix I tested that should work if back-porting proves tricky.
>
> > It could be running on older Windows platforms maybe.
>
> That would only be an issue of the versions of Windows were so old they
> were no longer supported by Microsoft. Users in those circumstances are
> unlikely to be updating to the latest 7.0.x release anyway. Therefore
> that isn't something I'm particularly worrying about. (But I am happy to
> be over-ruled if the consensus is not to back-port to 7.0.x.)

Searching my mailbox and archives at https://tomcat.markmail.org/,

a) Tomcat 7.0.96 running on Windows XP  was mentioned recently (August 2019)
https://bz.apache.org/bugzilla/show_bug.cgi?id=63625#c16

b) Tomcat 8.5 was never mentioned running on Windows XP or on Windows 2003.
There was one thread about Tomcat 8.5.3 when a client was using
Windows XP, but Tomcat was running on Ubuntu.
There was one thread in year 2017 about posting an application from an
old server running Windows 2003 and Tomcat 5 to Tomcat 8.5.
https://markmail.org/thread/qvmzmmjz2dqohbk5

I think the single pollset change should not be backported to Tomcat 7.
I am OK with it being backported to Tomcat 8.5.

Best regards,
Konstantin Kolinko

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

[Bug 63932] Content compression breaks contract of ETag

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63932

--- Comment #6 from Konstantin Kolinko  ---
(In reply to Mark Thomas from comment #5)
> Please take care, as Julian did, to be specific about whether you are
> talking about weak or strong validators.
> 
> RFC 7232 states (section 2.1)
> [...]
> 
> So the Default servlet (that only ever sets a weak ETag) is fine. As is the
> WebDAV servlet.

+1

> Where things get "interesting" is when resources set their own, strong ETag.
> It looks to me that the simplest solution would be for the container
> provided compression to check for the presence of a strong ETag and, if it
> finds one, prepend the weakness indicator to the ETag if it is going to
> compress the resource.

Interesting idea. But I think such feature has to be documented. A server
administrator should be aware that changing a Connector setting will change
behaviour of a web application in that way as well. (Changing strong ETag to a
weak one may affect performance of caches.)

Another possible solution is to do not compress a response if a strong ETag is
encountered. The same what we do when a response is already compressed.

https://github.com/apache/tomcat/blob/9.0.29/java/org/apache/coyote/CompressionConfig.java#L203

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 8.5.49

[Konstantin Kolinko]

вт, 19 нояб. 2019 г. в 00:22, Mark Thomas :
>
> On 17/11/2019 19:01, Mark Thomas wrote:
>
> We have a regression affecting 8.5.x (and 7.0.x).
>
> The fix [1] for an issue raised on the users list [2] was incorrect and
> creating a different issue [3].
>
> There are two questions to address.
>
> a) Do we cancel the 8.5.49 release for this and roll a 8.5.50 release?

If we are re-rolling, I would like to pull back Chris Schultz's
changes to CSRF Filter
(8c143abae26f9b0c49b233c3e7a9cb6cc5b1b0ed)
until all issues with those changes are solved on master (9.0).

Not a showstopper.

> b) Do we fix this by a) correcting [1] or back-porting the change to a
> single poll set?
>
> I'm leaning towards 8.5.50 and back-port the single poll set change.
>

What is easier for you?
If 7.0.x needs a patch as well, won't it be easier to have the same
patch as for 7.0?

(For reference, discussion of the single poll set change on dev@, Jul 05 2019
https://tomcat.markmail.org/thread/dzlcnmuodeqe27w7
Subject:Re: [tomcat] branch master updated: Quick fix for poller issue
reported on users list
)

The removed code is for older OSes like Windows XP. As stated in a
comment in that code (in AprEndpoint.java) the issue was solved in
Windows Vista,
Support for Windows XP ended April 8, 2014.  The first version of Java
8 was March 18, 2014, thus we are safe to assume that Tomcat 9 does
not run on Windows XP.

The first version of Java 7 was in 2011, thus I think that Tomcat 8.0
may run on Windows XP.

Tomcat 8.5.0 was released in March 2016, so I think it was never
really tested on Windows XP.  Looking into the "Vote" thread for
8.5.0, it was tested on Windows 7. Thus I have no objections against
backporting the single pollset change to Tomcat 8.5.

Officially, running Java 7 on Windows XP is no longer supported by
Oracle. For reference:
https://www.oracle.com/technetwork/java/javase/config-417990.html
"Oracle JDK 7 and JRE 7 Certified System Configurations"


Best regards,
Konstantin Kolinko

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

Re: [VOTE] Release Apache Tomcat 8.5.49

[Mark Thomas]

On 18/11/2019 22:01, Rémy Maucherat wrote:
> On Mon, Nov 18, 2019 at 10:22 PM Mark Thomas  > wrote:
> 
> On 17/11/2019 19:01, Mark Thomas wrote:
> 
> We have a regression affecting 8.5.x (and 7.0.x).
> 
> The fix [1] for an issue raised on the users list [2] was incorrect and
> creating a different issue [3].
> 
> There are two questions to address.
> 
> a) Do we cancel the 8.5.49 release for this and roll a 8.5.50 release?
> 
> b) Do we fix this by a) correcting [1] or back-porting the change to a
> single poll set?
> 
> I'm leaning towards 8.5.50 and back-port the single poll set change.
> 
> Thoughts?
> 
> Mark
> 
> [1]
> 
> https://github.com/apache/tomcat/commit/fffb08790e642e03f00c5f96a3a61ee09a2c8342
> [2] https://markmail.org/thread/lh7pst3bwptpcyco
> [3] https://tomcat.markmail.org/thread/btjionfhp2olyjne
> 
> 
> +0 only for 8.5.50 since the issue isn't so common (APR + Windows).

Ack.

> Is porting the multipoller removal to 7.0 really doable ?

I don't know. I haven't looked at the code yet. I do have an alternative
fix I tested that should work if back-porting proves tricky.

> It could be running on older Windows platforms maybe.

That would only be an issue of the versions of Windows were so old they
were no longer supported by Microsoft. Users in those circumstances are
unlikely to be updating to the latest 7.0.x release anyway. Therefore
that isn't something I'm particularly worrying about. (But I am happy to
be over-ruled if the consensus is not to back-port to 7.0.x.)

Mark

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

Re: [VOTE] Release Apache Tomcat 8.5.49

[Rémy Maucherat]

On Mon, Nov 18, 2019 at 10:22 PM Mark Thomas  wrote:

> On 17/11/2019 19:01, Mark Thomas wrote:
>
> We have a regression affecting 8.5.x (and 7.0.x).
>
> The fix [1] for an issue raised on the users list [2] was incorrect and
> creating a different issue [3].
>
> There are two questions to address.
>
> a) Do we cancel the 8.5.49 release for this and roll a 8.5.50 release?
>
> b) Do we fix this by a) correcting [1] or back-porting the change to a
> single poll set?
>
> I'm leaning towards 8.5.50 and back-port the single poll set change.
>
> Thoughts?
>
> Mark
>
> [1]
>
> https://github.com/apache/tomcat/commit/fffb08790e642e03f00c5f96a3a61ee09a2c8342
> [2] https://markmail.org/thread/lh7pst3bwptpcyco
> [3] https://tomcat.markmail.org/thread/btjionfhp2olyjne
>

+0 only for 8.5.50 since the issue isn't so common (APR + Windows). Is
porting the multipoller removal to 7.0 really doable ? It could be running
on older Windows platforms maybe.

Rémy

[Bug 63932] Content compression breaks contract of ETag

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63932

--- Comment #5 from Mark Thomas  ---
Please take care, as Julian did, to be specific about whether you are talking
about weak or strong validators.

RFC 7232 states (section 2.1)

Likewise, a validator is weak if it is shared by two or more
representations of a given resource at the same time, unless those
representations have identical representation data.  For example, if
the origin server sends the same validator for a representation with
a gzip content coding applied as it does for a representation with no
content coding, then that validator is weak.


So the Default servlet (that only ever sets a weak ETag) is fine. As is the
WebDAV servlet.

Where things get "interesting" is when resources set their own, strong ETag. It
looks to me that the simplest solution would be for the container provided
compression to check for the presence of a strong ETag and, if it finds one,
prepend the weakness indicator to the ETag if it is going to compress the
resource.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 8.5.49

[Igal Sapir]

On 11/18/2019 1:22 PM, Mark Thomas wrote:

On 17/11/2019 19:01, Mark Thomas wrote:

We have a regression affecting 8.5.x (and 7.0.x).

The fix [1] for an issue raised on the users list [2] was incorrect and
creating a different issue [3].

There are two questions to address.

a) Do we cancel the 8.5.49 release for this and roll a 8.5.50 release?

b) Do we fix this by a) correcting [1] or back-porting the change to a
single poll set?

I'm leaning towards 8.5.50 and back-port the single poll set change.

Thoughts?


+1 for 8.5.50

Igal




Mark

[1]
https://github.com/apache/tomcat/commit/fffb08790e642e03f00c5f96a3a61ee09a2c8342
[2] https://markmail.org/thread/lh7pst3bwptpcyco
[3] https://tomcat.markmail.org/thread/btjionfhp2olyjne



The proposed Apache Tomcat 8.5.49 release is now available for voting.

The major changes compared to the 8.5.47 release are:

- Improvements to Async error handling

- Stricter processing of HTTP headers when looking for specific token
   values

- Fix various issues that could lead to modification to a JSP not being
   reflected in the served page

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://ci.apache.org/projects/tomcat/tomcat85/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.49/

The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1238/

The tag is:
https://github.com/apache/tomcat/tree/8.5.49

The proposed 8.5.49 release is:
[ ] Broken - do not release
[ ] Stable - go ahead and release as 8.5.49

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



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



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

Re: [VOTE] Release Apache Tomcat 8.5.49

[Mark Thomas]

On 17/11/2019 19:01, Mark Thomas wrote:

We have a regression affecting 8.5.x (and 7.0.x).

The fix [1] for an issue raised on the users list [2] was incorrect and
creating a different issue [3].

There are two questions to address.

a) Do we cancel the 8.5.49 release for this and roll a 8.5.50 release?

b) Do we fix this by a) correcting [1] or back-porting the change to a
single poll set?

I'm leaning towards 8.5.50 and back-port the single poll set change.

Thoughts?

Mark

[1]
https://github.com/apache/tomcat/commit/fffb08790e642e03f00c5f96a3a61ee09a2c8342
[2] https://markmail.org/thread/lh7pst3bwptpcyco
[3] https://tomcat.markmail.org/thread/btjionfhp2olyjne


> The proposed Apache Tomcat 8.5.49 release is now available for voting.
> 
> The major changes compared to the 8.5.47 release are:
> 
> - Improvements to Async error handling
> 
> - Stricter processing of HTTP headers when looking for specific token
>   values
> 
> - Fix various issues that could lead to modification to a JSP not being
>   reflected in the served page
> 
> Along with lots of other bug fixes and improvements.
> 
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat85/docs/changelog.html
> 
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.49/
> 
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1238/
> 
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.49
> 
> The proposed 8.5.49 release is:
> [ ] Broken - do not release
> [ ] Stable - go ahead and release as 8.5.49
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 


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

Re: [VOTE] Release Apache Tomcat 8.5.49

[Coty Sutherland]

On Sun, Nov 17, 2019 at 2:01 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 8.5.49 release is now available for voting.
>
> The major changes compared to the 8.5.47 release are:
>
> - Improvements to Async error handling
>
> - Stricter processing of HTTP headers when looking for specific token
>   values
>
> - Fix various issues that could lead to modification to a JSP not being
>   reflected in the served page
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat85/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.49/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1238/
>
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.49
>
> The proposed 8.5.49 release is:
> [ ] Broken - do not release
> [x] Stable - go ahead and release as 8.5.49
>

+1


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

Re: [VOTE] Release Apache Tomcat 9.0.29

[Coty Sutherland]

On Sat, Nov 16, 2019 at 1:56 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 9.0.29 release is now available for voting.
>
> The major changes compared to the 9.0.27 release are:
>
> - Improvements to Async error handling
>
> - Stricter processing of HTTP headers when looking for specific token
>   values
>
> - Fix various issues that could lead to modification to a JSP not being
>   reflected in the served page
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat9/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.29/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1236/
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.29
>
>
> The proposed 9.0.29 release is:
> [ ] Broken - do not release
> [x] Stable - go ahead and release as 9.0.29
>

+1


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

Re: [VOTE] Release Apache Tomcat 9.0.29

[Igal Sapir]

On 11/16/2019 10:56 AM, Mark Thomas wrote:

The proposed Apache Tomcat 9.0.29 release is now available for voting.

The proposed 9.0.29 release is:
[ ] Broken - do not release
[X] Stable - go ahead and release as 9.0.29


Unit tests passed on Windows 10 and Ubuntu 18.04

Igal



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

Re: [VOTE] Release Apache Tomcat 8.5.49

[Igal Sapir]

On 11/17/2019 11:01 AM, Mark Thomas wrote:

The proposed Apache Tomcat 8.5.49 release is now available for voting.

The proposed 8.5.49 release is:
[ ] Broken - do not release
[X] Stable - go ahead and release as 8.5.49


Unit tests passed on Windows 10 and Ubuntu 18.04

Igal



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

[Bug 63932] Content compression breaks contract of ETag

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63932

--- Comment #4 from Michael Osipov  ---
(In reply to Remy Maucherat from comment #2)
> The purpose of the tag is to know if there is an update. Thus, it is ok if
> compression does not change the etag, regardless of what the specification
> might imply in its language.

No, that's wrong.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 63932] Content compression breaks contract of ETag

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63932

--- Comment #3 from Julian Reschke  ---
Hm, no.

If the payload is different, it can't have the same strong etag.

Consider the impact on conditional requests.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 63932] Content compression breaks contract of ETag

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63932

--- Comment #2 from Remy Maucherat  ---
The purpose of the tag is to know if there is an update. Thus, it is ok if
compression does not change the etag, regardless of what the specification
might imply in its language.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 63932] Content compression breaks contract of ETag

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63932

--- Comment #1 from Michael Osipov  ---
I think this also applies to the DefaultServlet for weak Etags:

An origin server
   SHOULD change a weak entity-tag whenever it considers prior
   representations to be unacceptable as a substitute for the current
   representation.  In other words, a weak entity-tag ought to change
   whenever the origin server wants caches to invalidate old responses.

but I am not fully sure. One might need to inquire with Julian Reschke.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 63932] New: Content compression breaks contract of ETag

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63932

Bug ID: 63932
   Summary: Content compression breaks contract of ETag
   Product: Tomcat 9
   Version: 9.0.x
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P2
 Component: Connectors
  Assignee: dev@tomcat.apache.org
  Reporter: micha...@apache.org
  Target Milestone: -

This is basically the same as Bug 39727.

Consider a huge JSON file, content compression is on in the connector and this
simple servlet:

> protected void doGet(HttpServletRequest request, HttpServletResponse 
> response) throws ServletException, IOException {
>   response.setContentType("application/json");
>   Path dump = Paths.get("projects.json");
>   response.setContentLengthLong(Files.size(dump));
>   response.setHeader("ETag", String.format("\"%d+%s\"", Files.size(dump), 
> Files.getLastModifiedTime(dump)));
>   Files.copy(dump, response.getOutputStream());
> }

and the following curl requests:

> $ curl http://md11gxtc:8080/awesome/awesome  -H "Accept-Encoding: identity" -I
> HTTP/1.1 200
> ETag: "2571736354+2016-01-07T12:29:06.455824Z"
> vary: accept-encoding
> Content-Type: application/json
> Content-Length: 2571736354
> Date: Mon, 18 Nov 2019 11:50:04 GMT

This one is fine, now lets request compression:
> $ curl http://md11gxtc:8080/awesome/awesome  -H "Accept-Encoding: gzip" -I
> HTTP/1.1 200
> ETag: "2571736354+2016-01-07T12:29:06.455824Z"
> vary: accept-encoding
> Content-Encoding: gzip
> Content-Type: application/json
> Transfer-Encoding: chunked
> Date: Mon, 18 Nov 2019 11:50:46 GMT

RFC 7232, 2.1 + 2.3 + 2.3.1 + 2.3.3 say: ETag generation happens over content
negotiation.

RFC 7231, 5.3 these headers are part of content negotiation:
Accept
Accept-Charset
Accept-Encoding
Accept-Language

Basically, Tomcat would require to modify the ETag somehow and on the fly
remove the change when If-Match/If-None-Match arrives at the servlet. Fully
opaque.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 8.5.49

[Rémy Maucherat]

On Sun, Nov 17, 2019 at 8:01 PM Mark Thomas  wrote:

> The proposed Apache Tomcat 8.5.49 release is now available for voting.
>
> The major changes compared to the 8.5.47 release are:
>
> - Improvements to Async error handling
>
> - Stricter processing of HTTP headers when looking for specific token
>   values
>
> - Fix various issues that could lead to modification to a JSP not being
>   reflected in the served page
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat85/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.49/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1238/
>
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.49
>
> The proposed 8.5.49 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 8.5.49
>
> Rémy

[Bug 63931] The remote endpoint was in state [TEXT_FULL_WRITING] which is an invalid state

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63931

--- Comment #5 from Saurav Singh  ---
You can see just now got same issue after raising the bug ticket:

2019-11-18T15:29:29,041 [tainer#0-1] co.ea.ex.no.tr.we.WebSocketServerHandler
ERROR: o.tr.we.WebSocketServerHandler(dToSession:  525) Encountered an error
sending session
StandardWebSocketSession[id=406e750f-554d-a786-8f01-6f0a24408833,
uri=wss://localhost:9004/websocket] open to client!
java.lang.IllegalStateException: The remote endpoint was in state
[TEXT_FULL_WRITING] which is an invalid state for called method
at
org.apache.tomcat.websocket.WsRemoteEndpointImplBase$StateMachine.checkState(WsRemoteEndpointImplBase.java:1229)
at
org.apache.tomcat.websocket.WsRemoteEndpointImplBase$StateMachine.textStart(WsRemoteEndpointImplBase.java:1191)
at
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendString(WsRemoteEndpointImplBase.java:190)
at
org.apache.tomcat.websocket.WsRemoteEndpointBasic.sendText(WsRemoteEndpointBasic.java:37)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 63931] The remote endpoint was in state [TEXT_FULL_WRITING] which is an invalid state

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63931

--- Comment #4 from Saurav Singh  ---
So I am working on Spring boot websocket which has method a
afterConnectionClosed(final WebSocketSession session, final CloseStatus status)
throws Exception that I have overriden on same handler class however I haven't
seen any log information being printed anywhere in log. I am not sure whether I
should be like that or any method i have override or configuration changes can
help me to move ahead.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 63931] The remote endpoint was in state [TEXT_FULL_WRITING] which is an invalid state

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63931

--- Comment #3 from Mark Thomas  ---
You should see a call to onClose() before this happens. You should also see an
IOException in the thread writing the message.

One thing I think Tomcat could improve on, is preventing applications trying to
write further messages once the close message has been written to the client.
Although in this scenario, that probably means you just get a different series
of exceptions.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 63931] The remote endpoint was in state [TEXT_FULL_WRITING] which is an invalid state

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63931

--- Comment #2 from Saurav Singh  ---
Hey Mark Thanks for response.

 1. Once you see the exception, do all subsequent attempts to write a message
trigger that exception? Answer --> Yes It does try to write message and trigger
that excpetion and then all threads hung forever.


Or is it intermittent? Answer --> It is not intermittent it happened over the
time always reproducable.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 63931] The remote endpoint was in state [TEXT_FULL_WRITING] which is an invalid state

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63931

Mark Thomas  changed:

   What|Removed |Added

 OS||All

--- Comment #1 from Mark Thomas  ---
Looking at the Tomcat code, there are two ways this can happen.

1. A previous messages has an error which throws an exception. This essentially
means the WebSocket connection is no longer usable.

2. Attempting to send messages concurrently.

>From your description, this looks like a case of 1. Once you see the exception,
do all subsequent attempts to write a message trigger that exception? Or is it
intermittent?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [tomcat] branch master updated: Fix timeout handling. Write timeout could be handled as read timeout.

[Mark Thomas]

On 17/11/2019 22:33, Rémy Maucherat wrote:
> On Sat, Nov 16, 2019 at 5:44 PM  > 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
> 
> 
> The following commit(s) were added to refs/heads/master by this push:
>      new 40ca9be  Fix timeout handling. Write timeout could be
> handled as read timeout.
> 40ca9be is described below
> 
> commit 40ca9bef10a2c2db48e759b16fc4fbff3725ffca
> Author: Mark Thomas mailto:ma...@apache.org>>
> AuthorDate: Sat Nov 16 16:43:52 2019 +
> 
>     Fix timeout handling. Write timeout could be handled as read
> timeout.



> I should have figured out that I needed only two flags there. Sorry for
> the trouble, it must have been a lot harder to figure out a long time
> after the initial overhaul.

No trouble. I'm not even sure that this was causing a problem. I ended
up looking at the code while investigating an intermittent test failure.
The error appeared to go away after I made the change but these sorts of
failures being what they are it may have been completely unrelated to
this change. I guess time will tell.

Mark

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