cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amichai Rothman (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DOSGI-169) RemoteServiceAdminCore missing synchronized block
Date Mon, 08 Apr 2013 16:53:15 GMT

     [ https://issues.apache.org/jira/browse/DOSGI-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Amichai Rothman updated DOSGI-169:
----------------------------------

    Attachment: fix_exportedservices_sync_2.diff

As it turns out, once this fix is applied and access is synchronized, it exposes another deadlock
- this time in exportService (where a FIXME comment predicts that putting the whole export
implementation inside the synchronized block means trouble).

This second patch fixes that deadlock by putting the data structure manipulations in synchronized
blocks, and the rest of the impl outside of them (including calls to the OSGi APIs, which
should not be performed while holding locks - that's where the deadlock came from, the service
tracker creation in particular). The implementation is a bit tricky, so an expert review is
most welcome.

Note that the second patch is currently based on the patch from DOSGI-168, since it's easier
to work with and may be committed first in any case. If for some reason this patch is accepted
and the DOSGI-168 one isn't, I can rebase it as necessary).

                
> RemoteServiceAdminCore missing synchronized block
> -------------------------------------------------
>
>                 Key: DOSGI-169
>                 URL: https://issues.apache.org/jira/browse/DOSGI-169
>             Project: CXF Distributed OSGi
>          Issue Type: Bug
>          Components: DSW
>    Affects Versions: 1.4.0, 1.5
>            Reporter: Amichai Rothman
>         Attachments: fix_exportedservices_sync_2.diff, fix_exportedservices_sync.diff
>
>
> In RemoteServiceAdminCore.removeExportRegistrations() the exportedServices map is used
in a HashMap copy constructor without being synchronized (this is easily visually mistaken
for a single atomic operation, but is actually an iteration on the map - an in any case, should
be synchronized for proper visibility). The copy constructor call should be placed in a syncrhonized
block with exportedServices as the monitor, just like all other accesses to this map.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message