Well as I say, at the moment I can't dig into anything as I don't appear to have any way to get matching source code for the felix HTTP bundles, all of the download links appear to be broken.
Since I've realised that actually fixing the double POST doesn't really help us anyway, that's now less of a priority than simply ensuring that the tests "wait until everything is ready" before execution and then "wait until everything is shutdown" after execution. At the moment we are doing the former by simply polling special "ping" endpoints until we get an OK response, but we don't do anything to check that things have shutdown before moving to the next test, which I think is where the main problem lies. We will investigate querying the whiteboard service directly, especially on test "cleanup" (i.e junit @After method) to see if that makes things more reliable. -----Original Message----- From: Carsten Ziegeler [mailto:[email protected]] Sent: 21 December 2016 10:58 To: [email protected] Subject: Re: POST requests being processed twice by felix HTTP Hi, you can use the runtime service defined by the Http Whiteboard spec to find out whether something is still registered. The only downside is that you need to poll and check the DTOs until the desired state is reached. But for testing this should be totally fine. However, it would be great if we could further pinpoint the problem and avoid the duplicate requests in general. Carsten Tom Quarendon wrote >> If that is not the case setting a break point in the DispatcherServlet from >> Felix will tell you whether the request is called twice from outside the >> Felix http implementation (Jetty in that case then) or now. > > The implication of this (I haven't looked into the felix code at this point, > and actually all of the source links for the HTTP projects on the felix > download page seem to be broken, I've tried numerous mirrors) is that there > is a single servlet that you register with jetty, and then you manage > distributing the request to the relevant servlet? > > We are as sure as we can be that there is only one HTTP request made, and two > calls to the server. We've turned on Jetty tracing and logged our own servlet > and this appears to be the case. Up until recently we haven't had a reliable > way to reproduce it, but the technique of editing the code in a debug session > so that you can force it to redeploy the component while it's in the middle > of processing the request appears to work. > > Since my original post, I realise that in some ways it's not interesting why > the problem occurs, or actually "solving" it (clearly, to me, POST being > processed twice is a bug somewhere). > Instead what we want is to make our tests reliable. And I think what this > means is that we need a way of waiting until everything is shut down after > each test. If we had a way of detecting whether all servlets had been > deregistered, then that might help. We suspect that although our test has > finished, background reconfiguration occurs within OSGi, and this is still > happening when the next test starts. It then makes a request that gets > handled by a servlet that is in the process of being shut down. If we could > avoid all of that, and ensure that we go back to a clean slate each time, > that's probably what we really need. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Carsten Ziegeler Adobe Research Switzerland [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
