karaf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf Steppacher (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (KARAF-4522) Instantiating class fails on first try but succeeds on second attempt: java.lang.IllegalStateException: Unknown protocol: mvn
Date Mon, 09 May 2016 07:12:12 GMT

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

Ralf Steppacher updated KARAF-4522:
-----------------------------------
    Description: 
I am trying to deploy a bundle that starts a Camel context via a Blueprint context file. The
bundle depends on a custom Camel component to subscribe to LDAP updates, which again depends
on the UnboundID SDK.

{noformat}
bundle: camel context --> bundle: custom camel component --> bundle: UnboundID SDK
{noformat}

The UnboundID SDK offers a call-back interface {{DisconnectHandler}} which I implement in
the custom camel component. In the call-back implementation I spawn a new thread that attempts
to re-establish the connection at a certain interval. Instantiating this thread fails consistently
on the first attempt, but always succeeds on the second.

If I wrap the call to {{new ReconnectionThread}} in a loop like so:

{code:java}
success = false;
while(!success) {
  try {
    ReconnectThread rt = new ReconnectThread(...);
    success = true;
  } catch (Exception e) {
    LOG.warn("Failed to spawn LDAP re-connection thread.", e);
  } 
}
{code}

Then the first attempt fails consistently while the second time around it consistently succeeds.

The exception I receive is the following:

{noformat}
2016-05-09 08:37:24,492 | WARN  | dap:389 (closed) | ReconnectingDisconnectHandler    | 53
- ch.vivates.ams.camel-uldap - 4.0.9.SNAPSHOT |  | Failed to spawn LDAP re-connection thread.
java.lang.IllegalStateException: Unknown protocol: mvn
	at org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:482)[org.apache.felix.framework-5.4.0.jar:]
	at org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:474)[org.apache.felix.framework-5.4.0.jar:]
	at java.net.URL.toExternalForm(URL.java:929)[:1.8.0_77]
	at java.net.URL.toString(URL.java:915)[:1.8.0_77]
	at java.lang.ClassLoader.defineClassSourceLocation(ClassLoader.java:678)[:1.8.0_77]
	at java.lang.ClassLoader.defineClass(ClassLoader.java:762)[:1.8.0_77]
	at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2370)[org.apache.felix.framework-5.4.0.jar:]
	at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2154)[org.apache.felix.framework-5.4.0.jar:]
	at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1542)[org.apache.felix.framework-5.4.0.jar:]
	at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)[org.apache.felix.framework-5.4.0.jar:]
	at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)[org.apache.felix.framework-5.4.0.jar:]
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)[:1.8.0_77]
	at ch.vivates.ams.camel.compoment.uldap.unboundid.ReconnectingDisconnectHandler.handleDisconnect(ReconnectingDisconnectHandler.java:44)[53:ch.vivates.ams.camel-uldap:4.0.9.SNAPSHOT]
	at com.unboundid.ldap.sdk.DisconnectInfo.notifyDisconnectHandler(DisconnectInfo.java:149)[56:com.unboundid.ldap.sdk.se:3.1.1]
	at com.unboundid.ldap.sdk.LDAPConnectionInternals.close(LDAPConnectionInternals.java:665)[56:com.unboundid.ldap.sdk.se:3.1.1]
	at com.unboundid.ldap.sdk.LDAPConnection.setClosed(LDAPConnection.java:4431)[56:com.unboundid.ldap.sdk.se:3.1.1]
	at com.unboundid.ldap.sdk.LDAPConnectionReader.closeInternal(LDAPConnectionReader.java:1089)[56:com.unboundid.ldap.sdk.se:3.1.1]
	at com.unboundid.ldap.sdk.LDAPConnectionReader.run(LDAPConnectionReader.java:444)[56:com.unboundid.ldap.sdk.se:3.1.1]
{noformat}

It appears the problem is limited to bundle deployment time. If the LDAP server is available
while the bundle gets deployed and only fails later, then the reconnection thread is spawned
on the first attempt.

Another thing I have noticed: The creation of the reconnection thread only fails when I attempt
to spawn it from the disconnect handler, which is driven by a thread associated to the LDAP
connection ({{LDAPConnectionReader}}). If I try to spawn my reconnect-thread from the thread
that starts the camel component, then this works on the first attempt as well.

The feature file I am using to deploy the bundles is simple:

{code:xml}
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<features xmlns="http://karaf.apache.org/xmlns/features/v1.3.0" name="Features">
    <!-- ... -->
    <feature name="camel-uldap" description="Camel UnboundID LDAP Component" version="4.0.9.SNAPSHOT">
        <details>Camel endpoint to subscribe with an OpenLDAP server and convert updates
