Mailing-List: contact users-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@felix.apache.org
From: Tom Quarendon <tom.quarendon@worldprogramming.com>
To: "users@felix.apache.org" <users@felix.apache.org>
Subject: RE: POST requests being processed twice by felix HTTP
Thread-Topic: POST requests being processed twice by felix HTTP
Thread-Index: AdJXm4K5gnXl1MlsRsWnbGnBRZKAZwAA/nuAAAAQJtA=
Date: Fri, 16 Dec 2016 13:46:35 +0000
Message-ID: <HE1PR0502MB29060346B691B62F7896ECF38F9C0@HE1PR0502MB2906.eurprd05.prod.outlook.com>
References: <HE1PR0502MB29064CA19A496E7C52FB98A68F9C0@HE1PR0502MB2906.eurprd05.prod.outlook.com>
 <b4278ef7-9282-6389-8ad5-753b77ada174@apache.org>
In-Reply-To: <b4278ef7-9282-6389-8ad5-753b77ada174@apache.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: worldprogramming.com does not
 designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2016 13:46:35.7055
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e74cacd3-9c6e-4b9e-9cc5-8c83d264a79d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0502MB2907
archived-at: Fri, 16 Dec 2016 13:46:43 -0000

> If that is not the case setting a break point in the DispatcherServlet fr=
om 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 d=
ownload 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 distr=
ibuting the request to the relevant servlet?

We are as sure as we can be that there is only one HTTP request made, and t=
wo calls to the server. We've turned on Jetty tracing and logged our own se=
rvlet and this appears to be the case. Up until recently we haven't had a r=
eliable way to reproduce it, but the technique of editing the code in a deb=
ug 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 wh=
y 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 m=
eans is that we need a way of waiting until everything is shut down after e=
ach test. If we had a way of detecting whether all servlets had been deregi=
stered, then that might help. We suspect that although our test has finishe=
d, background reconfiguration occurs within OSGi, and this is still happeni=
ng 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 pro=
bably what we really need.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org