[ 
https://issues.apache.org/jira/browse/RIVER-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15066200#comment-15066200
 ] 

Peter Firmstone edited comment on RIVER-431 at 12/21/15 8:45 AM:
-----------------------------------------------------------------

com.sun.jini.thread.TaskManager.firstPending; locked 68% of time - deprecated, 
not fixed.

All uses of TaskManager have been replaced by ExecutorService implementations, 
note that new ExecutorService wrapper classes have been written to handle 
ordering and task interdependencies.  TaskManager will be removed in a future 
release.


was (Author: pfirmst):
com.sun.jini.thread.TaskManager.firstPending; locked 68% of time - deprecated, 
not fixed.

> Java Memory Model Compliance
> ----------------------------
>
>                 Key: RIVER-431
>                 URL: https://issues.apache.org/jira/browse/RIVER-431
>             Project: River
>          Issue Type: Bug
>    Affects Versions: River_2.1.1, River_2.1.2, River_2.2.0, River_2.2.1, 
> River_2.2.2
>         Environment: JVM
>            Reporter: Peter Firmstone
>            Assignee: Peter Firmstone
>             Fix For: River_3.0.0
>
>         Attachments: RegistrarImpl.patch
>
>
> Much of the Jini codebase was written prior to the publication of the current 
> JMM, for this reason, there are a number of issues with the existing code 
> base that need to be changed to bring River into compliance with the JMM.
> Typical issues encountered:
> 1.Letting "this" escape during construction - example exporting or starting 
> threads, where those threads can see internal field references before 
> construction of that object is complete.
> 2. Inadequate synchronization or lack of synchronization on mutable fields.
> 3. Sharing of internal unsynchronized state.
> 4. Race conditions where unsynchronized or non final or non volatile fields 
> are updated by other threads.
> 5. Deserializing an object in one thread and sharing the deserialized mutable 
> but unmodified object with another thread without first publishing it safely 
> to a volatile or final field, so the second thread can sometimes see the 
> default value of fields in the mutable object.
> Affects all presently released versions, planned to be fixed in River 3.0



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to