[SIPSERVLET_SPEC-41] Concurrency issues remain in SipServlet 2.0v0.9 Created: 14/Mar/14  Updated: 24/Nov/14  Resolved: 24/Nov/14

Status: Resolved
Project: sipservlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-pfd

Type: Bug Priority: Major
Reporter: tomrstrickland Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


I am worried that (in introducing our thread-scheduling solution in 18.3.2) we are ignoring a set of problems that will hit both container and application developers hard. Rather than rambling on, I will outline a use-case to illustrate the point:


  1. SipApplicationSession sasA. Any thread running in its context will be called threadA.
  2. SipApplicationSession sasB. Any thread running in its context will be called threadB.
  3. a SipServletMessage, msgA, that was created in a SipSession within sasA.

threadA invokes a task to run in the context of sasB, passing msgA - the task runs on threadB.


  1. threadB should be able to read values from msgA (otherwise there's no point in passing it around at all). There are a variety of such readable values : headers, body, container-supplied metadata (e.g. about transport), AttributeStore attributes. Should all these values be readable from threadB?
  2. Assuming that threadB is reading a value from msgA, what happens if threadA alters it?
  3. Should threadB be able to write values in msgA?

Perhaps we do not have the time to fix the API or the specification. However, we may be able to outline a set of use cases that both app and container developers can consider when developing apps, perhaps in an appendix. As a bonus, in outlining these use-cases, we may be able to tighten up the spec a little.

Comment by binod [ 09/Oct/14 ]

Link to the meeting notes about this issue.

Comment by binod [ 13/Oct/14 ]

Here is the proposed text we can add to the end of section
SIP Servlet containers ensure that tasks are run in a thread safe manner with respect to the sip application sessions specified as the context. However, application should be careful while sharing the objects between tasks with different application session context. Thread safety of such objects, whether it is an application specific object or an object received from the container, need to be maintained by the application. For example, objects like SipURI, Address may be cloned before sharing it between the tasks.

Comment by binod [ 24/Nov/14 ]

Section has been modified to reflect the suggested change.

Generated at Sun Apr 30 16:35:33 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.