[Bug 66659] New: Tomcat does not send FIN message upon request by client to close TCP connection
https://bz.apache.org/bugzilla/show_bug.cgi?id=66659 Bug ID: 66659 Summary: Tomcat does not send FIN message upon request by client to close TCP connection Product: Tomcat 10 Version: 10.1.8 Hardware: PC Status: NEW Severity: normal Priority: P2 Component: Connectors Assignee: dev@tomcat.apache.org Reporter: aritzbast...@gmail.com Target Milestone: -- We are using Tomcat 10 + Spring Boot 3.1.0 to implement a notification mechanism, based on SSE (Server-Sent Events). However, when the client agent (browser) tries to close the connection sending a TCP FIN message, the server (Tomcat) answers just an ACK, instead of ACK+FIN. As a result, the server application (REST controller) does not even notice that the socket is being closed on the client side, and it will be able to send subsequent notifications (PSH messages). If client and server are directly connected, the client will respond with a RST upon next notification, and the server socket will finally be closed. But, if a proxy (such as F5 or HA Proxy) lies between the two, the proxy will silently discard PSH messages and the backend application will "think" that the notification was successfully delivered to the client. On client side, the connection will remain in FIN_WAIT_2 state for hours. For demonstration purposes, I can attach a minimal Spring Boot application showing this behavior. -- 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] 03/03: Add getSession() to SendResult
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
commit 1b1685b377f547bbece829dfcbf7f93d56624274
Author: Mark Thomas
AuthorDate: Tue Jun 20 13:46:31 2023 +0100
Add getSession() to SendResult
This aligns Tomcat 11.0.x with the latest proposals for Jakarta
WebSocket 2.2 from the Jakarta WebSocket project.
---
.../tomcat/websocket/WsRemoteEndpointImplBase.java | 24 ++
.../websocket/WsRemoteEndpointImplClient.java | 7 +++---
java/org/apache/tomcat/websocket/WsSession.java| 4 +--
.../server/WsRemoteEndpointImplServer.java | 29 --
webapps/docs/changelog.xml | 6 +
5 files changed, 42 insertions(+), 28 deletions(-)
diff --git a/java/org/apache/tomcat/websocket/WsRemoteEndpointImplBase.java
b/java/org/apache/tomcat/websocket/WsRemoteEndpointImplBase.java
index 5dc9298b6e..5717a7bfca 100644
--- a/java/org/apache/tomcat/websocket/WsRemoteEndpointImplBase.java
+++ b/java/org/apache/tomcat/websocket/WsRemoteEndpointImplBase.java
@@ -58,8 +58,6 @@ public abstract class WsRemoteEndpointImplBase implements
RemoteEndpoint {
protected static final StringManager sm =
StringManager.getManager(WsRemoteEndpointImplBase.class);
-protected static final SendResult SENDRESULT_OK = new SendResult();
-
private final Log log = LogFactory.getLog(WsRemoteEndpointImplBase.class);
// must not be static
private final StateMachine stateMachine = new StateMachine();
@@ -104,6 +102,11 @@ public abstract class WsRemoteEndpointImplBase implements
RemoteEndpoint {
}
+protected WsSession getSession() {
+return wsSession;
+}
+
+
@Override
public void setBatchingAllowed(boolean batchingAllowed) throws IOException
{
boolean oldValue = this.batchingAllowed.getAndSet(batchingAllowed);
@@ -362,7 +365,7 @@ public abstract class WsRemoteEndpointImplBase implements
RemoteEndpoint {
try {
messageParts = transformation.sendMessagePart(messageParts);
} catch (IOException ioe) {
-handler.onResult(new SendResult(ioe));
+handler.onResult(new SendResult(getSession(), ioe));
return;
}
@@ -370,7 +373,7 @@ public abstract class WsRemoteEndpointImplBase implements
RemoteEndpoint {
// that no message parts will be returned. If this is the case the
// trigger the supplied SendHandler
if (messageParts.size() == 0) {
-handler.onResult(new SendResult());
+handler.onResult(new SendResult(getSession()));
return;
}
@@ -671,7 +674,7 @@ public abstract class WsRemoteEndpointImplBase implements
RemoteEndpoint {
try (Writer w = getSendWriter()) {
((Encoder.TextStream) encoder).encode(obj, w);
}
-completion.onResult(new SendResult());
+completion.onResult(new SendResult(getSession()));
} else if (encoder instanceof Encoder.Binary) {
ByteBuffer msg = ((Encoder.Binary) encoder).encode(obj);
sendBytesByCompletion(msg, completion);
@@ -679,12 +682,12 @@ public abstract class WsRemoteEndpointImplBase implements
RemoteEndpoint {
try (OutputStream os = getSendStream()) {
((Encoder.BinaryStream) encoder).encode(obj, os);
}
-completion.onResult(new SendResult());
+completion.onResult(new SendResult(getSession()));
} else {
throw new EncodeException(obj,
sm.getString("wsRemoteEndpoint.noEncoder", obj.getClass()));
}
} catch (Exception e) {
-SendResult sr = new SendResult(e);
+SendResult sr = new SendResult(getSession(), e);
completion.onResult(sr);
}
}
@@ -848,7 +851,8 @@ public abstract class WsRemoteEndpointImplBase implements
RemoteEndpoint {
} else if (!result.isOK()) {
handler.onResult(result);
} else if (closed) {
-SendResult sr = new SendResult(new
IOException(sm.getString("wsRemoteEndpoint.closedDuringMessage")));
+SendResult sr = new SendResult(getSession(),
+new
IOException(sm.getString("wsRemoteEndpoint.closedDuringMessage")));
handler.onResult(sr);
} else {
write();
@@ -933,12 +937,12 @@ public abstract class WsRemoteEndpointImplBase implements
RemoteEndpoint {
if (flushRequired) {
outputBuffer.flip();
if (outputBuffer.remaining() == 0) {
-handler.onResult(SENDRESULT_OK);
+handler.onResult(new SendResult(endpoint.getSession()));
} else {
[tomcat] branch main updated (e0320d4894 -> 1b1685b377)
This is an automated email from the ASF dual-hosted git repository. markt pushed a change to branch main in repository https://gitbox.apache.org/repos/asf/tomcat.git from e0320d4894 Remove unnecessary test. new ab801f8a4f Fix IDE warning new 46578dc3e7 Update WebSocket API to align with latest proposals new 1b1685b377 Add getSession() to SendResult The 3 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: java/jakarta/websocket/SendResult.java | 50 +- .../tomcat/websocket/WsRemoteEndpointImplBase.java | 24 ++- .../websocket/WsRemoteEndpointImplClient.java | 7 +-- java/org/apache/tomcat/websocket/WsSession.java| 4 +- .../server/WsRemoteEndpointImplServer.java | 29 +++-- .../apache/tomcat/jdbc/pool/ConnectionPool.java| 2 +- webapps/docs/changelog.xml | 6 +++ 7 files changed, 91 insertions(+), 31 deletions(-) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] 02/03: Update WebSocket API to align with latest proposals
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
commit 46578dc3e7cc98ca907a2711ca48ecfc07042b9b
Author: Mark Thomas
AuthorDate: Tue Jun 20 10:19:10 2023 +0100
Update WebSocket API to align with latest proposals
---
java/jakarta/websocket/SendResult.java | 50 --
1 file changed, 48 insertions(+), 2 deletions(-)
diff --git a/java/jakarta/websocket/SendResult.java
b/java/jakarta/websocket/SendResult.java
index 47f5021aac..f506c881af 100644
--- a/java/jakarta/websocket/SendResult.java
+++ b/java/jakarta/websocket/SendResult.java
@@ -17,16 +17,53 @@
package jakarta.websocket;
public final class SendResult {
+private final Session session;
private final Throwable exception;
private final boolean ok;
-public SendResult(Throwable exception) {
+/**
+ * Create an instance for an unsuccessful message.
+ *
+ * @param session the WebSocket session in which the message was sent
+ * @param exception The exception describing the failure when trying to
send the message.
+ */
+public SendResult(Session session, Throwable exception) {
+this.session = session;
this.exception = exception;
this.ok = (exception == null);
}
+/**
+ * Create an instance for a successful message.
+ *
+ * @param session the WebSocket session in which the message was sent
+ */
+public SendResult(Session session) {
+this(session, null);
+}
+
+/**
+ * Create an instance for an unsuccessful message.
+ *
+ * @param exception The exception describing the failure when trying to
send the message.
+ *
+ * @deprecated Deprecated in WebSocket 2.2 and will be removed in a future
version. Use
+ * {@link #SendResult(Session, Throwable)} as a
replacement.
+ */
+@Deprecated
+public SendResult(Throwable exception) {
+this(null, exception);
+}
+
+/**
+ * Create an instance for a successful message.
+ *
+ * @deprecated Deprecated in WebSocket 2.2 and will be removed in a future
version. Use
+ * {@link #SendResult(Session, Throwable)} as a
replacement.
+ */
+@Deprecated
public SendResult() {
-this(null);
+this(null, null);
}
public Throwable getException() {
@@ -36,4 +73,13 @@ public final class SendResult {
public boolean isOK() {
return ok;
}
+
+/**
+ * The WebSocket session in which the session was sent.
+ *
+ * @return the WebSocket session in which the session was sent or {@code
null} if not known.
+ */
+public Session getSession() {
+return session;
+}
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] 01/03: Fix IDE warning
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
commit ab801f8a4f44b6baa5c5b13b80a43946e8ba738a
Author: Mark Thomas
AuthorDate: Tue Jun 20 10:18:29 2023 +0100
Fix IDE warning
---
.../src/main/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java
b/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java
index b20bb55084..702589fad5 100644
---
a/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java
+++
b/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java
@@ -111,7 +111,7 @@ public class ConnectionPool {
/**
* Executor service used to cancel Futures
*/
-private ThreadPoolExecutor cancellator = new
ThreadPoolExecutor(0,1,1000,TimeUnit.MILLISECONDS,new
LinkedBlockingQueue());
+private ThreadPoolExecutor cancellator = new
ThreadPoolExecutor(0,1,1000,TimeUnit.MILLISECONDS,new LinkedBlockingQueue<>());
/**
* reference to the JMX mbean
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1910521 - /tomcat/site/trunk/docs/.well-known/security.txt
Author: schultz Date: Tue Jun 20 17:03:16 2023 New Revision: 1910521 URL: http://svn.apache.org/viewvc?rev=1910521&view=rev Log: Update security.txt with a new expiration date. Modified: tomcat/site/trunk/docs/.well-known/security.txt Modified: tomcat/site/trunk/docs/.well-known/security.txt URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/.well-known/security.txt?rev=1910521&r1=1910520&r2=1910521&view=diff == --- tomcat/site/trunk/docs/.well-known/security.txt (original) +++ tomcat/site/trunk/docs/.well-known/security.txt Tue Jun 20 17:03:16 2023 @@ -3,7 +3,7 @@ Hash: SHA256 Contact: secur...@tomcat.apache.org Contact: https://tomcat.apache.org/security.html#Reporting_New_Security_Problems_with_Apache_Tomcat -Expires: 2023-01-01T00:00:00 +Expires: 2024-01-01T00:00:00 Acknowledgments: https://tomcat.apache.org/security.html Preferred-Languages: en Canonical: https://tomcat.apache.org/.well-known/security.txt @@ -11,17 +11,17 @@ Hiring: https://tomcat.apache.org/getinv -BEGIN PGP SIGNATURE- -iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAmKkwA8ACgkQHPApP6U8 -pFjDyw//Zkjf5tCgoXqs6OwNtEu+wxx1ZIgPWSMCSTcMNJn2w+4zfaeBpIPLIJ/i -Uz6h+jXfXkGdTizKK1DJw00eOLLz8nknb80FmtX4Hzxe4m6I1SNdJJmHg/25ud0S -jDyoDHPoYEW7VgpdTot1mOuO8E+bkGTE/rKbsl3u2uHTVOHV7yxE96DmCknKSyZx -+wdgoqemEhwv04LRd/Xlx2USl5+sazsUZO3qDJIkhb7V8C18lmk1/FALRXWkq31y -RkKoNfoJ92FgBPmmmHfUbEniDLzZUivCoqVCDUpjiPRChaWwbqzP953jqqpXeB/c -z1kaYyH1vvTnefobsvcDgN4yCJ3UrfTYQorNZTrMbbC8GVn8ZdQA/cX+sq4jvFOQ -PoUxyDu0xtacLPQ7vEL7WHB50rdAUsvjwN5X7A7/Rnl3Z4uq7nDxqkY33gaOT7Yf -3Qr9Bzzllc9TTkanDxjayrvrxWXN9c7F+Khpb48dEz5HVhEPxwtmjKSmc3Cwu8xx -rWul5EbKXwBEW8K0pMMEHs5pEZTDiA+c0jV1AfOirJB09Z9NUcRZtUm1MMhuU7x3 -IPehpw8GDIHUNkveeBUzMShIwbuFVEA/S0t4VUzSme8WG15b1w6pFCOnVV920qPx -gnPSP60KegTrV/Y4WmD9XjWTrYGCK9Y0ObCtse7X4MDMgnRaBzY= -=xtjD +iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAmSR274ACgkQHPApP6U8 +pFiP0RAAx1Ln6cugta2HcnMUTzMYpqb0Mdg4e2tcvQT5J4LFrgP5mMvSJKg3GQKG +mtQ+FBNanf865rhI8Y604vS/2sYrjkh8UYeosg/Yot0UiGxhWzmgeIoXbGB3EuAc +Awuzvr/+s/0KBXXb9ihkyYXqKEoUxtM6QCRlthJS2UkZkrrEjEEhwax0R+2qXCkp +iivjPpyb+XNPTh7Rg8t/fT2vCfHHL4KOvq8DL+p3O+x4MW4bP2fsie4P5SOr7LDg +0zsGZ234UXdStRMqjCU74/5LuswEP3TPJrobeD9yjrljwXGW8gX5DVsl2EXpRgpa +BycUpLvQ9/7RVSXIRabI6vKD0zYljarl8Uryrm/CEOO2stUG7ENBAZVDbg1nCC5p +UMRfX3a+Nigp2UVneUNpepP1vO2ltb6P+dP9T7bISRbomqjSdK+Kjc7clAUOzLH3 +0FX2DqIGViEKaRBBP+0qGYJus8hPt0c37/Sf96/4cdQUOokcDe1sMNbsS2VrNKbx +QPZusS4eFn3JzXbHoqqgs4cGoBKsWhh8Jd9w/F5HYm+0C2Rk9l89uNyknoFbAmME +jpyu1VnYr9zTkusJ+iX2cc0Ttfw7XLLowWCSYzWNvM5FBnf+tyg0qQaD4qF9mk8K +WzchMJGzV0O1hhqanXqA3jUvXtRh5stG88xt+lmrsX2URdPYs80= +=iJYn -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Signature expiration on security.txt
All, I just discovered that our security.txt file[1] had passed its "expiration date" and just updated it and re-signed it. Is there any existing process for "checking things" where we could insert a check for "is security.txt about to expire" into that workflow? Would ASF's monitoring system be appropriate for that purpose? -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Signature expiration on security.txt
On 20/06/2023 18:09, Christopher Schultz wrote: All, I just discovered that our security.txt file[1] had passed its "expiration date" and just updated it and re-signed it. Is there any existing process for "checking things" where we could insert a check for "is security.txt about to expire" into that workflow? Not that I am aware of. Would ASF's monitoring system be appropriate for that purpose? Don't know. You might need to raise an Infra ticket to ask. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66660] New: StaticMember doesn't support lazy hostname resolution (useful in K8s)
https://bz.apache.org/bugzilla/show_bug.cgi?id=0 Bug ID: 0 Summary: StaticMember doesn't support lazy hostname resolution (useful in K8s) Product: Tomcat 9 Version: 9.0.x Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Cluster Assignee: dev@tomcat.apache.org Reporter: diego.riv...@armedia.com Target Milestone: - In many (most) vendor-provided K8s environments, UDP is not allowed to be used within clusters. Thus, one is forced to use static TCP member lists pointing to all the pods that will be members of the cluster: If, for whatever reason, there's a need to boot up the pods in OrderedReady (as opposed to Parallel), then pod-0 will be booted before the others, and the StaticMember implementations will fail to resolve the hosts "pod-1" and "pod-2", because they will not exist in K8s DNS yet (b/c the pods won't exist until the first pod is in the Ready state). Thus, the first pod will be left with a broken member list: later on the members will be there, but since they weren't around during initialization, the member list is left empty. Instead of caching the hostname once on construction, the IP address (getByName() result) should only be cached if the member is confirmed to be healthy. If the member is initializing, then it's OK to resolve the hostname every time (perhaps add an attribute to limit the number of hostname resolution retries?). If the member is down and being polled for health it's Ok to resolve the hostname every time as well. One possible solution is to encapsulate MemberImpl.host in a method that does the lookup and caching/de-caching based on the member's state. -- 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 66660] StaticMember doesn't support lazy hostname resolution (useful in K8s)
https://bz.apache.org/bugzilla/show_bug.cgi?id=0 --- Comment #1 from romain.manni-bucau --- Hi, probably not yet mainstream but did you evaluated to use a custom DNS resolver impl delegating to the JVM when the host values were not known to be the pod ones? (https://bugs.openjdk.org/browse/JDK-8263693). Think it makes this usage quite straight forward, just requires to add the custom impl in tomcat launching classpath (with bootstrap.jar - or directly in the jvm classpath if embedded) and be it. Can avoid to put a specific strategy in tomcat and test with the more appropriated one before potentially giving it back, wdyt? -- 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 66660] StaticMember doesn't support lazy hostname resolution (useful in K8s)
https://bz.apache.org/bugzilla/show_bug.cgi?id=0 --- Comment #2 from Mark Thomas --- It looks like it needs more Javadoc and some documentation but I suspect using the k8s specific membership provider would be a better solution: https://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/catalina/tribes/membership/cloud/package-summary.html -- 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 66660] StaticMember doesn't support lazy hostname resolution (useful in K8s)
https://bz.apache.org/bugzilla/show_bug.cgi?id=0 --- Comment #3 from Diego Rivera --- (In reply to romain.manni-bucau from comment #1) > Hi, probably not yet mainstream but did you evaluated to use a custom DNS > resolver impl delegating to the JVM when the host values were not known to > be the pod ones? (https://bugs.openjdk.org/browse/JDK-8263693). Think it > makes this usage quite straight forward, just requires to add the custom > impl in tomcat launching classpath (with bootstrap.jar - or directly in the > jvm classpath if embedded) and be it. Can avoid to put a specific strategy > in tomcat and test with the more appropriated one before potentially giving > it back, wdyt? That wouldn't help. The problem is *when* the DNS resolution happens, not "by whom". The MemberImpl code does the resolution during construction and expects to store the IP address data - whatever it is - at that point. If resolution fails, construction fails and thus the member isn't added to the cluster - i.e. there's no provision for an "expected member": the member's hostname is required to exist at the moment the object is instantiated. Naturally we can't add an IP address b/c no such address exists yet (or else we'd already have a hostname). -- 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 66660] StaticMember doesn't support lazy hostname resolution (useful in K8s)
https://bz.apache.org/bugzilla/show_bug.cgi?id=0 --- Comment #4 from Diego Rivera --- (In reply to Mark Thomas from comment #2) > It looks like it needs more Javadoc and some documentation but I suspect > using the k8s specific membership provider would be a better solution: > > https://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/catalina/tribes/ > membership/cloud/package-summary.html We're very much trying to avoid granting access to the K8s infrastructure to our pods, for security reasons. I saw that class and it piqued my interest, but quickly fizzled when I saw how it works. We have the same conundrum: when it fetches the membership list, only one pod exists (the one being booted up), so we'd be back to square one regarding "expected members which don't yet exist or aren't yet available". The problem is that the StaticMember expects all members to exist upon instantiation, whereas this may not always be the case. -- 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 66660] StaticMember doesn't support lazy hostname resolution (useful in K8s)
https://bz.apache.org/bugzilla/show_bug.cgi?id=0 --- Comment #5 from Diego Rivera --- To clarify: the problem is that MemberImpl expects the target member to exist or be resolvable at object construction. If that resolution fails, then it pukes out and the member is then discarded by the overarching infrastructure, even if the member will become available shortly thereafter. -- 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 66660] StaticMember doesn't support lazy hostname resolution (useful in K8s)
https://bz.apache.org/bugzilla/show_bug.cgi?id=0 --- Comment #6 from Remy Maucherat --- (In reply to Diego Rivera from comment #4) > (In reply to Mark Thomas from comment #2) > > It looks like it needs more Javadoc and some documentation but I suspect > > using the k8s specific membership provider would be a better solution: > > > > https://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/catalina/tribes/ > > membership/cloud/package-summary.html > > We're very much trying to avoid granting access to the K8s infrastructure to > our pods, for security reasons. I don't really understand the security concern since this is so granular, and it seems the whole point. But anyway, there is also the K8 DNS based membership provider: https://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/catalina/tribes/membership/cloud/DNSMembershipProvider.html I personally prefer the regular provider since it is more reliable, though. > I saw that class and it piqued my interest, but quickly fizzled when I saw > how it works. We have the same conundrum: when it fetches the membership > list, only one pod exists (the one being booted up), so we'd be back to > square one regarding "expected members which don't yet exist or aren't yet > available". > > The problem is that the StaticMember expects all members to exist upon > instantiation, whereas this may not always be the case. Sure, but you're asking for a dynamic static membership list here, basically. -- 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 66660] StaticMember doesn't support lazy hostname resolution (useful in K8s)
https://bz.apache.org/bugzilla/show_bug.cgi?id=0 --- Comment #7 from Diego Rivera --- > Sure, but you're asking for a dynamic static membership list here, basically. Kind of, but not. The only thing "dynamic" is the IP address to which each hostname would resolve to. If the hostname string is an IP address, well then so be it - there's no updating it and its end result will always be the same. What I'm asking for is a static membership list, with static hostname *strings*, where the resulting IP address said strings resolve to is allowed to change during the life of the Member. Also, I'm not saying that the name-to-address mapping should be allowed to change at any arbitrary moment: it should only be set once the member is confirmed to exist, and should only be cleared if the member disappears. The hostname string wouldn't change - only the IP address. The special edge case where the hostname string is an actual IP address really doesn't need any special handling as the resulting IP bytes won't ever change, and the overhead of computing them is negligible in the grand scheme of things. So yes - a little bit of dynamism, but not enough to require a significant rewrite of the Static membership classes (at least, I hope not :D). -- 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 10.1.x updated: Further fix for regression in previous BZ 66574 fix.
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 10.1.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/10.1.x by this push:
new d72b0fe4c7 Further fix for regression in previous BZ 66574 fix.
d72b0fe4c7 is described below
commit d72b0fe4c77bf0c690d526b22646ea5fafd9227f
Author: Mark Thomas
AuthorDate: Tue Jun 20 22:53:16 2023 +0100
Further fix for regression in previous BZ 66574 fix.
Both new states need to be accounted for to fix the regression.
---
java/org/apache/tomcat/websocket/WsSession.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/java/org/apache/tomcat/websocket/WsSession.java
b/java/org/apache/tomcat/websocket/WsSession.java
index 0c75f92184..d7eab00daa 100644
--- a/java/org/apache/tomcat/websocket/WsSession.java
+++ b/java/org/apache/tomcat/websocket/WsSession.java
@@ -459,7 +459,7 @@ public class WsSession implements Session {
@Override
public boolean isOpen() {
-return state.get() == State.OPEN || state.get() ==
State.OUTPUT_CLOSING;
+return state.get() == State.OPEN || state.get() ==
State.OUTPUT_CLOSING || state.get() == State.CLOSING;
}
-
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: Further fix for regression in previous BZ 66574 fix.
This is an automated email from the ASF dual-hosted git repository.
markt 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 ac297f1ab8 Further fix for regression in previous BZ 66574 fix.
ac297f1ab8 is described below
commit ac297f1ab89690e762f088c0253c79cd653a4dfc
Author: Mark Thomas
AuthorDate: Tue Jun 20 22:53:16 2023 +0100
Further fix for regression in previous BZ 66574 fix.
Both new states need to be accounted for to fix the regression.
---
java/org/apache/tomcat/websocket/WsSession.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/java/org/apache/tomcat/websocket/WsSession.java
b/java/org/apache/tomcat/websocket/WsSession.java
index 3d5ebdbf10..602e14b671 100644
--- a/java/org/apache/tomcat/websocket/WsSession.java
+++ b/java/org/apache/tomcat/websocket/WsSession.java
@@ -542,7 +542,7 @@ public class WsSession implements Session {
@Override
public boolean isOpen() {
-return state.get() == State.OPEN || state.get() ==
State.OUTPUT_CLOSING;
+return state.get() == State.OPEN || state.get() ==
State.OUTPUT_CLOSING || state.get() == State.CLOSING;
}
-
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: Further fix for regression in previous BZ 66574 fix.
This is an automated email from the ASF dual-hosted git repository.
markt 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 70ccf2a624 Further fix for regression in previous BZ 66574 fix.
70ccf2a624 is described below
commit 70ccf2a624b5dba544d1f77d210c27e713023a3a
Author: Mark Thomas
AuthorDate: Tue Jun 20 22:53:16 2023 +0100
Further fix for regression in previous BZ 66574 fix.
Both new states need to be accounted for to fix the regression.
---
java/org/apache/tomcat/websocket/WsSession.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/java/org/apache/tomcat/websocket/WsSession.java
b/java/org/apache/tomcat/websocket/WsSession.java
index 3d5ebdbf10..602e14b671 100644
--- a/java/org/apache/tomcat/websocket/WsSession.java
+++ b/java/org/apache/tomcat/websocket/WsSession.java
@@ -542,7 +542,7 @@ public class WsSession implements Session {
@Override
public boolean isOpen() {
-return state.get() == State.OPEN || state.get() ==
State.OUTPUT_CLOSING;
+return state.get() == State.OPEN || state.get() ==
State.OUTPUT_CLOSING || state.get() == State.CLOSING;
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch main updated: Further fix for regression in previous BZ 66574 fix.
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new 1403f0ee85 Further fix for regression in previous BZ 66574 fix.
1403f0ee85 is described below
commit 1403f0ee854dcee6a08341c38deffee457fac03c
Author: Mark Thomas
AuthorDate: Tue Jun 20 22:53:16 2023 +0100
Further fix for regression in previous BZ 66574 fix.
Both new states need to be accounted for to fix the regression.
---
java/org/apache/tomcat/websocket/WsSession.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/java/org/apache/tomcat/websocket/WsSession.java
b/java/org/apache/tomcat/websocket/WsSession.java
index 41cc389eae..d00989e754 100644
--- a/java/org/apache/tomcat/websocket/WsSession.java
+++ b/java/org/apache/tomcat/websocket/WsSession.java
@@ -459,7 +459,7 @@ public class WsSession implements Session {
@Override
public boolean isOpen() {
-return state.get() == State.OPEN || state.get() ==
State.OUTPUT_CLOSING;
+return state.get() == State.OPEN || state.get() ==
State.OUTPUT_CLOSING || state.get() == State.CLOSING;
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66660] StaticMember doesn't support lazy hostname resolution (useful in K8s)
https://bz.apache.org/bugzilla/show_bug.cgi?id=0 --- Comment #8 from romain.manni-bucau --- Facade your pods by services or just impl a custom.discovery but static one looks like a wrong usage for you and not willing to use k8s api will require another registration mechanism anyway -- 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 11, Java 21 and Windows 32-bit support
Mark, On 6/15/23 05:31, Mark Thomas wrote: All, I'm currently looking at adding the Windows specific binary distributions to Maven Central as a result of PR #609 [1]. That got me thinking whether Windows 32-bit was still supported. Some quick research found that: - The only currently supported 32-bit version of Windows is Windows 10 which reaches EOL on 2025-10-14 - OpenJDK only provides 64-bit Windows releases for Java 20 - Oracle only provides 64-bit Windows releases for Java 9 onwards - The Java 21 EA releases only include 64-bit builds for Windows - The latest Temurin release for 32-bit Windows is Java 19 - The latest Azul release for 32-bit Windows is Java 17 Given the above, I think we can safely: - plan to stop providing 32-bit Windows builds after 2025-10-14 - remove 32-bit Windows builds from Tomcat 11 Microsoft has sometimes allowed customers to stick with "unsupported" versions of Windows my just paying for super-secret-double-extended-support lifetimes. I'm not sure how they will feel about that EOY 2025 for Windows 10, but it could happen. Given that the only remaining supported 32-bit Windows operating system is a consumer one (the last Windows server OS to support 32-bit was Sever 2008) do we want to drop 32-bit support from any other products and/or versions? I'm thinking about Tomcat Native, Connectors (mod_jk & ISAPI redirector), and the earlier Tomcat versions. Personally, I'm leaning towards not making any further changes until after 2025-10-14 but what does everyone else think? Certainly there's no reason to change anything just yet, but this is a reasonable conversation to have starting now. Another data point: Apache Lounge (Windows builds for httpd and related modules) only does 64-bit builds for mod_jk. I didn't look at archives to see how far back in time you have to go in order to get a 32-bit build. Given that we bundle libtcnative with Tomcat but do not build it on-demand for each release (that is, we just pull the existing binaries) and we should continue to bundle both 32-bit and 64-bit libtcnative builds with Tomcat 9 semi-indefinitely, I think it's actually more work to remove the 32-bit builds from Tomcat 10, 11, etc. than it is to leave them in, no? 32-bit builds for the installer/uninstaller and mod_jk seem more obvious. I think these days it's /much/ more likely that someone is running a 32-bit JVM on a 64-bit OS than on a 32-bit OS. So it really doesn't matter if the installer/uninstaller are available as 32-bit as long as the installer installs the arch-appropriate libtcnative. -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 11, Java 21 and Windows 32-bit support
On 20/06/2023 23:34, Christopher Schultz wrote: Mark, On 6/15/23 05:31, Mark Thomas wrote: All, I'm currently looking at adding the Windows specific binary distributions to Maven Central as a result of PR #609 [1]. That got me thinking whether Windows 32-bit was still supported. Some quick research found that: - The only currently supported 32-bit version of Windows is Windows 10 which reaches EOL on 2025-10-14 - OpenJDK only provides 64-bit Windows releases for Java 20 - Oracle only provides 64-bit Windows releases for Java 9 onwards - The Java 21 EA releases only include 64-bit builds for Windows - The latest Temurin release for 32-bit Windows is Java 19 - The latest Azul release for 32-bit Windows is Java 17 Given the above, I think we can safely: - plan to stop providing 32-bit Windows builds after 2025-10-14 - remove 32-bit Windows builds from Tomcat 11 Microsoft has sometimes allowed customers to stick with "unsupported" versions of Windows my just paying for super-secret-double-extended-support lifetimes. I'm not sure how they will feel about that EOY 2025 for Windows 10, but it could happen. Indeed. But there are also options to pay for extended Tomcat support. We are pretty generous with out support lifetimes so I think ending support for an OS when it officially reaches EOL seems reasonable. Given that the only remaining supported 32-bit Windows operating system is a consumer one (the last Windows server OS to support 32-bit was Sever 2008) do we want to drop 32-bit support from any other products and/or versions? I'm thinking about Tomcat Native, Connectors (mod_jk & ISAPI redirector), and the earlier Tomcat versions. Personally, I'm leaning towards not making any further changes until after 2025-10-14 but what does everyone else think? Certainly there's no reason to change anything just yet, but this is a reasonable conversation to have starting now. Another data point: Apache Lounge (Windows builds for httpd and related modules) only does 64-bit builds for mod_jk. I didn't look at archives to see how far back in time you have to go in order to get a 32-bit build. Ah. Interesting. I didn't know that. Given that we bundle libtcnative with Tomcat but do not build it on-demand for each release (that is, we just pull the existing binaries) and we should continue to bundle both 32-bit and 64-bit libtcnative builds with Tomcat 9 semi-indefinitely, I think it's actually more work to remove the 32-bit builds from Tomcat 10, 11, etc. than it is to leave them in, no? It is, but by that argument we'd never remove anything that was no longer used / needed. The changes for Tomcat 11 are already in place so... 32-bit builds for the installer/uninstaller and mod_jk seem more obvious. I think these days it's /much/ more likely that someone is running a 32-bit JVM on a 64-bit OS than on a 32-bit OS. So it really doesn't matter if the installer/uninstaller are available as 32-bit as long as the installer installs the arch-appropriate libtcnative. I'm fairly sure the installer is 32-bit and I know it does auto-detect the correct architecture from the JVM. That is a good point about 32-bit JVMs. It might be the case that we need to support 32-bit Tomcat Native as long as there are supported Tomcat versions that run on (supported? - we've never been that concerned about Java versions going out of support) Java versions that are available for 32-bit. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
