Hi all,
I've fixed the remaining Guard.secrets issue following Tim advises:
- removed the setSecrets() method in trunk
- eagerly instantiate the secrets map
I've also fixed potential issues with RouteList using an underlying
CopyOnWriteArrayList instance.
If you see remaining threading issues, please reopen:
http://restlet.tigris.org/issues/show_bug.cgi?id=368
Best,
Jerome
Jerome Louvel a écrit :
Hi Tim,
What's the best way for me (or anyone else) to report other
concurrency and documentation issues that I encounter? In
this discussion group? This thread? Or somewhere else?
For issues similar to the one we discussed, the best place is in the issue,
via the comments system. I've just broaden the scope of this issue:
"Fix thread safety issues"
http://restlet.tigris.org/issues/show_bug.cgi?id=368
If you have time to contribute patches, that would be more than welcome.
Here's my understanding of the basic concurrency requirements
of the Restlet framework: Restlets of all flavors must be
@ThreadSafe because they will in general be accessed
concurrently by many threads. Requests and Responses are
@NotThreadSafe; their handling is confined to a single
thread. Representations might or might not be thread-safe,
depending on whether they will be re-used in subsequent
request handling. Does that sound right?
It is mostly right. For Representations, I don't think they should be shared
by multiple threads. The instances are generally short-lived, bounded to the
Request/Response life cycle.
I posted some basic rules for writing @ThreadSafe classes
<http://tembrel.blogspot.com/2007/10/basic-rules-for-threadsaf
e-classes.html> on my blog. I hope they're helpful.
Cool, I've added the link to the threading documentation RFE:
http://www.outerthought.com/
Best regards,
Jerome
