Bug 57969 - @PathParam annotation captures incorrect value under high load
Summary: @PathParam annotation captures incorrect value under high load
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 7
Classification: Unclassified
Component: WebSocket (show other bugs)
Version: 7.0.59
Hardware: PC Linux
: P2 major (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
: 58059 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-05-28 20:58 UTC by peter hausel
Modified: 2015-06-20 04:30 UTC (History)
1 user (show)



Attachments
Patch proposal (1.47 KB, patch)
2015-06-04 14:34 UTC, Violeta Georgieva
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description peter hausel 2015-05-28 20:58:49 UTC
Under high load, given a @ServerEndpoint like


@ServerEndpoint(value="/websocket/{key}", configurator=MyConfigurator.class)
public class ExecutionMonitoringEndpoint{
...
@OnMessage
public void onMessage(@PathParam("key") String key, String payload) {
   ...
}
}
//where MyConfigurator is used to only inject a custom property like ServerEndpointConfig.conf.getUserProperties().put(...);

we noticed that the captured PathParam ("key" in this case) was sometimes mixed up with another concurrent request - causing double subscriptions in our pub/sub application.


Changing the above to

@ServerEndpoint(value="/websocket/{key}", configurator=MyConfigurator.class)
public class ExecutionMonitoringEndpoint{
...
@OnMessage
public void onMessage(Session session, String payload) {
  String key = session.getPathParameters().get("key");
}
}

fixed the problem.
Comment 1 Violeta Georgieva 2015-06-04 14:34:37 UTC
Created attachment 32794 [details]
Patch proposal

Hi,

I succeeded to reproduce the issue.
I'm attaching a patch proposal.

Regards,
Violeta
Comment 2 Violeta Georgieva 2015-06-08 14:30:40 UTC
Hi,

This is fixed in trunk, in 8.0.x for 8.0.24 and in 7.0.x for 7.0.63 onwards.

Regards,
Violeta
Comment 3 Violeta Georgieva 2015-06-20 04:30:46 UTC
*** Bug 58059 has been marked as a duplicate of this bug. ***