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 / [email protected] On Tue, Sep 5, 2023 at 9:24 AM Silvio Bierman <[email protected]> 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 / [email protected] > > > On Tue, Sep 5, 2023 at 8:47 AM Silvio Bierman via jetty-users < > [email protected]> 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 >> > <[email protected]> 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 >> [email protected] >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/jetty-users >> > >
_______________________________________________ jetty-users mailing list [email protected] To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
