You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "Peter Firmstone (JIRA)" <ji...@apache.org> on 2015/12/05 09:18:11 UTC
[jira] [Resolved] (RIVER-113) JoinManager synchronization on each
proxyReg should be reviewed, doc'd and fixed where appropriate
[ https://issues.apache.org/jira/browse/RIVER-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Firmstone resolved RIVER-113.
-----------------------------------
Resolution: Fixed
Fix Version/s: River_3.0.0
Synchronization in JoinManager has been reviewed and fixed.
> JoinManager synchronization on each proxyReg should be reviewed, doc'd and fixed where appropriate
> --------------------------------------------------------------------------------------------------
>
> Key: RIVER-113
> URL: https://issues.apache.org/jira/browse/RIVER-113
> Project: River
> Issue Type: Bug
> Components: net_jini_lookup
> Affects Versions: jtsk_2.1
> Reporter: Jim Hurley
> Priority: Minor
> Fix For: River_3.0.0
>
>
> Bugtraq ID[6219112|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6219112]
> For each lookup service that is discovered, the JoinManager creates a
> new instance of ProxyReg that wraps the discovered lookup service's
> proxy. Each such proxyReg object contains a list of tasks that are
> executed. For each proxyReg, there is a special wrapper task named,
> ProxyRegTask that is queued with the TaskManager.
> Each ProxyRegTask is executed in parallel by the TaskManager.
> Within each ProxyRegTask, the tasks contained in the correpsonding proxyReg's
> taskList are each run in FIFO order.
> For any given proxyReg object, the proxyReg object itself, as well as the
> fields of that object, are accessed (read or written) in the various tasks
> and threads (including the main thread) executed by the JoinManager. In
> most cases, that access is controlled through synchronization on various
> objects (different objects are used to provide more "granularity" to the
> access). There are a few places where the access to a proxyReg object or
> its fields is not synchronized at all.
> The synchronization strategy and implementation for each proxyReg object and
> its fields should be reviewed and corrected where appropriate.
> See the comments for a 'map' of serviceItem synchronization, and a
> discription of the synchronization strategy regarding each proxyReg and
> its fields.
> Comments:
> JoinManager {
> ProxyRegTask extends RetryTask {
> ProxyReg proxyReg
> tryOnce() {}
> runAfter() {}
> stopTrying() {}
> }
> ProxyReg {
> ProxyRegTask proxyRegTask
> ServiceRegistrar proxy
> ServiceRegistration srvcRegistration
> Lease serviceLease
> List taskList
> DiscLeaseListener dListener
> }
> }
> -- Synchronization Strategy for serviceItem --
> Because each new proxyReg is placed in the joinSet, and because the tasks
> corresponding to a particular proxyReg (stored in that proxyReg's taskList)
> are unrelated (and run in parallel) to the tasks of the other proxyRegs,
> access to a particular proxyReg instance is controlled primarily through synchronization on either joinSet or the proxyReg's taskList. This is intended
> to provide better granularity between the accesses that occur across all
> proxyReg tasks (access to joinSet) and accesses that are specific to a
> particular proxyReg (access to a particular proxyReg's taskList). Additionally,
> there is one special where in addtion to syncing on joinSet, there is a
> nested sync on serviceItem. This is necessary because in addition to accessing
> a field of a proxyReg (requiring a sync on joinSet), there is also an
> access to serviceItem.serviceID which requires a sync on serviceItem (see
> bug 6219020).
> Thus, for a given proxyReg:
> -- Access to the taskList of the proxyReg is controlled by synchronizing
> on the taskList itself.
> -- Access to the other fields of the proxyReg is controlled by
> synchronizing on joinSet.
> -- Synchronization Map --
> proxyReg field access location access type synchronization
> ----------------- ----------------------- ----------- -----------------
> a.) proxyRegTask ProxyRegTask.tryOnce() write sync(taskList)
> ProxyReg.addTask() read write sync(taskList)
> removeTasks() read write sync(taskList)
> b.) proxy ProxyReg.constructor() write NO SYNC
> [*** Note: constructor is only place proxy field is written to ***]
> getJoinSet() read sync(joinSet)
> *** findReg() read NO SYNC
> *** proxyReg.equals() read NO SYNC
> c.) srvcRegistration ProxyReg.register() read write sync(joinSet)
> sync(joinSet)
> &sync(serviceItem)
> *** ProxyReg.addAttributes() read NO SYNC
> *** ProxyReg.modifyAttributes() read NO SYNC
> *** ProxyReg.setAttributes() read NO SYNC
> getJoinSet() read sync(joinSet)
> d.) serviceLease DiscardLeaseListener.notify() read sync(joinSet)
> *** DiscardProxyTask.run() read NO SYNC
> *** ProxyReg.register() write NO SYNC
> DiscMgrListener.discarded() read sync(joinSet)
> replaceRegistrationDo() read sync(joinSet)
> e.) taskList ProxyRegTask.tryOnce() read write sync(taskList)
> ProxyReg.addTask() write sync(taskList)
> removeTasks() write sync(taskList)
> f.) dListener ProxyReg.register() read NO SYNC
> [*** Note: dListener is instantiated when each proxyReg instance is
> created. No need then to synchronize access to dListener? ***]
> Suggested Fix
> Each of the items labelled with a "NO SYNC" in the synchronization map
> documented in "Comments" section should be analyzed and the appropriate
> synchronization should be added.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)