We've got an off problem that we're trying to diagnose. The symptoms are that a POST request is sent, and the servlet gets called twice to process it, resulting in a duplicate key violation on the database.
This appears to occur when reconfiguration of components occurs whilst the request is being processed. So what appears to happen is that the request is received, and the servlet gets called to process it. Before the response is generated, the servlet component gets recycled, destroyed and recreated. Felix HTTP whiteboard responds to these lifecycle events and presumably reconfigures jetty in response. Someone, somewhere then decides that the request should be retried, and the same request then gets passed to the new servlet, and the response from that gets sent back to the client. This primarily happens in testing environments when the world is being brought up and down for each test, but you can actually reproduce it in the debugger by putting a breakpoint in the servlet, then when the breakpoint is hit, edit the code and save it. The servlet gets recycled and the request is processed twice. In our case the servlet is being registered using declarative services, using the HTTP whiteboard service. Is this a known problem? Is there a known solution to this problem? Where is the most likely culprit? It seems highly unlikely that jetty would be trying a POST request, that would appear to fundamentally break the contract for POST. GET, PUT, DELETE fine, they are all idempotent, but not POST. I haven't yet delved into the felix HTTP whiteboard code to try and understand its relationship with jetty, so I've no idea whether felix http would get involved, or whether the problem would lie with jetty. Is it likely that the problem is at the felix layer? Any suggestions for investigation would be most appreciated. Thanks.