to the LDAP into Camel exchanges.</details>
        <feature version="2.16.3" prerequisite="false" dependency="false">camel-core</feature>
        <bundle start-level="89">mvn:ch.vivates.ams/camel-uldap/4.0.9-SNAPSHOT</bundle>
        <bundle>mvn:com.unboundid/unboundid-ldapsdk/3.1.1</bundle>
    </feature>
    <!-- ... -->
</features>
{code}

  was:
I am trying to deploy a bundle that starts a Camel context via a Blueprint context file. The
bundle depends on a custom Camel component to subscribe to LDAP updates, which again depends
on the UnboundID SDK.

{noformat}
bundle: camel context --> bundle: custom camel component --> bundle: UnboundID SDK
{noformat}

The UnboundID SDK offers a call-back interface {{DisconnectHandler}} which I implement in
the custom camel component. In the call-back implementation I spawn a new thread that attempts
to re-establish the connection at a certain interval. Instantiating this thread fails consistently
on the first attempt, but always succeeds on the second.

If I wrap the call to {{new ReconnectionThread}} in a loop like so:

{code:java}
success = false;
while(!success) {
  try {
    ReconnectThread rt = new ReconnectThread(...);
    success = true;
  } catch (Exception e) {
    LOG.warn("Failed to spawn LDAP re-connection thread.", e);
  } 
}
{code}

Then the first attempt fails consistently while the second time around it consistently succeeds.

The exception I receive is the following:

{noformat}
2016-05-09 08:37:24,492 | WARN  | dap:389 (closed) | ReconnectingDisconnectHandler    | 53
- ch.vivates.ams.camel-uldap - 4.0.9.SNAPSHOT |  | Failed to spawn LDAP re-connection thread.
java.lang.IllegalStateException: Unknown protocol: mvn
	at org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:482)[org.apache.felix.framework-5.4.0.jar:]
	at org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:474)[org.apache.felix.framework-5.4.0.jar:]
	at java.net.URL.toExternalForm(URL.java:929)[:1.8.0_77]
	at java.net.URL.toString(URL.java:915)[:1.8.0_77]
	at java.lang.ClassLoader.defineClassSourceLocation(ClassLoader.java:678)[:1.8.0_77]
	at java.lang.ClassLoader.defineClass(ClassLoader.java:762)[:1.8.0_77]
	at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2370)[org.apache.felix.framework-5.4.0.jar:]
	at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2154)[org.apache.felix.framework-5.4.0.jar:]
	at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1542)[org.apache.felix.framework-5.4.0.jar:]
	at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)[org.apache.felix.framework-5.4.0.jar:]
	at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)[org.apache.felix.framework-5.4.0.jar:]
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)[:1.8.0_77]
	at ch.vivates.ams.camel.compoment.uldap.unboundid.ReconnectingDisconnectHandler.handleDisconnect(ReconnectingDisconnectHandler.java:44)[53:ch.vivates.ams.camel-uldap:4.0.9.SNAPSHOT]
	at com.unboundid.ldap.sdk.DisconnectInfo.notifyDisconnectHandler(DisconnectInfo.java:149)[56:com.unboundid.ldap.sdk.se:3.1.1]
	at com.unboundid.ldap.sdk.LDAPConnectionInternals.close(LDAPConnectionInternals.java:665)[56:com.unboundid.ldap.sdk.se:3.1.1]
	at com.unboundid.ldap.sdk.LDAPConnection.setClosed(LDAPConnection.java:4431)[56:com.unboundid.ldap.sdk.se:3.1.1]
	at com.unboundid.ldap.sdk.LDAPConnectionReader.closeInternal(LDAPConnectionReader.java:1089)[56:com.unboundid.ldap.sdk.se:3.1.1]
	at com.unboundid.ldap.sdk.LDAPConnectionReader.run(LDAPConnectionReader.java:444)[56:com.unboundid.ldap.sdk.se:3.1.1]
{noformat}

It appears the problem is limited to bundle deployment time. If the LDAP server is available
while the bundle gets deployed and only fails later, then the reconnection thread is spawned
on the first attempt.

Another thing I have noticed: The creation of the reconnection thread only fails when I attempt
to spawn it from the disconnect handler, which is driven by a thread associated to the LDAP
connection ({{LDAPConnectionReader}}). If I try to spawn my reconnect-thread from the thread
that starts the camel component, then this works on the first attempt as well.


