[jira] [Comment Edited] (FELIX-4436) DirectoryWatcher should not refresh transformed bundles on every start-up
[ https://issues.apache.org/jira/browse/FELIX-4436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13940952#comment-13940952 ] Uwe Barthel edited comment on FELIX-4436 at 3/19/14 8:51 PM: - [~metatech] Oh, that isn't cool. Please provide information about your framework and setup. Debug log information are helpful too. Is it possible that you provide the bundle cache content for that file ? It sounds like a failure in scanner on calculate the checksum or something else in this context. Under Linux with a minimal Felix setup I have not noticed this behavior. Please retry with a clear bundle cache. was (Author: barthel): [~metatech] Oh, that isn't cool. Please provide information about your framework and setup. Debug log information are helpful too. It sounds like a failure in scanner on calculate the checksum. Under Linux with a minimal Felix setup I have not noticed this behavior. Please retry with a clear bundle cache. > DirectoryWatcher should not refresh transformed bundles on every start-up > - > > Key: FELIX-4436 > URL: https://issues.apache.org/jira/browse/FELIX-4436 > Project: Felix > Issue Type: Bug > Components: File Install >Affects Versions: fileinstall-3.2.4 > Environment: ServiceMix 4.5.3 >Reporter: metatech >Assignee: Guillaume Nodet >Priority: Minor > Fix For: fileinstall-3.4.0 > > Attachments: felix_no_refresh_installed.patch > > > DirectoryWatcher can auto-deploy JAR or XML files placed in a directory. > Blueprint XML files (containing for instance ActiveMQ factories or JAAS > realms) are detected as "installed" on every start-up. Prior to FELIX-2066, > this had no effect. Since FELIX-2066, bundles detected as "installed" are > now forcibly "refreshed" on every start-up. The impact is that these bundles > are stopped and restarted during the container start-up. Because there are > some race conditions (see FELIX-3067), this can prevent those XML files or > other bundles depending on them from fully starting. Here is a patch which > avoids restarting those bundles when they were not modified. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FELIX-4436) DirectoryWatcher should not refresh transformed bundles on every start-up
[ https://issues.apache.org/jira/browse/FELIX-4436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13940952#comment-13940952 ] Uwe Barthel commented on FELIX-4436: [~metatech] Oh, that isn't cool. Please provide information about your framework and setup. Debug log information are helpful too. It sounds like a failure in scanner on calculate the checksum. Under Linux with a minimal Felix setup I have not noticed this behavior. Please retry with a clear bundle cache. > DirectoryWatcher should not refresh transformed bundles on every start-up > - > > Key: FELIX-4436 > URL: https://issues.apache.org/jira/browse/FELIX-4436 > Project: Felix > Issue Type: Bug > Components: File Install >Affects Versions: fileinstall-3.2.4 > Environment: ServiceMix 4.5.3 >Reporter: metatech >Assignee: Guillaume Nodet >Priority: Minor > Fix For: fileinstall-3.4.0 > > Attachments: felix_no_refresh_installed.patch > > > DirectoryWatcher can auto-deploy JAR or XML files placed in a directory. > Blueprint XML files (containing for instance ActiveMQ factories or JAAS > realms) are detected as "installed" on every start-up. Prior to FELIX-2066, > this had no effect. Since FELIX-2066, bundles detected as "installed" are > now forcibly "refreshed" on every start-up. The impact is that these bundles > are stopped and restarted during the container start-up. Because there are > some race conditions (see FELIX-3067), this can prevent those XML files or > other bundles depending on them from fully starting. Here is a patch which > avoids restarting those bundles when they were not modified. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (FELIX-3992) Classloader access outside of a privileged block
[
https://issues.apache.org/jira/browse/FELIX-3992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls resolved FELIX-3992.
---
Resolution: Fixed
> Classloader access outside of a privileged block
>
>
> Key: FELIX-3992
> URL: https://issues.apache.org/jira/browse/FELIX-3992
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.2.0
>Reporter: Romain Dubois
>Assignee: Karl Pauls
>Priority: Minor
> Labels: security
> Fix For: framework-4.4.0
>
>
> In method
> org.apache.felix.framework.ServiceRegistrationImpl.isClassAccessible(Class),
> there is an access to the registered ServiceFactory classloader (lines
> 163:169 in v4.2.1):
> if ((m_factory != null)
> && (m_factory.getClass().getClassLoader() instanceof
> BundleReference)
> && !((BundleReference) m_factory.getClass()
> .getClassLoader()).getBundle().equals(m_bundle))
> {
> return true;
> }
> If a bundle registers a service through a ServiceFactory and if there is an
> active ServiceListener matching this service, those lines are executed inside
> the registering bundle's protection domain.
> If this bundle does not have the (java.util.RuntimePermission
> 'getClassloader') privilege, the getClassLoader invocation throws a
> SecurityException and the listener is always called because the exception is
> catched at line 526 (isAssignableTo) of the same class.
> The comment inside the catch block does not seem to justify this case.
> I think a simple privileged block around the bundle comparison is harmless
> and should fix this. It could be something like :
> if (m_factory != null)
> {
> Bundle bundle = null;
> if (System.getSecurityManager() == null)
> {
> if ((m_factory.getClass().getClassLoader() instanceof
> BundleReference) {
> bundle = ((BundleReference)
> m_factory.getClass().getClassLoader()).getBundle();
> }
> }
> else
> {
> bundle = AccessController.doPrivileged(new
> PrivilegedAction() {
> public Bundle run() {
> if ((m_factory.getClass().getClassLoader() instanceof
> BundleReference) {
> return ((BundleReference)
> m_factory.getClass().getClassLoader()).getBundle();
> }
> return null;
> }
> });
> }
>
> if (bundle != null && bundle.equals(m_bundle)) {
> return true;
> }
> }
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Reopened] (FELIX-4436) DirectoryWatcher should not refresh transformed bundles on every start-up
[ https://issues.apache.org/jira/browse/FELIX-4436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reopened FELIX-4436: Reopening to check the activemq xml config > DirectoryWatcher should not refresh transformed bundles on every start-up > - > > Key: FELIX-4436 > URL: https://issues.apache.org/jira/browse/FELIX-4436 > Project: Felix > Issue Type: Bug > Components: File Install >Affects Versions: fileinstall-3.2.4 > Environment: ServiceMix 4.5.3 >Reporter: metatech >Assignee: Guillaume Nodet >Priority: Minor > Fix For: fileinstall-3.4.0 > > Attachments: felix_no_refresh_installed.patch > > > DirectoryWatcher can auto-deploy JAR or XML files placed in a directory. > Blueprint XML files (containing for instance ActiveMQ factories or JAAS > realms) are detected as "installed" on every start-up. Prior to FELIX-2066, > this had no effect. Since FELIX-2066, bundles detected as "installed" are > now forcibly "refreshed" on every start-up. The impact is that these bundles > are stopped and restarted during the container start-up. Because there are > some race conditions (see FELIX-3067), this can prevent those XML files or > other bundles depending on them from fully starting. Here is a patch which > avoids restarting those bundles when they were not modified. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FELIX-4462) Classloader deadlock in Java6 between two bundles
[ https://issues.apache.org/jira/browse/FELIX-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall updated FELIX-4462: --- Fix Version/s: framework-4.4.0 > Classloader deadlock in Java6 between two bundles > - > > Key: FELIX-4462 > URL: https://issues.apache.org/jira/browse/FELIX-4462 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.2.1 > Environment: MacOS 10.7.5, java version "1.6.0_65", Java(TM) SE > Runtime Environment (build 1.6.0_65-b14-462-11M4609), Java HotSpot(TM) 64-Bit > Server VM (build 20.65-b04-462, mixed mode) >Reporter: Stefan Egli >Assignee: Richard S. Hall > Fix For: framework-4.4.0 > > Attachments: FELIX-4462.txt, classLockMonitor.FELIX-4462.patch2, > suggested.synchronized.FELIX-4462.patch, test.reproducingFELIX-4462.patch > > > As discussed on the user list ([0]) there is a deadlock in Java 6 (if bug > 4670071 [2] is not fixed). The problem is the hidden, implicit > ClassLoader.loadClassInternal which is is synchronized(this) in that case. > Consider the following scenario: > * bundle 2 wants to load a class of bundle 1 - hence is not synchronized > with bundle 1's classloader - thus uses the m_classLocks locking mechanism to > lock bundle 1's classloader for the particular class being loaded. Then calls > defineClass (with bundle 1's classloader) > * before it can do so, bundle 1 wants to load the same class (of bundle 1) - > hence does a synchronized loadClassInternal. then reaches the m_classLocks > locking mechanism and notices that there's another thread loading the class > -> this results in the deadlock reported. > There's multiple fixes for this: > * use Java 7 > * use -XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass > * create a special Java 6 classloader (Java 7 would use the current one) > which does a plain synchronized findClass() - and replaces all > synchronized(m_classLocks) with synchronized(this) > [0] http://markmail.org/thread/crwqzqobxgob7q3n > [1] http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4670071 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (FELIX-4462) Classloader deadlock in Java6 between two bundles
[ https://issues.apache.org/jira/browse/FELIX-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall closed FELIX-4462. -- Resolution: Fixed > Classloader deadlock in Java6 between two bundles > - > > Key: FELIX-4462 > URL: https://issues.apache.org/jira/browse/FELIX-4462 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.2.1 > Environment: MacOS 10.7.5, java version "1.6.0_65", Java(TM) SE > Runtime Environment (build 1.6.0_65-b14-462-11M4609), Java HotSpot(TM) 64-Bit > Server VM (build 20.65-b04-462, mixed mode) >Reporter: Stefan Egli >Assignee: Richard S. Hall > Fix For: framework-4.4.0 > > Attachments: FELIX-4462.txt, classLockMonitor.FELIX-4462.patch2, > suggested.synchronized.FELIX-4462.patch, test.reproducingFELIX-4462.patch > > > As discussed on the user list ([0]) there is a deadlock in Java 6 (if bug > 4670071 [2] is not fixed). The problem is the hidden, implicit > ClassLoader.loadClassInternal which is is synchronized(this) in that case. > Consider the following scenario: > * bundle 2 wants to load a class of bundle 1 - hence is not synchronized > with bundle 1's classloader - thus uses the m_classLocks locking mechanism to > lock bundle 1's classloader for the particular class being loaded. Then calls > defineClass (with bundle 1's classloader) > * before it can do so, bundle 1 wants to load the same class (of bundle 1) - > hence does a synchronized loadClassInternal. then reaches the m_classLocks > locking mechanism and notices that there's another thread loading the class > -> this results in the deadlock reported. > There's multiple fixes for this: > * use Java 7 > * use -XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass > * create a special Java 6 classloader (Java 7 would use the current one) > which does a plain synchronized findClass() - and replaces all > synchronized(m_classLocks) with synchronized(this) > [0] http://markmail.org/thread/crwqzqobxgob7q3n > [1] http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4670071 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (FELIX-4462) Classloader deadlock in Java6 between two bundles
[ https://issues.apache.org/jira/browse/FELIX-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall reopened FELIX-4462: > Classloader deadlock in Java6 between two bundles > - > > Key: FELIX-4462 > URL: https://issues.apache.org/jira/browse/FELIX-4462 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.2.1 > Environment: MacOS 10.7.5, java version "1.6.0_65", Java(TM) SE > Runtime Environment (build 1.6.0_65-b14-462-11M4609), Java HotSpot(TM) 64-Bit > Server VM (build 20.65-b04-462, mixed mode) >Reporter: Stefan Egli >Assignee: Richard S. Hall > Fix For: framework-4.4.0 > > Attachments: FELIX-4462.txt, classLockMonitor.FELIX-4462.patch2, > suggested.synchronized.FELIX-4462.patch, test.reproducingFELIX-4462.patch > > > As discussed on the user list ([0]) there is a deadlock in Java 6 (if bug > 4670071 [2] is not fixed). The problem is the hidden, implicit > ClassLoader.loadClassInternal which is is synchronized(this) in that case. > Consider the following scenario: > * bundle 2 wants to load a class of bundle 1 - hence is not synchronized > with bundle 1's classloader - thus uses the m_classLocks locking mechanism to > lock bundle 1's classloader for the particular class being loaded. Then calls > defineClass (with bundle 1's classloader) > * before it can do so, bundle 1 wants to load the same class (of bundle 1) - > hence does a synchronized loadClassInternal. then reaches the m_classLocks > locking mechanism and notices that there's another thread loading the class > -> this results in the deadlock reported. > There's multiple fixes for this: > * use Java 7 > * use -XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass > * create a special Java 6 classloader (Java 7 would use the current one) > which does a plain synchronized findClass() - and replaces all > synchronized(m_classLocks) with synchronized(this) > [0] http://markmail.org/thread/crwqzqobxgob7q3n > [1] http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4670071 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (FELIX-4462) Classloader deadlock in Java6 between two bundles
[ https://issues.apache.org/jira/browse/FELIX-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall resolved FELIX-4462. Resolution: Fixed Assignee: Richard S. Hall Ok, great. I've applied the fix, so please close this issue if satisfied. Thanks. > Classloader deadlock in Java6 between two bundles > - > > Key: FELIX-4462 > URL: https://issues.apache.org/jira/browse/FELIX-4462 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.2.1 > Environment: MacOS 10.7.5, java version "1.6.0_65", Java(TM) SE > Runtime Environment (build 1.6.0_65-b14-462-11M4609), Java HotSpot(TM) 64-Bit > Server VM (build 20.65-b04-462, mixed mode) >Reporter: Stefan Egli >Assignee: Richard S. Hall > Attachments: FELIX-4462.txt, classLockMonitor.FELIX-4462.patch2, > suggested.synchronized.FELIX-4462.patch, test.reproducingFELIX-4462.patch > > > As discussed on the user list ([0]) there is a deadlock in Java 6 (if bug > 4670071 [2] is not fixed). The problem is the hidden, implicit > ClassLoader.loadClassInternal which is is synchronized(this) in that case. > Consider the following scenario: > * bundle 2 wants to load a class of bundle 1 - hence is not synchronized > with bundle 1's classloader - thus uses the m_classLocks locking mechanism to > lock bundle 1's classloader for the particular class being loaded. Then calls > defineClass (with bundle 1's classloader) > * before it can do so, bundle 1 wants to load the same class (of bundle 1) - > hence does a synchronized loadClassInternal. then reaches the m_classLocks > locking mechanism and notices that there's another thread loading the class > -> this results in the deadlock reported. > There's multiple fixes for this: > * use Java 7 > * use -XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass > * create a special Java 6 classloader (Java 7 would use the current one) > which does a plain synchronized findClass() - and replaces all > synchronized(m_classLocks) with synchronized(this) > [0] http://markmail.org/thread/crwqzqobxgob7q3n > [1] http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4670071 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (FELIX-4462) Classloader deadlock in Java6 between two bundles
[ https://issues.apache.org/jira/browse/FELIX-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli closed FELIX-4462. -- Thanks! Test works fine with the fix now. > Classloader deadlock in Java6 between two bundles > - > > Key: FELIX-4462 > URL: https://issues.apache.org/jira/browse/FELIX-4462 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.2.1 > Environment: MacOS 10.7.5, java version "1.6.0_65", Java(TM) SE > Runtime Environment (build 1.6.0_65-b14-462-11M4609), Java HotSpot(TM) 64-Bit > Server VM (build 20.65-b04-462, mixed mode) >Reporter: Stefan Egli >Assignee: Richard S. Hall > Attachments: FELIX-4462.txt, classLockMonitor.FELIX-4462.patch2, > suggested.synchronized.FELIX-4462.patch, test.reproducingFELIX-4462.patch > > > As discussed on the user list ([0]) there is a deadlock in Java 6 (if bug > 4670071 [2] is not fixed). The problem is the hidden, implicit > ClassLoader.loadClassInternal which is is synchronized(this) in that case. > Consider the following scenario: > * bundle 2 wants to load a class of bundle 1 - hence is not synchronized > with bundle 1's classloader - thus uses the m_classLocks locking mechanism to > lock bundle 1's classloader for the particular class being loaded. Then calls > defineClass (with bundle 1's classloader) > * before it can do so, bundle 1 wants to load the same class (of bundle 1) - > hence does a synchronized loadClassInternal. then reaches the m_classLocks > locking mechanism and notices that there's another thread loading the class > -> this results in the deadlock reported. > There's multiple fixes for this: > * use Java 7 > * use -XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass > * create a special Java 6 classloader (Java 7 would use the current one) > which does a plain synchronized findClass() - and replaces all > synchronized(m_classLocks) with synchronized(this) > [0] http://markmail.org/thread/crwqzqobxgob7q3n > [1] http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4670071 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FELIX-4462) Classloader deadlock in Java6 between two bundles
[ https://issues.apache.org/jira/browse/FELIX-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall updated FELIX-4462: --- Attachment: FELIX-4462.txt I've attached a patch that tries to determine if we are using a parallel class loader or not. If so, it uses the class locks list as the lock object, if not, it uses the class loader itself as the lock object. Please test this patch and see if it works. Thanks. > Classloader deadlock in Java6 between two bundles > - > > Key: FELIX-4462 > URL: https://issues.apache.org/jira/browse/FELIX-4462 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.2.1 > Environment: MacOS 10.7.5, java version "1.6.0_65", Java(TM) SE > Runtime Environment (build 1.6.0_65-b14-462-11M4609), Java HotSpot(TM) 64-Bit > Server VM (build 20.65-b04-462, mixed mode) >Reporter: Stefan Egli > Attachments: FELIX-4462.txt, suggested.synchronized.FELIX-4462.patch, > test.reproducingFELIX-4462.patch > > > As discussed on the user list ([0]) there is a deadlock in Java 6 (if bug > 4670071 [2] is not fixed). The problem is the hidden, implicit > ClassLoader.loadClassInternal which is is synchronized(this) in that case. > Consider the following scenario: > * bundle 2 wants to load a class of bundle 1 - hence is not synchronized > with bundle 1's classloader - thus uses the m_classLocks locking mechanism to > lock bundle 1's classloader for the particular class being loaded. Then calls > defineClass (with bundle 1's classloader) > * before it can do so, bundle 1 wants to load the same class (of bundle 1) - > hence does a synchronized loadClassInternal. then reaches the m_classLocks > locking mechanism and notices that there's another thread loading the class > -> this results in the deadlock reported. > There's multiple fixes for this: > * use Java 7 > * use -XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass > * create a special Java 6 classloader (Java 7 would use the current one) > which does a plain synchronized findClass() - and replaces all > synchronized(m_classLocks) with synchronized(this) > [0] http://markmail.org/thread/crwqzqobxgob7q3n > [1] http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4670071 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FELIX-4462) Classloader deadlock in Java6 between two bundles
[ https://issues.apache.org/jira/browse/FELIX-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli updated FELIX-4462: --- Attachment: classLockMonitor.FELIX-4462.patch2 Attached a patch which replaces the synchronization monitor of m_classLocks to this. With this fix the Java6DeadlockTest succeeds. > Classloader deadlock in Java6 between two bundles > - > > Key: FELIX-4462 > URL: https://issues.apache.org/jira/browse/FELIX-4462 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.2.1 > Environment: MacOS 10.7.5, java version "1.6.0_65", Java(TM) SE > Runtime Environment (build 1.6.0_65-b14-462-11M4609), Java HotSpot(TM) 64-Bit > Server VM (build 20.65-b04-462, mixed mode) >Reporter: Stefan Egli > Attachments: FELIX-4462.txt, classLockMonitor.FELIX-4462.patch2, > suggested.synchronized.FELIX-4462.patch, test.reproducingFELIX-4462.patch > > > As discussed on the user list ([0]) there is a deadlock in Java 6 (if bug > 4670071 [2] is not fixed). The problem is the hidden, implicit > ClassLoader.loadClassInternal which is is synchronized(this) in that case. > Consider the following scenario: > * bundle 2 wants to load a class of bundle 1 - hence is not synchronized > with bundle 1's classloader - thus uses the m_classLocks locking mechanism to > lock bundle 1's classloader for the particular class being loaded. Then calls > defineClass (with bundle 1's classloader) > * before it can do so, bundle 1 wants to load the same class (of bundle 1) - > hence does a synchronized loadClassInternal. then reaches the m_classLocks > locking mechanism and notices that there's another thread loading the class > -> this results in the deadlock reported. > There's multiple fixes for this: > * use Java 7 > * use -XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass > * create a special Java 6 classloader (Java 7 would use the current one) > which does a plain synchronized findClass() - and replaces all > synchronized(m_classLocks) with synchronized(this) > [0] http://markmail.org/thread/crwqzqobxgob7q3n > [1] http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4670071 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FELIX-4462) Classloader deadlock in Java6 between two bundles
[ https://issues.apache.org/jira/browse/FELIX-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13940572#comment-13940572 ] Stefan Egli commented on FELIX-4462: [~rickhall], yes, with your patch Java6DeadlockTest succeeds. > Classloader deadlock in Java6 between two bundles > - > > Key: FELIX-4462 > URL: https://issues.apache.org/jira/browse/FELIX-4462 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.2.1 > Environment: MacOS 10.7.5, java version "1.6.0_65", Java(TM) SE > Runtime Environment (build 1.6.0_65-b14-462-11M4609), Java HotSpot(TM) 64-Bit > Server VM (build 20.65-b04-462, mixed mode) >Reporter: Stefan Egli > Attachments: FELIX-4462.txt, classLockMonitor.FELIX-4462.patch2, > suggested.synchronized.FELIX-4462.patch, test.reproducingFELIX-4462.patch > > > As discussed on the user list ([0]) there is a deadlock in Java 6 (if bug > 4670071 [2] is not fixed). The problem is the hidden, implicit > ClassLoader.loadClassInternal which is is synchronized(this) in that case. > Consider the following scenario: > * bundle 2 wants to load a class of bundle 1 - hence is not synchronized > with bundle 1's classloader - thus uses the m_classLocks locking mechanism to > lock bundle 1's classloader for the particular class being loaded. Then calls > defineClass (with bundle 1's classloader) > * before it can do so, bundle 1 wants to load the same class (of bundle 1) - > hence does a synchronized loadClassInternal. then reaches the m_classLocks > locking mechanism and notices that there's another thread loading the class > -> this results in the deadlock reported. > There's multiple fixes for this: > * use Java 7 > * use -XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass > * create a special Java 6 classloader (Java 7 would use the current one) > which does a plain synchronized findClass() - and replaces all > synchronized(m_classLocks) with synchronized(this) > [0] http://markmail.org/thread/crwqzqobxgob7q3n > [1] http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4670071 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FELIX-4462) Classloader deadlock in Java6 between two bundles
[ https://issues.apache.org/jira/browse/FELIX-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli updated FELIX-4462: --- Attachment: suggested.synchronized.FELIX-4462.patch Attached the synchronized findClass as mentioned in the description of this ticket. This would fix the deadlock encountered - but prevents parallel classloading for Java 7 onwards. So maybe there's a better solution... > Classloader deadlock in Java6 between two bundles > - > > Key: FELIX-4462 > URL: https://issues.apache.org/jira/browse/FELIX-4462 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.2.1 > Environment: MacOS 10.7.5, java version "1.6.0_65", Java(TM) SE > Runtime Environment (build 1.6.0_65-b14-462-11M4609), Java HotSpot(TM) 64-Bit > Server VM (build 20.65-b04-462, mixed mode) >Reporter: Stefan Egli > Attachments: suggested.synchronized.FELIX-4462.patch, > test.reproducingFELIX-4462.patch > > > As discussed on the user list ([0]) there is a deadlock in Java 6 (if bug > 4670071 [2] is not fixed). The problem is the hidden, implicit > ClassLoader.loadClassInternal which is is synchronized(this) in that case. > Consider the following scenario: > * bundle 2 wants to load a class of bundle 1 - hence is not synchronized > with bundle 1's classloader - thus uses the m_classLocks locking mechanism to > lock bundle 1's classloader for the particular class being loaded. Then calls > defineClass (with bundle 1's classloader) > * before it can do so, bundle 1 wants to load the same class (of bundle 1) - > hence does a synchronized loadClassInternal. then reaches the m_classLocks > locking mechanism and notices that there's another thread loading the class > -> this results in the deadlock reported. > There's multiple fixes for this: > * use Java 7 > * use -XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass > * create a special Java 6 classloader (Java 7 would use the current one) > which does a plain synchronized findClass() - and replaces all > synchronized(m_classLocks) with synchronized(this) > [0] http://markmail.org/thread/crwqzqobxgob7q3n > [1] http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4670071 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FELIX-4462) Classloader deadlock in Java6 between two bundles
[ https://issues.apache.org/jira/browse/FELIX-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli updated FELIX-4462: --- Attachment: test.reproducingFELIX-4462.patch Adding a patch which contains a test (Java6DeadlockTest) that reproduces the deadlock. I had a problem reproducing it via maven (mvn clean test), there is succeeds, but when running it in Eclipse it indeed reproduces the deadlock. When running it in Eclipse with '-XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass' it succeeds. > Classloader deadlock in Java6 between two bundles > - > > Key: FELIX-4462 > URL: https://issues.apache.org/jira/browse/FELIX-4462 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.2.1 > Environment: MacOS 10.7.5, java version "1.6.0_65", Java(TM) SE > Runtime Environment (build 1.6.0_65-b14-462-11M4609), Java HotSpot(TM) 64-Bit > Server VM (build 20.65-b04-462, mixed mode) >Reporter: Stefan Egli > Attachments: test.reproducingFELIX-4462.patch > > > As discussed on the user list ([0]) there is a deadlock in Java 6 (if bug > 4670071 [2] is not fixed). The problem is the hidden, implicit > ClassLoader.loadClassInternal which is is synchronized(this) in that case. > Consider the following scenario: > * bundle 2 wants to load a class of bundle 1 - hence is not synchronized > with bundle 1's classloader - thus uses the m_classLocks locking mechanism to > lock bundle 1's classloader for the particular class being loaded. Then calls > defineClass (with bundle 1's classloader) > * before it can do so, bundle 1 wants to load the same class (of bundle 1) - > hence does a synchronized loadClassInternal. then reaches the m_classLocks > locking mechanism and notices that there's another thread loading the class > -> this results in the deadlock reported. > There's multiple fixes for this: > * use Java 7 > * use -XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass > * create a special Java 6 classloader (Java 7 would use the current one) > which does a plain synchronized findClass() - and replaces all > synchronized(m_classLocks) with synchronized(this) > [0] http://markmail.org/thread/crwqzqobxgob7q3n > [1] http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4670071 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (FELIX-4462) Classloader deadlock in Java6 between two bundles
Stefan Egli created FELIX-4462: -- Summary: Classloader deadlock in Java6 between two bundles Key: FELIX-4462 URL: https://issues.apache.org/jira/browse/FELIX-4462 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-4.2.1 Environment: MacOS 10.7.5, java version "1.6.0_65", Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609), Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode) Reporter: Stefan Egli As discussed on the user list ([0]) there is a deadlock in Java 6 (if bug 4670071 [2] is not fixed). The problem is the hidden, implicit ClassLoader.loadClassInternal which is is synchronized(this) in that case. Consider the following scenario: * bundle 2 wants to load a class of bundle 1 - hence is not synchronized with bundle 1's classloader - thus uses the m_classLocks locking mechanism to lock bundle 1's classloader for the particular class being loaded. Then calls defineClass (with bundle 1's classloader) * before it can do so, bundle 1 wants to load the same class (of bundle 1) - hence does a synchronized loadClassInternal. then reaches the m_classLocks locking mechanism and notices that there's another thread loading the class -> this results in the deadlock reported. There's multiple fixes for this: * use Java 7 * use -XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass * create a special Java 6 classloader (Java 7 would use the current one) which does a plain synchronized findClass() - and replaces all synchronized(m_classLocks) with synchronized(this) [0] http://markmail.org/thread/crwqzqobxgob7q3n [1] http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4670071 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FELIX-4461) Update to ASM 5 for Java 8 compatibility
[ https://issues.apache.org/jira/browse/FELIX-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated FELIX-4461: --- Description: ASM 5.0 is out (http://mail.ow2.org/wws/arc/asm/2014-03/msg00012.html ) with Java 8 support. I've validated that the build works just by updating versions, although I did have to switch to the debug version since asm-all artifact seems broken ( http://mail.ow2.org/wws/arc/asm/2014-03/msg00020.html ) . I'll submit a patch once that artifact gets a proper release. was: ASM 5.0 is out ( [announcement|http://mail.ow2.org/wws/arc/asm/2014-03/msg00012.html] ) with Java 8 support. I've validated that the build works just by updating versions, although I did have to switch to the debug version since [asm-all artifact seems broken|http://mail.ow2.org/wws/arc/asm/2014-03/msg00020.html] . I'll submit a patch once that artifact gets a proper release. > Update to ASM 5 for Java 8 compatibility > > > Key: FELIX-4461 > URL: https://issues.apache.org/jira/browse/FELIX-4461 > Project: Felix > Issue Type: Improvement > Components: SCR Tooling >Reporter: Robert Munteanu > > ASM 5.0 is out (http://mail.ow2.org/wws/arc/asm/2014-03/msg00012.html ) with > Java 8 support. I've validated that the build works just by updating > versions, although I did have to switch to the debug version since asm-all > artifact seems broken ( http://mail.ow2.org/wws/arc/asm/2014-03/msg00020.html > ) . > I'll submit a patch once that artifact gets a proper release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (FELIX-4461) Update to ASM 5 for Java 8 compatibility
Robert Munteanu created FELIX-4461: -- Summary: Update to ASM 5 for Java 8 compatibility Key: FELIX-4461 URL: https://issues.apache.org/jira/browse/FELIX-4461 Project: Felix Issue Type: Improvement Components: SCR Tooling Reporter: Robert Munteanu ASM 5.0 is out ( [announcement|http://mail.ow2.org/wws/arc/asm/2014-03/msg00012.html] ) with Java 8 support. I've validated that the build works just by updating versions, although I did have to switch to the debug version since [asm-all artifact seems broken|http://mail.ow2.org/wws/arc/asm/2014-03/msg00020.html] . I'll submit a patch once that artifact gets a proper release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FELIX-4436) DirectoryWatcher should not refresh transformed bundles on every start-up
[
https://issues.apache.org/jira/browse/FELIX-4436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13940448#comment-13940448
]
metatech commented on FELIX-4436:
-
I tested using Guillaume's commit version.
Indeed the Blueprint XML are not detected anymore as "installed" on every
start-up.
However, I see now that the "activemq-broker.xml" gets restarted during
start-up, which generates many errors in depending bundles.
I also see that the "cfg" files in the "etc" directory are still detected as
"installed" on every start-up, although this does not seem to cause any harm.
Below is the stack trace when the "activemq-broker.xml" is stopped during
start-up, if it can help.
{code}
"fileinstall-C:\smx\servicemix/etc" daemon prio=6 tid=0x0a18e000
nid=0x1210 at breakpoint[0x0bfbf000]
java.lang.Thread.State: RUNNABLE
at org.apache.felix.framework.Felix.stopBundle(Felix.java:2217)
at org.apache.felix.framework.BundleImpl.stop(BundleImpl.java:963)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.stopTransient(DirectoryWatcher.java:1214)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.update(DirectoryWatcher.java:1156)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.update(DirectoryWatcher.java:935)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:498)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:308)
{code}
> DirectoryWatcher should not refresh transformed bundles on every start-up
> -
>
> Key: FELIX-4436
> URL: https://issues.apache.org/jira/browse/FELIX-4436
> Project: Felix
> Issue Type: Bug
> Components: File Install
>Affects Versions: fileinstall-3.2.4
> Environment: ServiceMix 4.5.3
>Reporter: metatech
>Assignee: Guillaume Nodet
>Priority: Minor
> Fix For: fileinstall-3.4.0
>
> Attachments: felix_no_refresh_installed.patch
>
>
> DirectoryWatcher can auto-deploy JAR or XML files placed in a directory.
> Blueprint XML files (containing for instance ActiveMQ factories or JAAS
> realms) are detected as "installed" on every start-up. Prior to FELIX-2066,
> this had no effect. Since FELIX-2066, bundles detected as "installed" are
> now forcibly "refreshed" on every start-up. The impact is that these bundles
> are stopped and restarted during the container start-up. Because there are
> some race conditions (see FELIX-3067), this can prevent those XML files or
> other bundles depending on them from fully starting. Here is a patch which
> avoids restarting those bundles when they were not modified.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
