Possibly change in maven-bundle-plugin bundle-classpath generation?
I’ve been experimenting with activemq and I think there may be a change in behavior of the Bundle-ClassPath generation from maven dependencies between maven-bundle-plugin versions 2.3.7 and 3.0.0. I believe that by changing only the plugin version two embedded jars got left out of the activemq-web-console META-INF/MANIFEST.MF. Is this known or expected behavior? thanks david jencks
[jira] [Commented] (FELIX-5215) Deadlocks involving global lock
[
https://issues.apache.org/jira/browse/FELIX-5215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193750#comment-15193750
]
Richard S. Hall commented on FELIX-5215:
Framework synchronization has been the bane of my existence since 2000...the
OSGi spec has made life very difficult with requiring synchronous event
delivery. As a result, I don't think it is completely possible to eliminate the
possibility of deadlocking. Timeouts are one way of dealing with this reality.
Digging a little deeper, in general, there are two types of operations, those
involving a single bundle and those involving multiple bundles. The main
multi-bundle operation is bundle resolution (which can be triggered during a
single-bundle operation). Related, the main reason why the global lock exists
is to make sure the state of the framework doesn't change while a multi-bundle
(i.e., resolve) operation is taking place.
The one thought that I've had over the years was to make the bundle resolution
process optimistic and non-locking. Effectively, just do the resolve process on
a copy of the state assuming the framework state won't change. At the end,
check to see if the state used to calculate the resolution is the same as the
current framework state; if so, grab the framework state lock and apply it; if
not, re-resolve with the updated state. Rinse, repeat, as necessary.
I think something like this would go a long way toward improving the situation,
but even then it won't eliminate the possibility. I think Equinox does
something similar.
> Deadlocks involving global lock
> ---
>
> Key: FELIX-5215
> URL: https://issues.apache.org/jira/browse/FELIX-5215
> Project: Felix
> Issue Type: Improvement
> Components: Framework
>Affects Versions: framework-4.6.1, framework-5.4.0
>Reporter: Julian Sedding
> Attachments: deadlock-01.txt, deadlock-02.txt
>
>
> I have recently analyzed two thread dumps on a framework 4.6.1 with deadlocks
> involving the {{FelixFrameworkWiring}} thread calling
> {{Felix.refreshPackages}} and another thread.
> In both cases the {{FelixFrameworkWiring}} thread holds Felix' global lock in
> {{Felix.refreshPackages}}, the other thread holds a lock in
> {{HttpServiceImpl}} and {{ServiceRegistry}}, respectively. (Note, both
> {{HttpServiceImpl}} and {{ServiceRegistry}} had their synchronization removed
> in trunk, possibly due to similar deadlocks).
> While fixing the other players in the deadlock certainly helps, I was
> wondering if it would be possible to change the code inside the framework in
> a way that such deadlocks are no longer possible?
> I believe section 4.7.3 "Synchronization Pitfalls" in the OSGi spec talks
> about this situation (quoted from v5.0.0):
> {quote}
> Generally, a bundle that calls a listener should not hold any Java monitors.
> This means that neither the Framework nor the originator of a synchronous
> event should be in a monitor when a callback is initiated.
> [...]
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Deadlocks involving Felix' global lock
PS: see also FELIX-5215 On Mon, Mar 14, 2016 at 6:00 PM, Julian Sedding wrote: > Hi all > > I have recently analyzed two thread dumps on a framework 4.6.1 with > deadlocks involving the FelixFrameworkWiring thread calling > Felix.refreshPackages and another thread. > In both cases the FelixFrameworkWiring thread holds Felix' global lock > in Felix.refreshPackages, the other thread holds a lock in > HttpServiceImpl and ServiceRegistry, respectively. (Note, both > HttpServiceImpl and ServiceRegistry had their synchronization removed > in trunk, possibly due to similar deadlocks). > > While fixing the other players in the deadlock certainly helps, I was > wondering if it would be possible to change the code inside the > framework in a way that such deadlocks are no longer possible? > > I believe section 4.7.3 "Synchronization Pitfalls" in the OSGi spec > talks about this situation (quoted from v5.0.0): > > "Generally, a bundle that calls a listener should not hold any Java > monitors. This means that neither the Framework nor the originator of > a synchronous event should be in a monitor when a callback is > initiated. [...]" > > WDYT? Any ideas on how this could be approached? > > Thanks & regards > Julian
Deadlocks involving Felix' global lock
Hi all I have recently analyzed two thread dumps on a framework 4.6.1 with deadlocks involving the FelixFrameworkWiring thread calling Felix.refreshPackages and another thread. In both cases the FelixFrameworkWiring thread holds Felix' global lock in Felix.refreshPackages, the other thread holds a lock in HttpServiceImpl and ServiceRegistry, respectively. (Note, both HttpServiceImpl and ServiceRegistry had their synchronization removed in trunk, possibly due to similar deadlocks). While fixing the other players in the deadlock certainly helps, I was wondering if it would be possible to change the code inside the framework in a way that such deadlocks are no longer possible? I believe section 4.7.3 "Synchronization Pitfalls" in the OSGi spec talks about this situation (quoted from v5.0.0): "Generally, a bundle that calls a listener should not hold any Java monitors. This means that neither the Framework nor the originator of a synchronous event should be in a monitor when a callback is initiated. [...]" WDYT? Any ideas on how this could be approached? Thanks & regards Julian
[jira] [Updated] (FELIX-5215) Deadlocks involving global lock
[
https://issues.apache.org/jira/browse/FELIX-5215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated FELIX-5215:
--
Attachment: deadlock-02.txt
deadlock-01.txt
Threaddumps showing deadlocks for reference.
Other similar situations were reported in FELIX-3839, FELIX-3761 and FELIX-3644.
In FELIX-3067 [~fmeschbe] proposed using a timeout in the global lock to remedy
the same situation.
> Deadlocks involving global lock
> ---
>
> Key: FELIX-5215
> URL: https://issues.apache.org/jira/browse/FELIX-5215
> Project: Felix
> Issue Type: Improvement
> Components: Framework
>Affects Versions: framework-4.6.1, framework-5.4.0
>Reporter: Julian Sedding
> Attachments: deadlock-01.txt, deadlock-02.txt
>
>
> I have recently analyzed two thread dumps on a framework 4.6.1 with deadlocks
> involving the {{FelixFrameworkWiring}} thread calling
> {{Felix.refreshPackages}} and another thread.
> In both cases the {{FelixFrameworkWiring}} thread holds Felix' global lock in
> {{Felix.refreshPackages}}, the other thread holds a lock in
> {{HttpServiceImpl}} and {{ServiceRegistry}}, respectively. (Note, both
> {{HttpServiceImpl}} and {{ServiceRegistry}} had their synchronization removed
> in trunk, possibly due to similar deadlocks).
> While fixing the other players in the deadlock certainly helps, I was
> wondering if it would be possible to change the code inside the framework in
> a way that such deadlocks are no longer possible?
> I believe section 4.7.3 "Synchronization Pitfalls" in the OSGi spec talks
> about this situation (quoted from v5.0.0):
> {quote}
> Generally, a bundle that calls a listener should not hold any Java monitors.
> This means that neither the Framework nor the originator of a synchronous
> event should be in a monitor when a callback is initiated.
> [...]
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FELIX-5215) Deadlocks involving global lock
Julian Sedding created FELIX-5215:
-
Summary: Deadlocks involving global lock
Key: FELIX-5215
URL: https://issues.apache.org/jira/browse/FELIX-5215
Project: Felix
Issue Type: Improvement
Components: Framework
Affects Versions: framework-5.4.0, framework-4.6.1
Reporter: Julian Sedding
I have recently analyzed two thread dumps on a framework 4.6.1 with deadlocks
involving the {{FelixFrameworkWiring}} thread calling {{Felix.refreshPackages}}
and another thread.
In both cases the {{FelixFrameworkWiring}} thread holds Felix' global lock in
{{Felix.refreshPackages}}, the other thread holds a lock in {{HttpServiceImpl}}
and {{ServiceRegistry}}, respectively. (Note, both {{HttpServiceImpl}} and
{{ServiceRegistry}} had their synchronization removed in trunk, possibly due to
similar deadlocks).
While fixing the other players in the deadlock certainly helps, I was wondering
if it would be possible to change the code inside the framework in a way that
such deadlocks are no longer possible?
I believe section 4.7.3 "Synchronization Pitfalls" in the OSGi spec talks about
this situation (quoted from v5.0.0):
{quote}
Generally, a bundle that calls a listener should not hold any Java monitors.
This means that neither the Framework nor the originator of a synchronous event
should be in a monitor when a callback is initiated.
[...]
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
