Re: [jetty-users] Missing http2-hpack jar causes connection to time out rather than throw an exception
Looks like chatgpt is hallucinating again. -joakim On Tue, Sep 5, 2023, 5:47 PM Shawn Heisey via jetty-users < jetty-users@eclipse.org> wrote: > On 9/5/23 02:40, Simone Bordet wrote: > > Do you have pointers? > > > > The RFC is quite clear that HPACK is mandatory for HTTP/2: > > > https://www.rfc-editor.org/rfc/rfc9113.html#name-field-section-compression-a > > I asked chatgpt. This is the full response: > > --- > HTTP/2 does not strictly require HPACK support, but HPACK is a critical > component of the HTTP/2 protocol for efficient header compression. HPACK > is used to reduce the overhead of sending headers in each HTTP/2 request > and response, which helps improve the performance of the protocol. > > In the context you mentioned, the HTTP client library (Jetty HTTP > client) likely relies on HPACK for header compression when making HTTP/2 > requests. If the HTTP client library is missing the http2-hpack JAR or > is not properly configured to use HPACK, it can lead to issues like > timeouts and inefficient header handling. > > So, while HTTP/2 technically can be operated without HPACK, it's highly > recommended to have HPACK support for proper functioning and optimal > performance. Without HPACK, the benefits of header compression provided > by HTTP/2 would be lost, which could result in suboptimal performance > and potentially even issues like the timeouts you described. > --- > > I am aware that chatgpt is not perfect. I've used it to give me code > writing pointers, and I usually find that its code suggestions only > serve to give me ideas, they aren't often usable as-is. But so far it > seems to be pretty good at covering facts established before 2021. I > think details like this about RFCs fall into that category. But you are > likely a far better expert than chatgpt on this topic. > > What exactly are you seeing in the RFC that says it's required? I > believe you, but I am apparently blind, because I can't see it. > > Thanks, > Shawn > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Missing http2-hpack jar causes connection to time out rather than throw an exception
On 9/5/23 02:40, Simone Bordet wrote: Do you have pointers? The RFC is quite clear that HPACK is mandatory for HTTP/2: https://www.rfc-editor.org/rfc/rfc9113.html#name-field-section-compression-a I asked chatgpt. This is the full response: --- HTTP/2 does not strictly require HPACK support, but HPACK is a critical component of the HTTP/2 protocol for efficient header compression. HPACK is used to reduce the overhead of sending headers in each HTTP/2 request and response, which helps improve the performance of the protocol. In the context you mentioned, the HTTP client library (Jetty HTTP client) likely relies on HPACK for header compression when making HTTP/2 requests. If the HTTP client library is missing the http2-hpack JAR or is not properly configured to use HPACK, it can lead to issues like timeouts and inefficient header handling. So, while HTTP/2 technically can be operated without HPACK, it's highly recommended to have HPACK support for proper functioning and optimal performance. Without HPACK, the benefits of header compression provided by HTTP/2 would be lost, which could result in suboptimal performance and potentially even issues like the timeouts you described. --- I am aware that chatgpt is not perfect. I've used it to give me code writing pointers, and I usually find that its code suggestions only serve to give me ideas, they aren't often usable as-is. But so far it seems to be pretty good at covering facts established before 2021. I think details like this about RFCs fall into that category. But you are likely a far better expert than chatgpt on this topic. What exactly are you seeing in the RFC that says it's required? I believe you, but I am apparently blind, because I can't see it. Thanks, Shawn ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Jetty 12.0.x blocks server-to-server requests (and in case of 12.0.1 issues warning: WARN :oeju.Blocker:qtp686466458-43: Blocking.Callback incomplete)
There is still not enough information to work with. With the scant information you have provided, there are tens of thousands of possible setups and even more use cases for your scenario. Out of our 35,800 test cases, we don't have one that produces what you are describing. We need far more details, an open issue, and perhaps logging at debug level (of the entire request from receive, parsing, processing, response commit, response write, to error) would help. But a reproduction case would be most useful. Joakim Erdfelt / joa...@webtide.com On Tue, Sep 5, 2023 at 9:24 AM Silvio Bierman wrote: > Hi Joakim, > > Actually it is not very complicated, apart from my setup being an embedded > Jetty 12.0.x (ee10, http/2). I do not know what a callback is in this > context and therefore I do not know where to start looking for what I am > doing wrong. > > The application receives a HTTPS POST request that is sent from inside a > page using an async XMLHttpRequest. The handling code processes the > application specific payload and returns a similarly encoded response. That > is when the warning is printed to stderr. > > It could be something in my embedded server setup code. Or it is an error > in the way the application wraps requests/responses when forwarding them to > the generic application level. Perhaps holding on to request or response > objects too long or something similar. Blocking.Callback incomplete is a > bit generic. Any explanation of what the warning hints at would be helpful > to figure this out. > > Previous experience indicates that whenever Jetty issues an error or > warning I am doing something wrong. But this is a new phenomenon that I > never witnessed until 12.0.1 so I was hoping it might be something obvious. > > Cheers, > > Silvio > > > On 05-09-2023 16:00, Joakim Erdfelt wrote: > > Like Simone said, file an issue. > https://github.com/eclipse/jetty.project/issues/new/choose > > Please provide as many details as possible, a reproducer is ideal! > > This is way out of scope for what the jetty-users mailing list can handle. > We need to share code, share logs, collect data, etc. > There is something fundamentally wrong with the callbacks, but which ones? > from where? How does the request flow through Jetty? How are you using > Jetty? (code helps) > > Joakim Erdfelt / joa...@webtide.com > > > On Tue, Sep 5, 2023 at 8:47 AM Silvio Bierman via jetty-users < > jetty-users@eclipse.org> wrote: > >> Hi Simone, >> >> Well, in the process of collecting more details and trying to describe >> the issue more clearly I discovered that I am delusional. The requests >> are not blocked at all but some other error in my test setup prevented >> them from being handled properly. I mistakenly concluded that the warning >> >> WARN :oeju.Blocker:qtp686466458-43: Blocking.Callback incomplete >> >> was in any way a result of the requests actually being blocked. Please >> ignore my previous message about this. >> >> I would however like to know what the warning means and why it is >> manifesting itself now with 12.0.1. It is starting to clog my >> stderr-logs... >> >> Thank you, >> >> Silvio >> >> >> >> On 04-09-2023 18:12, Simone Bordet wrote: >> > Silvio, >> > >> > On Mon, Sep 4, 2023 at 4:33 PM Silvio Bierman via jetty-users >> > wrote: >> >> This happens on embedded Jetty (ee10 - http/2) HTTPS requests from the >> >> embedding application (standard Java HttpServletRequest, URL that >> >> contains the global/external host name and the local port number) that >> >> is supposed to be handled by the current running process (and thus >> Jetty >> >> server). The local port is necessary because using the default port >> from >> >> localhost will bypass firewall NAT and therefore fail. >> >> I have traced this warning to >> >> jetty-core/jetty-util/src/main/java/org/eclipse/jetty/util/Blocker.java >> >> but do not understand what is going on there. >> >> >> >> The same URL can be evaluated from a command line on the same server >> >> without issue, only evaluation from the process itself is blocked. >> >> >> >> The same code works on Jetty11. It blocks silently on 12.0.0 but 12.0.1 >> >> logs this message to stderr. >> > Please file an issue with more details. >> > If you have a simple reproduce will be best. >> > I don't quite follow the "local port, default port, firewall NAT" >> > part, too little context. >> > >> >> ___ >> jetty-users mailing list >> jetty-users@eclipse.org >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/jetty-users >> > > ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Jetty 12.0.x blocks server-to-server requests (and in case of 12.0.1 issues warning: WARN :oeju.Blocker:qtp686466458-43: Blocking.Callback incomplete)
Hi Joakim, Actually it is not very complicated, apart from my setup being an embedded Jetty 12.0.x (ee10, http/2). I do not know what a callback is in this context and therefore I do not know where to start looking for what I am doing wrong. The application receives a HTTPS POST request that is sent from inside a page using an async XMLHttpRequest. The handling code processes the application specific payload and returns a similarly encoded response. That is when the warning is printed to stderr. It could be something in my embedded server setup code. Or it is an error in the way the application wraps requests/responses when forwarding them to the generic application level. Perhaps holding on to request or response objects too long or something similar. Blocking.Callback incomplete is a bit generic. Any explanation of what the warning hints at would be helpful to figure this out. Previous experience indicates that whenever Jetty issues an error or warning I am doing something wrong. But this is a new phenomenon that I never witnessed until 12.0.1 so I was hoping it might be something obvious. Cheers, Silvio On 05-09-2023 16:00, Joakim Erdfelt wrote: Like Simone said, file an issue. https://github.com/eclipse/jetty.project/issues/new/choose Please provide as many details as possible, a reproducer is ideal! This is way out of scope for what the jetty-users mailing list can handle. We need to share code, share logs, collect data, etc. There is something fundamentally wrong with the callbacks, but which ones? from where? How does the request flow through Jetty? How are you using Jetty? (code helps) Joakim Erdfelt / joa...@webtide.com On Tue, Sep 5, 2023 at 8:47 AM Silvio Bierman via jetty-users wrote: Hi Simone, Well, in the process of collecting more details and trying to describe the issue more clearly I discovered that I am delusional. The requests are not blocked at all but some other error in my test setup prevented them from being handled properly. I mistakenly concluded that the warning WARN :oeju.Blocker:qtp686466458-43: Blocking.Callback incomplete was in any way a result of the requests actually being blocked. Please ignore my previous message about this. I would however like to know what the warning means and why it is manifesting itself now with 12.0.1. It is starting to clog my stderr-logs... Thank you, Silvio On 04-09-2023 18:12, Simone Bordet wrote: > Silvio, > > On Mon, Sep 4, 2023 at 4:33 PM Silvio Bierman via jetty-users > wrote: >> This happens on embedded Jetty (ee10 - http/2) HTTPS requests from the >> embedding application (standard Java HttpServletRequest, URL that >> contains the global/external host name and the local port number) that >> is supposed to be handled by the current running process (and thus Jetty >> server). The local port is necessary because using the default port from >> localhost will bypass firewall NAT and therefore fail. >> I have traced this warning to >> jetty-core/jetty-util/src/main/java/org/eclipse/jetty/util/Blocker.java >> but do not understand what is going on there. >> >> The same URL can be evaluated from a command line on the same server >> without issue, only evaluation from the process itself is blocked. >> >> The same code works on Jetty11. It blocks silently on 12.0.0 but 12.0.1 >> logs this message to stderr. > Please file an issue with more details. > If you have a simple reproduce will be best. > I don't quite follow the "local port, default port, firewall NAT" > part, too little context. > ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Jetty 12.0.x blocks server-to-server requests (and in case of 12.0.1 issues warning: WARN :oeju.Blocker:qtp686466458-43: Blocking.Callback incomplete)
Like Simone said, file an issue. https://github.com/eclipse/jetty.project/issues/new/choose Please provide as many details as possible, a reproducer is ideal! This is way out of scope for what the jetty-users mailing list can handle. We need to share code, share logs, collect data, etc. There is something fundamentally wrong with the callbacks, but which ones? from where? How does the request flow through Jetty? How are you using Jetty? (code helps) Joakim Erdfelt / joa...@webtide.com On Tue, Sep 5, 2023 at 8:47 AM Silvio Bierman via jetty-users < jetty-users@eclipse.org> wrote: > Hi Simone, > > Well, in the process of collecting more details and trying to describe > the issue more clearly I discovered that I am delusional. The requests > are not blocked at all but some other error in my test setup prevented > them from being handled properly. I mistakenly concluded that the warning > > WARN :oeju.Blocker:qtp686466458-43: Blocking.Callback incomplete > > was in any way a result of the requests actually being blocked. Please > ignore my previous message about this. > > I would however like to know what the warning means and why it is > manifesting itself now with 12.0.1. It is starting to clog my > stderr-logs... > > Thank you, > > Silvio > > > > On 04-09-2023 18:12, Simone Bordet wrote: > > Silvio, > > > > On Mon, Sep 4, 2023 at 4:33 PM Silvio Bierman via jetty-users > > wrote: > >> This happens on embedded Jetty (ee10 - http/2) HTTPS requests from the > >> embedding application (standard Java HttpServletRequest, URL that > >> contains the global/external host name and the local port number) that > >> is supposed to be handled by the current running process (and thus Jetty > >> server). The local port is necessary because using the default port from > >> localhost will bypass firewall NAT and therefore fail. > >> I have traced this warning to > >> jetty-core/jetty-util/src/main/java/org/eclipse/jetty/util/Blocker.java > >> but do not understand what is going on there. > >> > >> The same URL can be evaluated from a command line on the same server > >> without issue, only evaluation from the process itself is blocked. > >> > >> The same code works on Jetty11. It blocks silently on 12.0.0 but 12.0.1 > >> logs this message to stderr. > > Please file an issue with more details. > > If you have a simple reproduce will be best. > > I don't quite follow the "local port, default port, firewall NAT" > > part, too little context. > > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Jetty 12.0.x blocks server-to-server requests (and in case of 12.0.1 issues warning: WARN :oeju.Blocker:qtp686466458-43: Blocking.Callback incomplete)
Hi Simone, Well, in the process of collecting more details and trying to describe the issue more clearly I discovered that I am delusional. The requests are not blocked at all but some other error in my test setup prevented them from being handled properly. I mistakenly concluded that the warning WARN :oeju.Blocker:qtp686466458-43: Blocking.Callback incomplete was in any way a result of the requests actually being blocked. Please ignore my previous message about this. I would however like to know what the warning means and why it is manifesting itself now with 12.0.1. It is starting to clog my stderr-logs... Thank you, Silvio On 04-09-2023 18:12, Simone Bordet wrote: Silvio, On Mon, Sep 4, 2023 at 4:33 PM Silvio Bierman via jetty-users wrote: This happens on embedded Jetty (ee10 - http/2) HTTPS requests from the embedding application (standard Java HttpServletRequest, URL that contains the global/external host name and the local port number) that is supposed to be handled by the current running process (and thus Jetty server). The local port is necessary because using the default port from localhost will bypass firewall NAT and therefore fail. I have traced this warning to jetty-core/jetty-util/src/main/java/org/eclipse/jetty/util/Blocker.java but do not understand what is going on there. The same URL can be evaluated from a command line on the same server without issue, only evaluation from the process itself is blocked. The same code works on Jetty11. It blocks silently on 12.0.0 but 12.0.1 logs this message to stderr. Please file an issue with more details. If you have a simple reproduce will be best. I don't quite follow the "local port, default port, firewall NAT" part, too little context. ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Missing http2-hpack jar causes connection to time out rather than throw an exception
Hi, On Tue, Sep 5, 2023 at 1:24 AM Shawn Heisey via jetty-users wrote: > > On 9/4/23 13:49, Shawn Heisey via jetty-users wrote: > > * Proceed without HPACK, logging a message at WARN about it. This > > assumes that http2 CAN operate without hpack. If http2 requires hpack, > > then I think it should not be in a separate jar from the main http2 > > implementation. I read through the http2 RFC when it was first > > released, but I admit that I do not remember whether or not hpack was > > required. > > I have learned that hpack is not *required* by http2, Do you have pointers? The RFC is quite clear that HPACK is mandatory for HTTP/2: https://www.rfc-editor.org/rfc/rfc9113.html#name-field-section-compression-a -- Simone Bordet http://cometd.org http://webtide.com Developer advice, training, services and support from the Jetty & CometD experts. ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Exception in Jetty 12.0.1
I've done a draft PR to potentially fix this: https://github.com/eclipse/jetty.project/pull/10479 But we need to actually write a test to confirm the diagnosis first. On Tue, 5 Sept 2023 at 17:44, Jan Bartel via jetty-users < jetty-users@eclipse.org> wrote: > Silvio, > > > This looks like a url with the sessionid encoded in the url, but it is > incomplete. It looks like the url just contains JSESSIONID, whereas it > should be JSESSIONID=. > > I don't think we changed the way we parse the sessionid from the url since > at least jetty 10, but I could be wrong, I don't have my computer in front > of me. > > Will look into it. > > > Jan > > On Mon, 4 Sept 2023, 22:10 Silvio Bierman via jetty-users, < > jetty-users@eclipse.org> wrote: > >> I do not know exactly which request causes the issue since I have not yet >> debugged that. There may be a UUID in the parameter list but these have >> length 36. The issue only occurs in 12.0.1 so I doubt the URL-paramaters >> are encoded incorrectly. We never use application character data in URL >> parameters so it is unlikely that any special characters are in there. >> >> >> On 04-09-2023 13:58, Bill Ross via jetty-users wrote: >> >> I wonder if this could be a string encoding issue? Can you think of any >> strings/params that are this long? >> >> 1234567890123456789012345678901234 >> >> >> 2023-09-04 13:39:27.421:WARN :oejs.Response:qtp105374791-42: writeError: >> status=500, message=java.lang.StringIndexOutOfBoundsException: Index 34 out >> of bounds for length 34, >> response=org.eclipse.jetty.ee10.servlet.ServletContextResponse@77c7bf1 >> java.lang.StringIndexOutOfBoundsException: Index 34 out of bounds for >> length 34 >> at >> java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:55) >> at >> java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:52) >> at >> java.base/jdk.internal.util.Preconditions$4.apply(Preconditions.java:213) >> at >> java.base/jdk.internal.util.Preconditions$4.apply(Preconditions.java:210) >> at >> java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:98) >> at >> java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106) >> at >> java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302) >> at java.base/java.lang.String.checkIndex(String.java:4575) >> at java.base/java.lang.StringLatin1.charAt(StringLatin1.java:46) >> at java.base/java.lang.String.charAt(String.java:1535) >> >> >> --- >> -- >> >> Phobrain.com >> >> >> On 2023-09-04 04:45, Silvio Bierman via jetty-users wrote: >> >> I get a runtime exception when using Jetty 12.0.1 in embedded mode >> (http/2). I have to add that i call SessionIdManager.setWorkerName(null) to >> get rid of the node id in the session ID (which has always worked for >> previous versions). >> >> 2023-09-04 13:39:27.421:WARN :oejs.Response:qtp105374791-42: writeError: >> status=500, message=java.lang.StringIndexOutOfBoundsException: Index 34 out >> of bounds for length 34, >> response=org.eclipse.jetty.ee10.servlet.ServletContextResponse@77c7bf1 >> java.lang.StringIndexOutOfBoundsException: Index 34 out of bounds for >> length 34 >> at >> java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:55) >> at >> java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:52) >> at >> java.base/jdk.internal.util.Preconditions$4.apply(Preconditions.java:213) >> at >> java.base/jdk.internal.util.Preconditions$4.apply(Preconditions.java:210) >> at >> java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:98) >> at >> java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106) >> at >> java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302) >> at java.base/java.lang.String.checkIndex(String.java:4575) >> at java.base/java.lang.StringLatin1.charAt(StringLatin1.java:46) >> at java.base/java.lang.String.charAt(String.java:1535) >> at >> org.eclipse.jetty.session.AbstractSessionManager.resolveRequestedSessionId(AbstractSessionManager.java:1261) >> at >> org.eclipse.jetty.ee10.servlet.SessionHandler.handle(SessionHandler.java:652) >> at >> org.eclipse.jetty.server.handler.ContextHandler.handle(ContextHandler.java:811) >> at >> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:177) >> at org.eclipse.jetty.server.Handler$Wrapper.handle(Handler.java:712) >> at org.eclipse.jetty.server.Server.handle(Server.java:176) >> at >> org.eclipse.jetty.server.internal.HttpChannelState$HandlerInvoker.run(HttpChannelState.java:648) >> at >> org.eclipse.jetty.util.thread.Invocable$ReadyTask.run(Invocable.java:105) >> at >> org.eclipse.jetty.http2.server.internal.HttpStreamOverHTTP2$1.run(HttpStreamOverHTTP2.java:129) >> at >>
Re: [jetty-users] Exception in Jetty 12.0.1
Silvio, This looks like a url with the sessionid encoded in the url, but it is incomplete. It looks like the url just contains JSESSIONID, whereas it should be JSESSIONID=. I don't think we changed the way we parse the sessionid from the url since at least jetty 10, but I could be wrong, I don't have my computer in front of me. Will look into it. Jan On Mon, 4 Sept 2023, 22:10 Silvio Bierman via jetty-users, < jetty-users@eclipse.org> wrote: > I do not know exactly which request causes the issue since I have not yet > debugged that. There may be a UUID in the parameter list but these have > length 36. The issue only occurs in 12.0.1 so I doubt the URL-paramaters > are encoded incorrectly. We never use application character data in URL > parameters so it is unlikely that any special characters are in there. > > > On 04-09-2023 13:58, Bill Ross via jetty-users wrote: > > I wonder if this could be a string encoding issue? Can you think of any > strings/params that are this long? > > 1234567890123456789012345678901234 > > > 2023-09-04 13:39:27.421:WARN :oejs.Response:qtp105374791-42: writeError: > status=500, message=java.lang.StringIndexOutOfBoundsException: Index 34 out > of bounds for length 34, > response=org.eclipse.jetty.ee10.servlet.ServletContextResponse@77c7bf1 > java.lang.StringIndexOutOfBoundsException: Index 34 out of bounds for > length 34 > at > java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:55) > at > java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:52) > at > java.base/jdk.internal.util.Preconditions$4.apply(Preconditions.java:213) > at > java.base/jdk.internal.util.Preconditions$4.apply(Preconditions.java:210) > at > java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:98) > at > java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106) > at > java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302) > at java.base/java.lang.String.checkIndex(String.java:4575) > at java.base/java.lang.StringLatin1.charAt(StringLatin1.java:46) > at java.base/java.lang.String.charAt(String.java:1535) > > > --- > -- > > Phobrain.com > > > On 2023-09-04 04:45, Silvio Bierman via jetty-users wrote: > > I get a runtime exception when using Jetty 12.0.1 in embedded mode > (http/2). I have to add that i call SessionIdManager.setWorkerName(null) to > get rid of the node id in the session ID (which has always worked for > previous versions). > > 2023-09-04 13:39:27.421:WARN :oejs.Response:qtp105374791-42: writeError: > status=500, message=java.lang.StringIndexOutOfBoundsException: Index 34 out > of bounds for length 34, > response=org.eclipse.jetty.ee10.servlet.ServletContextResponse@77c7bf1 > java.lang.StringIndexOutOfBoundsException: Index 34 out of bounds for > length 34 > at > java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:55) > at > java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:52) > at > java.base/jdk.internal.util.Preconditions$4.apply(Preconditions.java:213) > at > java.base/jdk.internal.util.Preconditions$4.apply(Preconditions.java:210) > at > java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:98) > at > java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106) > at > java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302) > at java.base/java.lang.String.checkIndex(String.java:4575) > at java.base/java.lang.StringLatin1.charAt(StringLatin1.java:46) > at java.base/java.lang.String.charAt(String.java:1535) > at > org.eclipse.jetty.session.AbstractSessionManager.resolveRequestedSessionId(AbstractSessionManager.java:1261) > at > org.eclipse.jetty.ee10.servlet.SessionHandler.handle(SessionHandler.java:652) > at > org.eclipse.jetty.server.handler.ContextHandler.handle(ContextHandler.java:811) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:177) > at org.eclipse.jetty.server.Handler$Wrapper.handle(Handler.java:712) > at org.eclipse.jetty.server.Server.handle(Server.java:176) > at > org.eclipse.jetty.server.internal.HttpChannelState$HandlerInvoker.run(HttpChannelState.java:648) > at > org.eclipse.jetty.util.thread.Invocable$ReadyTask.run(Invocable.java:105) > at > org.eclipse.jetty.http2.server.internal.HttpStreamOverHTTP2$1.run(HttpStreamOverHTTP2.java:129) > at > org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:478) > at > org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:441) > at > org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:293) > at >