> Instantiating class fails on first try but succeeds on second attempt: java.lang.IllegalStateException:
Unknown protocol: mvn
> -----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: KARAF-4522
>                 URL: https://issues.apache.org/jira/browse/KARAF-4522
>             Project: Karaf
>          Issue Type: Bug
>          Components: karaf-core
>    Affects Versions: 4.0.5
>         Environment: OSX El Capitan, IBM JDK 8, Camel 2.16.3, Blueprint
>            Reporter: Ralf Steppacher
>
> I am trying to deploy a bundle that starts a Camel context via a Blueprint context file.
The bundle depends on a custom Camel component to subscribe to LDAP updates, which again depends
on the UnboundID SDK.
> {noformat}
> bundle: camel context --> bundle: custom camel component --> bundle: UnboundID
SDK
> {noformat}
> The UnboundID SDK offers a call-back interface {{DisconnectHandler}} which I implement
in the custom camel component. In the call-back implementation I spawn a new thread that attempts
to re-establish the connection at a certain interval. Instantiating this thread fails consistently
on the first attempt, but always succeeds on the second.
> If I wrap the call to {{new ReconnectionThread}} in a loop like so:
> {code:java}
> success = false;
> while(!success) {
>   try {
>     ReconnectThread rt = new ReconnectThread(...);
>     success = true;
>   } catch (Exception e) {
>     LOG.warn("Failed to spawn LDAP re-connection thread.", e);
>   } 
> }
> {code}
> Then the first attempt fails consistently while the second time around it consistently
succeeds.
> The exception I receive is the following:
> {noformat}
> 2016-05-09 08:37:24,492 | WARN  | dap:389 (closed) | ReconnectingDisconnectHandler  
 | 53 - ch.vivates.ams.camel-uldap - 4.0.9.SNAPSHOT |  | Failed to spawn LDAP re-connection
thread.
> java.lang.IllegalStateException: Unknown protocol: mvn
> 	at org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:482)[org.apache.felix.framework-5.4.0.jar:]
> 	at org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:474)[org.apache.felix.framework-5.4.0.jar:]
> 	at java.net.URL.toExternalForm(URL.java:929)[:1.8.0_77]
> 	at java.net.URL.toString(URL.java:915)[:1.8.0_77]
> 	at java.lang.ClassLoader.defineClassSourceLocation(ClassLoader.java:678)[:1.8.0_77]
> 	at java.lang.ClassLoader.defineClass(ClassLoader.java:762)[:1.8.0_77]
> 	at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2370)[org.apache.felix.framework-5.4.0.jar:]
> 	at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2154)[org.apache.felix.framework-5.4.0.jar:]
> 	at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1542)[org.apache.felix.framework-5.4.0.jar:]
> 	at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)[org.apache.felix.framework-5.4.0.jar:]
> 	at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)[org.apache.felix.framework-5.4.0.jar:]
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)[:1.8.0_77]
> 	at ch.vivates.ams.camel.compoment.uldap.unboundid.ReconnectingDisconnectHandler.handleDisconnect(ReconnectingDisconnectHandler.java:44)[53:ch.vivates.ams.camel-uldap:4.0.9.SNAPSHOT]
> 	at com.unboundid.ldap.sdk.DisconnectInfo.notifyDisconnectHandler(DisconnectInfo.java:149)[56:com.unboundid.ldap.sdk.se:3.1.1]
> 	at com.unboundid.ldap.sdk.LDAPConnectionInternals.close(LDAPConnectionInternals.java:665)[56:com.unboundid.ldap.sdk.se:3.1.1]
> 	at com.unboundid.ldap.sdk.LDAPConnection.setClosed(LDAPConnection.java:4431)[56:com.unboundid.ldap.sdk.se:3.1.1]
> 	at com.unboundid.ldap.sdk.LDAPConnectionReader.closeInternal(LDAPConnectionReader.java:1089)[56:com.unboundid.ldap.sdk.se:3.1.1]
> 	at com.unboundid.ldap.sdk.LDAPConnectionReader.run(LDAPConnectionReader.java:444)[56:com.unboundid.ldap.sdk.se:3.1.1]
> {noformat}
> It appears the problem is limited to bundle deployment time. If the LDAP server is available
while the bundle gets deployed and only fails later, then the reconnection thread is spawned
on the first attempt.
> Another thing I have noticed: The creation of the reconnection thread only fails when
I attempt to spawn it from the disconnect handler, which is driven by a thread associated
to the LDAP connection ({{LDAPConnectionReader}}). If I try to spawn my reconnect-thread from
the thread that starts the camel component, then this works on the first attempt as well.
> The feature file I am using to deploy the bundles is simple:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <features xmlns="http://karaf.apache.org/xmlns/features/v1.3.0" name="Features">
>     <!-- ... -->
>     <feature name="camel-uldap" description="Camel UnboundID LDAP Component" version="4.0.9.SNAPSHOT">
>         <details>Camel endpoint to subscribe with an OpenLDAP server and convert
updates to the LDAP into Camel exchanges.</details>
>         <feature version="2.16.3" prerequisite="false" dependency="false">camel-core</feature>
>         <bundle start-level="89">mvn:ch.vivates.ams/camel-uldap/4.0.9-SNAPSHOT</bundle>
>         <bundle>mvn:com.unboundid/unboundid-ldapsdk/3.1.1</bundle>
>     </feature>
>     <!-- ... -->
> </features>
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message