Affects Version/s: None
Fix Version/s: 2.0-pfd
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:
- SipApplicationSession sasA. Any thread running in its context will be called threadA.
- SipApplicationSession sasB. Any thread running in its context will be called threadB.
- 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.
- 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?
- Assuming that threadB is reading a value from msgA, what happens if threadA alters it?
- 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.