[Bug 64644] New: wrong state of WsSession on network outage
https://bz.apache.org/bugzilla/show_bug.cgi?id=64644 Bug ID: 64644 Summary: wrong state of WsSession on network outage Product: Tomcat 9 Version: 9.0.31 Hardware: PC OS: Linux Status: NEW Severity: major Priority: P2 Component: WebSocket Assignee: dev@tomcat.apache.org Reporter: saksham.ve...@gmail.com Target Milestone: - Created attachment 37382 --> https://bz.apache.org/bugzilla/attachment.cgi?id=37382&action=edit a web project to start a ws server and index.html showing value of active websocket connections This issue happens on any Linux OS, when we have a remote websocket connection stable and then, network drops. If the application is writing on that websocket channel, then the lastActiveTime keeps on getting updated even if there is no network. The writes are successful for next ~15 minutes because the keep-alive interval for tcp is 15 minutes. Thus, from the time network was dropped to next 15 minutes the WsSession is shown as active. And if the application is not writing anything on that channel, then after the maxIdleTimeout the WsSession.checkExpiration closes the connection. But when application is writing it shows wrong state of websocket session. Steps to reproduce: 1. Start the attached web project on a linux OS. It sets the maxIdleTimeout to 10 seconds and if any websocket session is created it sends a message every 2 seconds. 2. On any remote system connect a websocket session. I used the "smart websocket client" extension in chrome. 3. Check that the /WebsocketActiveTimeIssue/index.html shows 1. 4. Drop the network connection between the client and server. I was using a VM so, I disconnected the network from Oracle virtual box. 5. For next 15 minutes that webpage will keep showing 1. Root cause: Tomcat updates the lastActiveTime anytime application writes anything on that channel. Thus, WsSession.checkExpiration() method never expires it unless the transport layer throws an error which happens only after 15 minutes. Effect: In my product, I need to show the devices which are connected to my IoT platform. The devices send the ping every T seconds (T is much less than maxIdleTimeout), thus, if there were any Idle Read events, then I could use that to close the connection and show the device as disconnected. Suggestion: Have two types of active times. viz. One for read and one for write: Throw an IdleRead or IdleWrite event when any of the active times are passed the maxIdle timeout. I have tried a fix on my system. But I don't know how to raise a PR with that. Though I am on the dev mailing list but got recently added. -- 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 64645] New: bin/service.bat doesn't handle wrongly configured JAVA_HOME
https://bz.apache.org/bugzilla/show_bug.cgi?id=64645 Bug ID: 64645 Summary: bin/service.bat doesn't handle wrongly configured JAVA_HOME Product: Tomcat 9 Version: 9.0.x Hardware: PC Status: NEW Severity: normal Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: jakub.mora...@getmanta.com Target Milestone: - This seems to be similar to https://bz.apache.org/bugzilla/show_bug.cgi?id=49993, maybe the validation just needs to be enhanced. Hello, this is my first ticket in Apache Bugzilla, please bear with me. We found out, that if JAVA_HOME is wrongly configured (for example if it points to JRE instead of JDK), the service.bat script won't fail, will skip to and return exit code 0. This is misleading, as the service was not installed because of wrongly set-up JAVA_HOME. Is it possible to provide better validation and make sure, that the exit code is not 0 in case the installation of the service fails? I believe that swallowing of exceptions is not a good approach ;) Thanks! -- 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: Discouraging Rogue Users In Tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Alan, On 8/3/20 21:25, Alan Basche wrote: > I have recently developed code for Tomcat 8.5 that defends against > black-hats probing Tomcat and the website apps for > vulnerabilities. This coding effort started a year ago, and the > latest code has been running successfully on Tomcat 8.5.49 (Linux > server) for about 3 months. I feel that Tomcat is less vulnerable > now and I would be rather uncomfortable running a production system > without this new feature. > > I am happy to provide design details and donate this code to > Apache, but I am unsure of your process to introduce new Tomcat > features for review by your dev team, and to submit code. > > Let me know if you have questions. What kind of protections does this module provide? How does it integrate into Tomcat (e.g. custom Filter/Valve/ServletContextListener, patches to arbitrary places in Tomcat internals, etc.)? Are you willing to post your code somewhere like GitHub where everyone can see it? - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8paG4ACgkQHPApP6U8 pFjbHg/8CJU3YQqQhu9TdPkSyS1CtRy6dgN0wf24NbU0mB39732lSk63Nssvm76e TWSzZ3cArjNseMrv8pxPsj44q5LCKZC065PpJnz5FEG0wJo7jVH+oQ4UcfBTqyuF woTjbMmX7b8IQIY/z5vgHXlgXlbVx8gZzNyRh0SgUZPNrZyViGgTKLMz4Wo+1PO+ xhBIEsAMyF55mei8qXYTatoW6vZ8oXofzh54Z41sAiA1zhziPBgim6E8UUaH8F8p kL9fcI3n421tsaE9ALLMrWQLAxUgwdbcLrL23JWRXOMT9pk7htkdEpQ+NF7UByr+ yL6omz3+LfUngFpAAIYX1A2DRQ9vtlFkM3VklGahemAM3BXzsiAEwbMYCycAhJEt iuoBu93F1q00iStYE6OcesRLIcmVplQMEGfgF8ibg9NGJQZLeTGXKfN2ksGAkr9x uk4uco9+NDKq19eQGitFnzx+l1Dvh9NlSDcoJsbw8mDKhPM1S+u3vQ5jVIgTw9s0 W5U8qWxFFcH3yWa805f3Skptps7mQg12YpDBsTEErwip+cIGhwG4Yna1AFtXhVU3 QHdz9hEsu1efNVWmjKvTsjAXnPNfn5F3rXjiyEbEzws1k0Z4D8MlrFWyk4ykfJWj e4/oPtQE/QD2jgq488WDRhMRimV2iB4u26SdfW7dyQvXVHNQI8I= =AiQz -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 64645] bin/service.bat doesn't handle wrongly configured JAVA_HOME
https://bz.apache.org/bugzilla/show_bug.cgi?id=64645 Christopher Schultz changed: What|Removed |Added OS||All --- Comment #1 from Christopher Schultz --- (In reply to Jakub Moravec from comment #0) > https://bz.apache.org/bugzilla/show_bug.cgi?id=49993, maybe the validation > just needs to be enhanced. +1 > We found out, that if JAVA_HOME is wrongly configured (for example if it > points to JRE instead of JDK), the service.bat script won't fail, will skip > to and return exit code 0. JAVA_HOME should be able to point to either a JRE or JDK. Tomcat hasn't required a JDK for a very long time. > This is misleading, as the service was not installed because of wrongly > set-up JAVA_HOME. If true, I agree. > Is it possible to provide better validation and make sure, that the exit > code is not 0 in case the installation of the service fails? Probably the best way to check for JAVA_HOME validity is to actually launch the JVM with some trivial task (even just "java.exe --help") to make sure it executes successfully, would you agree? > I believe that swallowing of exceptions is not a good approach ;) Do you believe there is an error being swallowed? Which one? -- 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 64644] wrong state of WsSession on network outage
https://bz.apache.org/bugzilla/show_bug.cgi?id=64644 --- Comment #1 from Saksham Verma --- Created attachment 37383 --> https://bz.apache.org/bugzilla/attachment.cgi?id=37383&action=edit a web project to start a ws server and index.html showing value of active websocket connections -- 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 64644] wrong state of WsSession on network outage
https://bz.apache.org/bugzilla/show_bug.cgi?id=64644 --- Comment #2 from Saksham Verma --- (In reply to Saksham Verma from comment #1) > Created attachment 37383 [details] > a web project to start a ws server and index.html showing value of active > websocket connections Use the latest attachment to reproduce the issue. Ignore the first attachment. -- 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
[GitHub] [tomcat] sakshamverma opened a new pull request #329: Bz64644 idle session handler
sakshamverma opened a new pull request #329: URL: https://github.com/apache/tomcat/pull/329 Bug ID: https://bz.apache.org/bugzilla/show_bug.cgi?id=64644 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] michael-o commented on pull request #329: Bz64644 idle session handler
michael-o commented on pull request #329: URL: https://github.com/apache/tomcat/pull/329#issuecomment-668710010 Rebase first This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] sakshamverma closed pull request #329: Bz64644 idle session handler
sakshamverma closed pull request #329: URL: https://github.com/apache/tomcat/pull/329 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] sakshamverma opened a new pull request #330: BZ-64644 throw an Idle Session handler on idle timeout
sakshamverma opened a new pull request #330: URL: https://github.com/apache/tomcat/pull/330 Bug ID Bug ID: https://bz.apache.org/bugzilla/show_bug.cgi?id=64644 The demo is also present there. I found a bug while working on my product of IoT platform. On network outage, the devices still showed connected due to the fact that tomcat didn't expire the existing connection. KIndly review. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57661] Delay sending of 100 continue response until application tries to read request body
https://bz.apache.org/bugzilla/show_bug.cgi?id=57661 --- Comment #7 from ma...@backblaze.com --- (In reply to Mark Thomas from comment #5) I ran into this recently and ended up implementing option (b) locally: b) container sends it when an InputStream / Reader is obtained I'd be happy to prepare my local changes as a PR if there is a willingness to move forward with this solution. Thanks! -- 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 64644] wrong state of WsSession on network outage
https://bz.apache.org/bugzilla/show_bug.cgi?id=64644 --- Comment #3 from Saksham Verma --- PR: https://github.com/apache/tomcat/pull/330/files Could any maintainer please review. -- 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 57661] Delay sending of 100 continue response until application tries to read request body
https://bz.apache.org/bugzilla/show_bug.cgi?id=57661 --- Comment #8 from Michael Osipov --- Please note that state changing actions do not necessary require a body, e.g., DELETE or generic POST with command in the URL. If Tomcat would wait until obtaining input this would completely defeat Expect Continue support. -- 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 57661] Delay sending of 100 continue response until application tries to read request body
https://bz.apache.org/bugzilla/show_bug.cgi?id=57661 --- Comment #9 from Christopher Schultz --- Why send 100-continue if you don't expect to send a request entity? The whole point of 100-continue is to request permission from the server to send a (usually large) request entity. -- 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 57661] Delay sending of 100 continue response until application tries to read request body
https://bz.apache.org/bugzilla/show_bug.cgi?id=57661 --- Comment #10 from Michael Osipov --- (In reply to Christopher Schultz from comment #9) > Why send 100-continue if you don't expect to send a request entity? The > whole point of 100-continue is to request permission from the server to send > a (usually large) request entity. because a client impl may does this by default. I haven't veryfied Apache HttpClient not to send the header when not HttpEntity is attached. -- 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
[tomcat] branch master updated: Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=62723
This is an automated email from the ASF dual-hosted git repository. schultz 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 d3c8a10 Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=62723 d3c8a10 is described below commit d3c8a10babacae2fb857c0591960d96397305353 Author: Christopher Schultz AuthorDate: Tue Aug 4 16:56:39 2020 -0400 Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=62723 Clarify the effects of some cluster channelSendOptions. Patch provided by Mitch Claborn. --- webapps/docs/changelog.xml | 4 webapps/docs/cluster-howto.xml | 2 ++ webapps/docs/config/cluster.xml | 34 ++ 3 files changed, 40 insertions(+) diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml index 246c2c4..17ec66b 100644 --- a/webapps/docs/changelog.xml +++ b/webapps/docs/changelog.xml @@ -109,6 +109,10 @@ Clean-up / standardize the XSL files used to generate the documentation. PR provided by John Bampton. (markt) + +62723: Clarify the effects of some options for cluster +channelSendOptions. Patch provided by Mitch Claborn. +(schultz) diff --git a/webapps/docs/cluster-howto.xml b/webapps/docs/cluster-howto.xml index cfbfc2f..09cdb2c 100644 --- a/webapps/docs/cluster-howto.xml +++ b/webapps/docs/cluster-howto.xml @@ -218,6 +218,8 @@ should be completed: Synchronous vs. asynchronous is configured using the channelSendOptions flag and is an integer value. The default value for the SimpleTcpCluster/DeltaManager combo is 8, which is asynchronous. +See the configuration reference +for more discussion on the various channelSendOptions values. For convenience, channelSendOptions can be set by name(s) rather than integer, diff --git a/webapps/docs/config/cluster.xml b/webapps/docs/config/cluster.xml index 91e8328..12434a8 100644 --- a/webapps/docs/config/cluster.xml +++ b/webapps/docs/config/cluster.xml @@ -146,6 +146,40 @@ Tomcat cluster. These include: to the order in which they were sent. +The various channelSendOptions values offer a tradeoff +between throughput on the sending node and the reliability of +replication should the sending or receiving node(s) fail. Here are +some common options. "Message" could be any message sent between nodes, +but only session-change messages are considered, here. + + +channelSendOptions="8" / channelSendOptions="async" +As far as the sender is concerned, the message is "sent" +as soon as it has been placed in the queue on the sender for +transmission to the other nodes. The message may not reach any or all +of the recipient nodes and may not be successfully processed on any +nodes that it does reach. This option offers the highest throughput on +the sender but the least reliability, as the triggering request will +complete without any knowledge of the success/failure of the session +replication. + + +channelSendOptions="2" / channelSendOptions="use_ack" +The sender will block the completion of the current request until all +of the receiving nodes have acknowledged that they have received the +message, but have not necessarily processed that message. This option +will result in lower throughput on the sending node, because the message +must be transmitted and the acknowledgement received, but the +reliability is greater than the asynchronous model. + + +channelSendOptions="6" / channelSendOptions="sync,use_ack" +The sender will block the completion of the current request until +all of the receiving nodes have acknowledged that they have received +and processed the message. This option will have the lowest +throughput (of these three) but the greatest reliability. + + You may also set these options as a comma separated string, e.g. "async, multicast", which will be translated into Channel.SEND_OPTIONS_ASYNCHRONOUS | Channel.SEND_OPTIONS_MULTICAST - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 9.0.x updated: Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=62723
This is an automated email from the ASF dual-hosted git repository. schultz pushed a commit to branch 9.0.x in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/9.0.x by this push: new b75ee12 Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=62723 b75ee12 is described below commit b75ee12a4ed6724c21f1a670b5a569ff5e043e52 Author: Christopher Schultz AuthorDate: Tue Aug 4 16:59:34 2020 -0400 Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=62723 Clarify the effects of some cluster channelSendOptions. Patch provided by Mitch Claborn. --- webapps/docs/changelog.xml | 4 webapps/docs/cluster-howto.xml | 2 ++ webapps/docs/config/cluster.xml | 34 ++ 3 files changed, 40 insertions(+) diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml index 95ddadf..1806b15 100644 --- a/webapps/docs/changelog.xml +++ b/webapps/docs/changelog.xml @@ -105,6 +105,10 @@ Clean-up / standardize the XSL files used to generate the documentation. PR provided by John Bampton. (markt) + +62723: Clarify the effects of some options for cluster +channelSendOptions. Patch provided by Mitch Claborn. +(schultz) diff --git a/webapps/docs/cluster-howto.xml b/webapps/docs/cluster-howto.xml index cfbfc2f..09cdb2c 100644 --- a/webapps/docs/cluster-howto.xml +++ b/webapps/docs/cluster-howto.xml @@ -218,6 +218,8 @@ should be completed: Synchronous vs. asynchronous is configured using the channelSendOptions flag and is an integer value. The default value for the SimpleTcpCluster/DeltaManager combo is 8, which is asynchronous. +See the configuration reference +for more discussion on the various channelSendOptions values. For convenience, channelSendOptions can be set by name(s) rather than integer, diff --git a/webapps/docs/config/cluster.xml b/webapps/docs/config/cluster.xml index 91e8328..12434a8 100644 --- a/webapps/docs/config/cluster.xml +++ b/webapps/docs/config/cluster.xml @@ -146,6 +146,40 @@ Tomcat cluster. These include: to the order in which they were sent. +The various channelSendOptions values offer a tradeoff +between throughput on the sending node and the reliability of +replication should the sending or receiving node(s) fail. Here are +some common options. "Message" could be any message sent between nodes, +but only session-change messages are considered, here. + + +channelSendOptions="8" / channelSendOptions="async" +As far as the sender is concerned, the message is "sent" +as soon as it has been placed in the queue on the sender for +transmission to the other nodes. The message may not reach any or all +of the recipient nodes and may not be successfully processed on any +nodes that it does reach. This option offers the highest throughput on +the sender but the least reliability, as the triggering request will +complete without any knowledge of the success/failure of the session +replication. + + +channelSendOptions="2" / channelSendOptions="use_ack" +The sender will block the completion of the current request until all +of the receiving nodes have acknowledged that they have received the +message, but have not necessarily processed that message. This option +will result in lower throughput on the sending node, because the message +must be transmitted and the acknowledgement received, but the +reliability is greater than the asynchronous model. + + +channelSendOptions="6" / channelSendOptions="sync,use_ack" +The sender will block the completion of the current request until +all of the receiving nodes have acknowledged that they have received +and processed the message. This option will have the lowest +throughput (of these three) but the greatest reliability. + + You may also set these options as a comma separated string, e.g. "async, multicast", which will be translated into Channel.SEND_OPTIONS_ASYNCHRONOUS | Channel.SEND_OPTIONS_MULTICAST - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot failure in on tomcat-trunk
The Buildbot has detected a new failure on builder tomcat-trunk while building tomcat. Full details are available at: https://ci.apache.org/builders/tomcat-trunk/builds/5328 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: asf946_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' triggered this build Build Source Stamp: [branch master] d3c8a10babacae2fb857c0591960d96397305353 Blamelist: Christopher Schultz BUILD FAILED: failed compile Sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot failure in on tomcat-9-trunk
The Buildbot has detected a new failure on builder tomcat-9-trunk while building tomcat. Full details are available at: https://ci.apache.org/builders/tomcat-9-trunk/builds/355 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: asf946_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-9-commit' triggered this build Build Source Stamp: [branch 9.0.x] b75ee12a4ed6724c21f1a670b5a569ff5e043e52 Blamelist: Christopher Schultz BUILD FAILED: failed compile Sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 8.5.x updated: Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=62723
This is an automated email from the ASF dual-hosted git repository. schultz pushed a commit to branch 8.5.x in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/8.5.x by this push: new df39f20 Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=62723 df39f20 is described below commit df39f2024023fcc07cfbc69cc6b0999cb5560a68 Author: Christopher Schultz AuthorDate: Tue Aug 4 17:10:01 2020 -0400 Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=62723 Clarify the effects of some cluster channelSendOptions. Patch provided by Mitch Claborn. --- webapps/docs/changelog.xml | 4 webapps/docs/cluster-howto.xml | 22 + webapps/docs/config/cluster.xml | 44 - 3 files changed, 65 insertions(+), 5 deletions(-) diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml index dff49fb..ac90ee8 100644 --- a/webapps/docs/changelog.xml +++ b/webapps/docs/changelog.xml @@ -99,6 +99,10 @@ Clean-up / standardize the XSL files used to generate the documentation. PR provided by John Bampton. (markt) + +62723: Clarify the effects of some options for cluster +channelSendOptions. Patch provided by Mitch Claborn. +(schultz) diff --git a/webapps/docs/cluster-howto.xml b/webapps/docs/cluster-howto.xml index cce6726..09cdb2c 100644 --- a/webapps/docs/cluster-howto.xml +++ b/webapps/docs/cluster-howto.xml @@ -217,10 +217,24 @@ should be completed: sent over the wire and reinstantiated on all the other cluster nodes. Synchronous vs. asynchronous is configured using the channelSendOptions flag and is an integer value. The default value for the SimpleTcpCluster/DeltaManager combo is -8, which is asynchronous. You can read more on the send flag(overview) or the -send flag(javadoc). -During async replication, the request is returned before the data has been replicated. async replication yields shorter -request times, and synchronous replication guarantees the session to be replicated before the request returns. +8, which is asynchronous. +See the configuration reference +for more discussion on the various channelSendOptions values. + + +For convenience, channelSendOptions can be set by name(s) rather than integer, +which are then translated to their integer value upon startup. The valid option names are: +"asynchronous" (alias "async"), "byte_message" (alias "byte"), "multicast", "secure", +"synchronized_ack" (alias "sync"), "udp", "use_ack". Use comma to separate multiple names, +e.g. pass "async, multicast" for the options +SEND_OPTIONS_ASYNCHRONOUS | SEND_OPTIONS_MULTICAST. + + + You can read more on the send flag(overview) or the + send flag(javadoc). + During async replication, the request is returned before the data has been replicated. async + replication yields shorter request times, and synchronous replication guarantees the session + to be replicated before the request returns. diff --git a/webapps/docs/config/cluster.xml b/webapps/docs/config/cluster.xml index f6cd407..9211edd 100644 --- a/webapps/docs/config/cluster.xml +++ b/webapps/docs/config/cluster.xml @@ -143,7 +143,49 @@ Tomcat cluster. These include: Note that if you use ASYNC messaging it is possible for update messages for a session to be processed by the receiving nodes in a different order - to the order in which they were sent. + to the order in which they were sent. + + +The various channelSendOptions values offer a tradeoff +between throughput on the sending node and the reliability of +replication should the sending or receiving node(s) fail. Here are +some common options. "Message" could be any message sent between nodes, +but only session-change messages are considered, here. + + +channelSendOptions="8" / channelSendOptions="async" +As far as the sender is concerned, the message is "sent" +as soon as it has been placed in the queue on the sender for +transmission to the other nodes. The message may not reach any or all +of the recipient nodes and may not be successfully processed on any +nodes that it does reach. This option offers the highest throughput on +the sender but the least reliability, as the triggering request will +complete without any knowledge of the success/failure of the session +replication. + + +channelSendOptions="2" / channelSendOptions="use_ack" +The sender will block the completion of the current request until all +of the receiving nodes have acknowledged that they have received the +message, but have not necessarily processed that message. This option +will result in lower throughput on the s
buildbot failure in on tomcat-85-trunk
The Buildbot has detected a new failure on builder tomcat-85-trunk while building tomcat. Full details are available at: https://ci.apache.org/builders/tomcat-85-trunk/builds/2397 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: asf946_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-85-commit' triggered this build Build Source Stamp: [branch 8.5.x] df39f2024023fcc07cfbc69cc6b0999cb5560a68 Blamelist: Christopher Schultz BUILD FAILED: failed compile Sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch master updated: Fix XML
This is an automated email from the ASF dual-hosted git repository. schultz 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 446b7d3 Fix XML 446b7d3 is described below commit 446b7d378be45904eb41cf50fea7b1efc077665a Author: Christopher Schultz AuthorDate: Tue Aug 4 17:38:38 2020 -0400 Fix XML --- webapps/docs/changelog.xml | 1 + 1 file changed, 1 insertion(+) diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml index 17ec66b..e1c8e04 100644 --- a/webapps/docs/changelog.xml +++ b/webapps/docs/changelog.xml @@ -113,6 +113,7 @@ 62723: Clarify the effects of some options for cluster channelSendOptions. Patch provided by Mitch Claborn. (schultz) + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 9.0.x updated: Fix XML
This is an automated email from the ASF dual-hosted git repository. schultz pushed a commit to branch 9.0.x in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/9.0.x by this push: new 4b3580a Fix XML 4b3580a is described below commit 4b3580af10e7d12201cb40cd68581b2dd1f5bfa2 Author: Christopher Schultz AuthorDate: Tue Aug 4 17:38:38 2020 -0400 Fix XML --- webapps/docs/changelog.xml | 1 + 1 file changed, 1 insertion(+) diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml index 1806b15..dbcb5a6 100644 --- a/webapps/docs/changelog.xml +++ b/webapps/docs/changelog.xml @@ -109,6 +109,7 @@ 62723: Clarify the effects of some options for cluster channelSendOptions. Patch provided by Mitch Claborn. (schultz) + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 8.5.x updated: Update changelog.xml
This is an automated email from the ASF dual-hosted git repository. schultz pushed a commit to branch 8.5.x in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/8.5.x by this push: new 3f81598 Update changelog.xml 3f81598 is described below commit 3f81598de055d935daf17f6fe49cf37ba429f16f Author: Christopher Schultz AuthorDate: Tue Aug 4 17:43:03 2020 -0400 Update changelog.xml Fix XML. --- webapps/docs/changelog.xml | 1 + 1 file changed, 1 insertion(+) diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml index ac90ee8..47413b6 100644 --- a/webapps/docs/changelog.xml +++ b/webapps/docs/changelog.xml @@ -103,6 +103,7 @@ 62723: Clarify the effects of some options for cluster channelSendOptions. Patch provided by Mitch Claborn. (schultz) + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot success in on tomcat-9-trunk
The Buildbot has detected a restored build on builder tomcat-9-trunk while building tomcat. Full details are available at: https://ci.apache.org/builders/tomcat-9-trunk/builds/356 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: asf946_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-9-commit' triggered this build Build Source Stamp: [branch 9.0.x] 4b3580af10e7d12201cb40cd68581b2dd1f5bfa2 Blamelist: Christopher Schultz Build succeeded! Sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] kamnani opened a new pull request #331: Remove White Spaces and extra lines from the JSP files
kamnani opened a new pull request #331: URL: https://github.com/apache/tomcat/pull/331 The changes enables the compiler to remove excess white spaces and new lines from the JSP files & thus reduce the JVM metadata. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot success in on tomcat-85-trunk
The Buildbot has detected a restored build on builder tomcat-85-trunk while building tomcat. Full details are available at: https://ci.apache.org/builders/tomcat-85-trunk/builds/2398 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: asf946_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-85-commit' triggered this build Build Source Stamp: [branch 8.5.x] 3f81598de055d935daf17f6fe49cf37ba429f16f Blamelist: Christopher Schultz Build succeeded! Sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57661] Delay sending of 100 continue response until application tries to read request body
https://bz.apache.org/bugzilla/show_bug.cgi?id=57661 --- Comment #11 from Malay --- I took a closer look at my implementation and it is actually option (c): c) container sends it when an InputStream / Reader is first used The approach that I'm taking is to only send the '100 continue' response when the application reads the request body, there is no additional blocking involved, so it will not interfere with handling of requests with no content. Regarding requests like DELETE that do not contain content, it is not allowed for those requests to contain the "Expect: 100-continue" header, from RFC 7231 5.1.1: A client MUST NOT generate a 100-continue expectation in a request that does not include a message body. >From what I can tell, Apache HttpComponents will not add the "Expect: 100-continue" header if the content body size is zero. -- 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 57661] Delay sending of 100 continue response until application tries to read request body
https://bz.apache.org/bugzilla/show_bug.cgi?id=57661 --- Comment #12 from Michael Osipov --- (In reply to Malay from comment #11) > I took a closer look at my implementation and it is actually option (c): > c) container sends it when an InputStream / Reader is first used > > The approach that I'm taking is to only send the '100 continue' response > when the application reads the request body, there is no additional blocking > involved, so it will not interfere with handling of requests with no content. > > Regarding requests like DELETE that do not contain content, it is not > allowed for those requests to contain the "Expect: 100-continue" header, > from RFC 7231 5.1.1: > A client MUST NOT generate a 100-continue expectation in a request > that does not include a message body. > > From what I can tell, Apache HttpComponents will not add the "Expect: > 100-continue" header if the content body size is zero. Thanks for citing. I did not have this in mind. -- 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
