[jira] [Updated] (SLING-4895) Service registry should not be called from within synchronized block
[ https://issues.apache.org/jira/browse/SLING-4895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-4895: Assignee: Marius Petria > Service registry should not be called from within synchronized block > > > Key: SLING-4895 > URL: https://issues.apache.org/jira/browse/SLING-4895 > Project: Sling > Issue Type: Bug > Components: Extensions >Affects Versions: Service User Mapper 1.2.0 >Reporter: Carsten Ziegeler >Assignee: Marius Petria > Fix For: Service User Mapper 1.2.2 > > Attachments: SLING-4895-alt.diff, SLING-4895.1.diff, SLING-4895.diff > > > RIght now, if e.g. an amendment is added/removed/updated, all > registration/unregistration is done in a "large" synchronized block. This > should be avoided -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4895) Service registry should not be called from within synchronized block
[ https://issues.apache.org/jira/browse/SLING-4895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marius Petria updated SLING-4895: - Attachment: SLING-4895.1.diff I created another patch that uses a placeholder registration object and then delegates the registrations and unregistrations outside the synched zones. Service registry should not be called from within synchronized block Key: SLING-4895 URL: https://issues.apache.org/jira/browse/SLING-4895 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Service User Mapper 1.2.0 Reporter: Carsten Ziegeler Fix For: Service User Mapper 1.2.2 Attachments: SLING-4895-alt.diff, SLING-4895.1.diff, SLING-4895.diff RIght now, if e.g. an amendment is added/removed/updated, all registration/unregistration is done in a large synchronized block. This should be avoided -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4895) Service registry should not be called from within synchronized block
[ https://issues.apache.org/jira/browse/SLING-4895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-4895: Attachment: SLING-4895-alt.diff I've attached an alternative patch which uses a use count for mappings. However, this is a more complicated setup compared to the original version. on the other hand, it handles the case where several amendments return a mapping for the same combination - I'm not 100% sure if this is currently correctly handled. But maybe the simpler patch is already enough Service registry should not be called from within synchronized block Key: SLING-4895 URL: https://issues.apache.org/jira/browse/SLING-4895 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Service User Mapper 1.2.0 Reporter: Carsten Ziegeler Fix For: Service User Mapper 1.2.2 Attachments: SLING-4895-alt.diff, SLING-4895.diff RIght now, if e.g. an amendment is added/removed/updated, all registration/unregistration is done in a large synchronized block. This should be avoided -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4895) Service registry should not be called from within synchronized block
[ https://issues.apache.org/jira/browse/SLING-4895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marius Petria updated SLING-4895: - Attachment: SLING-4895.diff [~cziegeler] I attached a patch that moves the service registration outside the sync block and uses a concurrent hash map to keep the registrations. Service registry should not be called from within synchronized block Key: SLING-4895 URL: https://issues.apache.org/jira/browse/SLING-4895 Project: Sling Issue Type: Bug Components: Extensions Affects Versions: Service User Mapper 1.2.0 Reporter: Carsten Ziegeler Fix For: Service User Mapper 1.2.2 Attachments: SLING-4895.diff RIght now, if e.g. an amendment is added/removed/updated, all registration/unregistration is done in a large synchronized block. This should be avoided -- This message was sent by Atlassian JIRA (v6.3.4#6332)
