river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Firmstone (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (RIVER-431) Java Memory Model Compliance
Date Mon, 21 Dec 2015 08:13:46 GMT

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

Peter Firmstone commented on RIVER-431:
---------------------------------------

Inconsistent synchronization of TxnTable.brokenTxns; locked 58% of time
Unsynchronized access at TxnTable.java:[line 404]
Field com.sun.jini.outrigger.TxnTable.brokenTxns
Unsynchronized access at TxnTable.java:[line 405]
Unsynchronized access at TxnTable.java:[line 408]
Unsynchronized access at TxnTable.java:[line 411]


> 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)

Mime
View raw message