[jira] [Updated] (RIVER-468) SSL Client credentials are not found with JDK 11.0.3 and greater
[
https://issues.apache.org/jira/browse/RIVER-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Ellis updated RIVER-468:
--
Description:
SSL Client Authentication fails with JDK 11.0.3 and greater due to changes with
the JVM. The JVM change prevents Apache River services from communicating with
each other if SSL Client Authentication is used.
The invocation of ClientAuthManager.chooseClientAlias() was changed with JDK
11.0.3. Prior versions would invoke chooseClientAlias once with multiple
keyType elements. JDK 11.0.3 and later versions invoke chooseClientAlias
multiple times with a single element in the keytype array.
Ex.
JDK 11.0.2 and earlier:
{code:java}
choseClientAlias({ "EC", "RSA", "DSA" }, socket);{code}
JDK 11.0.3 and greater:
{code:java}
for (String keyType : { "EC", "RSA", "DSA" }) {
choseClientAlias({ keyType }, socket);
}
{code}
ClientAuthManger.java was modified to store the SecurityException or
GeneralSecurityException in a map based upon the keytype. This allows River to
work with older and later versions of the JVM. The attached patch is based upon
the Apache River 3.0 branch.
[^ClientAuthManager-1.patch]
was:
SSL Client Authentication fails with JDK 11.0.3 and greater due to changes with
the JVM. The JVM change prevents Apache River services from communicating with
each other if SSL Client Authentication is used.
The invocation of ClientAuthManager.chooseClientAlias() was changed with JDK
11.0.3. Prior versions would invoke chooseClientAlias once with multiple
keyType elements. JDK 11.0.3 and later versions invoke chooseClientAlias
multiple times with a single element in the keytype array.
Ex.
JDK 11.0.2 and earlier:
choseClientAlias(\{ "EC", "RSA", "DSA" }, socket);
JDK 11.0.3 and greater:
{code:java}
for (String keyType : { "EC", "RSA", "DSA" }) {
choseClientAlias({ keyType }, socket);
}
{code}
ClientAuthManger.java was modified to store the SecurityException or
GeneralSecurityException in a map based upon the keytype. This allows River to
work with older and later versions of the JVM. The attached patch is based upon
the Apache River 3.0 branch.
[^ClientAuthManager-1.patch]
> SSL Client credentials are not found with JDK 11.0.3 and greater
>
>
> Key: RIVER-468
> URL: https://issues.apache.org/jira/browse/RIVER-468
> Project: River
> Issue Type: Bug
> Components: net_jini_jeri
>Affects Versions: River_3.0.1
>Reporter: Shawn Ellis
>Priority: Major
> Attachments: ClientAuthManager-1.patch
>
>
> SSL Client Authentication fails with JDK 11.0.3 and greater due to changes
> with the JVM. The JVM change prevents Apache River services from
> communicating with each other if SSL Client Authentication is used.
> The invocation of ClientAuthManager.chooseClientAlias() was changed with JDK
> 11.0.3. Prior versions would invoke chooseClientAlias once with multiple
> keyType elements. JDK 11.0.3 and later versions invoke chooseClientAlias
> multiple times with a single element in the keytype array.
> Ex.
> JDK 11.0.2 and earlier:
> {code:java}
> choseClientAlias({ "EC", "RSA", "DSA" }, socket);{code}
> JDK 11.0.3 and greater:
>
> {code:java}
> for (String keyType : { "EC", "RSA", "DSA" }) {
> choseClientAlias({ keyType }, socket);
> }
> {code}
>
> ClientAuthManger.java was modified to store the SecurityException or
> GeneralSecurityException in a map based upon the keytype. This allows River
> to work with older and later versions of the JVM. The attached patch is based
> upon the Apache River 3.0 branch.
>
> [^ClientAuthManager-1.patch]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (RIVER-468) SSL Client credentials are not found with JDK 11.0.3 and greater
[
https://issues.apache.org/jira/browse/RIVER-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Ellis updated RIVER-468:
--
Description:
SSL Client Authentication fails with JDK 11.0.3 and greater due to changes with
the JVM. The JVM change prevents Apache River services from communicating with
each other if SSL Client Authentication is used.
The invocation of ClientAuthManager.chooseClientAlias() was changed with JDK
11.0.3. Prior versions would invoke chooseClientAlias once with multiple
keyType elements. JDK 11.0.3 and later versions invoke chooseClientAlias
multiple times with a single element in the keytype array.
Ex.
JDK 11.0.2 and earlier:
{code:java}
choseClientAlias({ "EC", "RSA", "DSA" }, socket);{code}
JDK 11.0.3 and greater:
{code:java}
for (String keyType : { "EC", "RSA", "DSA" }) {
choseClientAlias({ keyType }, socket);
}
{code}
ClientAuthManger.java was modified to store the SecurityException or
GeneralSecurityException in a map based upon the keytype. This allows River to
work with older and later versions of the JVM. The attached patch is based upon
the Apache River 3.0 branch.
[^ClientAuthManager-1.patch]
was:
SSL Client Authentication fails with JDK 11.0.3 and greater due to changes with
the JVM. The JVM change prevents Apache River services from communicating with
each other if SSL Client Authentication is used.
The invocation of ClientAuthManager.chooseClientAlias() was changed with JDK
11.0.3. Prior versions would invoke chooseClientAlias once with multiple
keyType elements. JDK 11.0.3 and later versions invoke chooseClientAlias
multiple times with a single element in the keytype array.
Ex.
JDK 11.0.2 and earlier:
{code:java}
choseClientAlias({ "EC", "RSA", "DSA" }, socket);{code}
JDK 11.0.3 and greater:
{code:java}
for (String keyType : { "EC", "RSA", "DSA" }) {
choseClientAlias({ keyType }, socket);
}
{code}
ClientAuthManger.java was modified to store the SecurityException or
GeneralSecurityException in a map based upon the keytype. This allows River to
work with older and later versions of the JVM. The attached patch is based upon
the Apache River 3.0 branch.
[^ClientAuthManager-1.patch]
> SSL Client credentials are not found with JDK 11.0.3 and greater
>
>
> Key: RIVER-468
> URL: https://issues.apache.org/jira/browse/RIVER-468
> Project: River
> Issue Type: Bug
> Components: net_jini_jeri
>Affects Versions: River_3.0.1
>Reporter: Shawn Ellis
>Priority: Major
> Attachments: ClientAuthManager-1.patch
>
>
> SSL Client Authentication fails with JDK 11.0.3 and greater due to changes
> with the JVM. The JVM change prevents Apache River services from
> communicating with each other if SSL Client Authentication is used.
> The invocation of ClientAuthManager.chooseClientAlias() was changed with JDK
> 11.0.3. Prior versions would invoke chooseClientAlias once with multiple
> keyType elements. JDK 11.0.3 and later versions invoke chooseClientAlias
> multiple times with a single element in the keytype array.
> Ex.
> JDK 11.0.2 and earlier:
> {code:java}
> choseClientAlias({ "EC", "RSA", "DSA" }, socket);{code}
> JDK 11.0.3 and greater:
>
> {code:java}
> for (String keyType : { "EC", "RSA", "DSA" }) {
> choseClientAlias({ keyType }, socket);
> }
> {code}
>
> ClientAuthManger.java was modified to store the SecurityException or
> GeneralSecurityException in a map based upon the keytype. This allows River
> to work with older and later versions of the JVM. The attached patch is based
> upon the Apache River 3.0 branch.
> [^ClientAuthManager-1.patch]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (RIVER-468) SSL Client credentials are not found with JDK 11.0.3 and greater
[
https://issues.apache.org/jira/browse/RIVER-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Ellis updated RIVER-468:
--
Description:
SSL Client Authentication fails with JDK 11.0.3 and greater due to changes with
the JVM. The JVM change prevents Apache River services from communicating with
each other if SSL Client Authentication is used.
The invocation of ClientAuthManager.chooseClientAlias() was changed with JDK
11.0.3. Prior versions would invoke chooseClientAlias once with multiple
keyType elements. JDK 11.0.3 and later versions invoke chooseClientAlias
multiple times with a single element in the keytype array.
Ex.
JDK 11.0.2 and earlier:
choseClientAlias(\{ "EC", "RSA", "DSA" }, socket);
JDK 11.0.3 and greater:
{code:java}
for (String keyType : { "EC", "RSA", "DSA" }) {
choseClientAlias({ keyType }, socket);
}
{code}
ClientAuthManger.java was modified to store the SecurityException or
GeneralSecurityException in a map based upon the keytype. This allows River to
work with older and later versions of the JVM. The attached patch is based upon
the Apache River 3.0 branch.
[^ClientAuthManager-1.patch]
was:
SSL Client Authentication fails with JDK 11.0.3 and greater due to changes with
the JVM. The JVM change prevents Apache River services from communicating with
each other if SSL Client Authentication is used.
The invocation of ClientAuthManager.chooseClientAlias() was changed with JDK
11.0.3. Prior versions would invoke chooseClientAlias once with multiple
keyType elements. JDK 11.0.3 and later versions invoke chooseClientAlias
multiple times with a single element in the keytype array.
Ex.
JDK 11.0.2 and earlier:
choseClientAlias(\{ "EC", "RSA", "DSA" }, socket);
JDK 11.0.3 and greater:
for (String keyType : \{ "EC", "RSA", "DSA" })
{ choseClientAlias(\\{ keyType }
, socket);
}
ClientAuthManger.java was modified to store the SecurityException or
GeneralSecurityException in a map based upon the keytype. This allows River to
work with older and later versions of the JVM. The attached patch is based upon
the Apache River 3.0 branch.
[^ClientAuthManager-1.patch]
> SSL Client credentials are not found with JDK 11.0.3 and greater
>
>
> Key: RIVER-468
> URL: https://issues.apache.org/jira/browse/RIVER-468
> Project: River
> Issue Type: Bug
> Components: net_jini_jeri
>Affects Versions: River_3.0.1
>Reporter: Shawn Ellis
>Priority: Major
> Attachments: ClientAuthManager-1.patch
>
>
> SSL Client Authentication fails with JDK 11.0.3 and greater due to changes
> with the JVM. The JVM change prevents Apache River services from
> communicating with each other if SSL Client Authentication is used.
> The invocation of ClientAuthManager.chooseClientAlias() was changed with JDK
> 11.0.3. Prior versions would invoke chooseClientAlias once with multiple
> keyType elements. JDK 11.0.3 and later versions invoke chooseClientAlias
> multiple times with a single element in the keytype array.
> Ex.
> JDK 11.0.2 and earlier:
> choseClientAlias(\{ "EC", "RSA", "DSA" }, socket);
> JDK 11.0.3 and greater:
>
> {code:java}
> for (String keyType : { "EC", "RSA", "DSA" }) {
> choseClientAlias({ keyType }, socket);
> }
> {code}
>
> ClientAuthManger.java was modified to store the SecurityException or
> GeneralSecurityException in a map based upon the keytype. This allows River
> to work with older and later versions of the JVM. The attached patch is based
> upon the Apache River 3.0 branch.
>
> [^ClientAuthManager-1.patch]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (RIVER-468) SSL Client credentials are not found with JDK 11.0.3 and greater
[
https://issues.apache.org/jira/browse/RIVER-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Ellis updated RIVER-468:
--
Summary: SSL Client credentials are not found with JDK 11.0.3 and greater
(was: SSL Client credentials not found with JDK 11.0.3 and greater)
> SSL Client credentials are not found with JDK 11.0.3 and greater
>
>
> Key: RIVER-468
> URL: https://issues.apache.org/jira/browse/RIVER-468
> Project: River
> Issue Type: Bug
> Components: net_jini_jeri
>Affects Versions: River_3.0.1
>Reporter: Shawn Ellis
>Priority: Major
> Attachments: ClientAuthManager-1.patch
>
>
> SSL Client Authentication fails with JDK 11.0.3 and greater due to changes
> with the JVM. The JVM change prevents Apache River services from
> communicating with each other if SSL Client Authentication is used.
> The invocation of ClientAuthManager.chooseClientAlias() was changed with JDK
> 11.0.3. Prior versions would invoke chooseClientAlias once with multiple
> keyType elements. JDK 11.0.3 and later versions invoke chooseClientAlias
> multiple times with a single element in the keytype array.
> Ex.
> JDK 11.0.2 and earlier:
> choseClientAlias(\{ "EC", "RSA", "DSA" }, socket);
> JDK 11.0.3 and greater:
> for (String keyType : \{ "EC", "RSA", "DSA" })
> { choseClientAlias(\\{ keyType }
> , socket);
> }
> ClientAuthManger.java was modified to store the SecurityException or
> GeneralSecurityException in a map based upon the keytype. This allows River
> to work with older and later versions of the JVM. The attached patch is based
> upon the Apache River 3.0 branch.
>
> [^ClientAuthManager-1.patch]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (RIVER-468) SSL Client Authentication doesn't work with JDK 11.0.3 and greater
[
https://issues.apache.org/jira/browse/RIVER-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Ellis updated RIVER-468:
--
Description:
SSL Client Authentication fails with JDK 11.0.3 and greater due to changes with
the JVM. The JVM change prevents Apache River services from communicating with
each other if SSL Client Authentication is used.
The invocation of ClientAuthManager.chooseClientAlias() was changed with JDK
11.0.3. Prior versions would invoke chooseClientAlias once with multiple
keyType elements. JDK 11.0.3 and later versions invoke chooseClientAlias
multiple times with a single element in the keytype array.
Ex.
JDK 11.0.2 and earlier:
choseClientAlias(\{ "EC", "RSA", "DSA" }, socket);
JDK 11.0.3 and greater:
for (String keyType : \{ "EC", "RSA", "DSA" })
{ choseClientAlias(\\{ keyType }
, socket);
}
ClientAuthManger.java was modified to store the SecurityException or
GeneralSecurityException in a map based upon the keytype. This allows River to
work with older and later versions of the JVM. The attached patch is based upon
the Apache River 3.0 branch.
[^ClientAuthManager-1.patch]
was:
SSL Client Authentication fails with JDK 11.0.3 and greater due to changes with
the JVM. The JVM change prevents Apache River services from communicating with
each other if SSL Client Authentication is used.
The invocation of ClientAuthManager.chooseClientAlias() was changed with JDK
11.0.3. Prior versions would invoke chooseClientAlias once with multiple
keyType elements. JDK 11.0.3 and later versions invoke chooseClientAlias
multiple times with a single element in the keytype array.
Ex.
JDK 11.0.2 and earlier:
choseClientAlias(\{ "EC", "RSA", "DSA" }, socket);
JDK 11.0.3 and greater:
for (String keyType : \{ "EC", "RSA", "DSA" }) {
choseClientAlias(\{ keyType }, socket);
}
ClientAuthManger.java was modified to store the SecurityException or
GeneralSecurityException in a map based upon the keytype. This allows River to
work with older and later versions of the JVM. The attached patch is based upon
the Apache River 3.0 branch.
> SSL Client Authentication doesn't work with JDK 11.0.3 and greater
> --
>
> Key: RIVER-468
> URL: https://issues.apache.org/jira/browse/RIVER-468
> Project: River
> Issue Type: Bug
> Components: net_jini_jeri
>Affects Versions: River_3.0.1
>Reporter: Shawn Ellis
>Priority: Major
> Attachments: ClientAuthManager-1.patch
>
>
> SSL Client Authentication fails with JDK 11.0.3 and greater due to changes
> with the JVM. The JVM change prevents Apache River services from
> communicating with each other if SSL Client Authentication is used.
> The invocation of ClientAuthManager.chooseClientAlias() was changed with JDK
> 11.0.3. Prior versions would invoke chooseClientAlias once with multiple
> keyType elements. JDK 11.0.3 and later versions invoke chooseClientAlias
> multiple times with a single element in the keytype array.
> Ex.
> JDK 11.0.2 and earlier:
> choseClientAlias(\{ "EC", "RSA", "DSA" }, socket);
> JDK 11.0.3 and greater:
> for (String keyType : \{ "EC", "RSA", "DSA" })
> { choseClientAlias(\\{ keyType }
> , socket);
> }
> ClientAuthManger.java was modified to store the SecurityException or
> GeneralSecurityException in a map based upon the keytype. This allows River
> to work with older and later versions of the JVM. The attached patch is based
> upon the Apache River 3.0 branch.
>
> [^ClientAuthManager-1.patch]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (RIVER-468) SSL Client credentials not found with JDK 11.0.3 and greater
[
https://issues.apache.org/jira/browse/RIVER-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Ellis updated RIVER-468:
--
Summary: SSL Client credentials not found with JDK 11.0.3 and greater
(was: SSL Client Authentication doesn't work with JDK 11.0.3 and greater)
> SSL Client credentials not found with JDK 11.0.3 and greater
>
>
> Key: RIVER-468
> URL: https://issues.apache.org/jira/browse/RIVER-468
> Project: River
> Issue Type: Bug
> Components: net_jini_jeri
>Affects Versions: River_3.0.1
>Reporter: Shawn Ellis
>Priority: Major
> Attachments: ClientAuthManager-1.patch
>
>
> SSL Client Authentication fails with JDK 11.0.3 and greater due to changes
> with the JVM. The JVM change prevents Apache River services from
> communicating with each other if SSL Client Authentication is used.
> The invocation of ClientAuthManager.chooseClientAlias() was changed with JDK
> 11.0.3. Prior versions would invoke chooseClientAlias once with multiple
> keyType elements. JDK 11.0.3 and later versions invoke chooseClientAlias
> multiple times with a single element in the keytype array.
> Ex.
> JDK 11.0.2 and earlier:
> choseClientAlias(\{ "EC", "RSA", "DSA" }, socket);
> JDK 11.0.3 and greater:
> for (String keyType : \{ "EC", "RSA", "DSA" })
> { choseClientAlias(\\{ keyType }
> , socket);
> }
> ClientAuthManger.java was modified to store the SecurityException or
> GeneralSecurityException in a map based upon the keytype. This allows River
> to work with older and later versions of the JVM. The attached patch is based
> upon the Apache River 3.0 branch.
>
> [^ClientAuthManager-1.patch]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (RIVER-468) SSL Client Authentication doesn't work with JDK 11.0.3 and greater
[
https://issues.apache.org/jira/browse/RIVER-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Ellis updated RIVER-468:
--
Attachment: ClientAuthManager-1.patch
> SSL Client Authentication doesn't work with JDK 11.0.3 and greater
> --
>
> Key: RIVER-468
> URL: https://issues.apache.org/jira/browse/RIVER-468
> Project: River
> Issue Type: Bug
> Components: net_jini_jeri
>Affects Versions: River_3.0.1
>Reporter: Shawn Ellis
>Priority: Major
> Attachments: ClientAuthManager-1.patch
>
>
> SSL Client Authentication fails with JDK 11.0.3 and greater due to changes
> with the JVM. The JVM change prevents Apache River services from
> communicating with each other if SSL Client Authentication is used.
> The invocation of ClientAuthManager.chooseClientAlias() was changed with JDK
> 11.0.3. Prior versions would invoke chooseClientAlias once with multiple
> keyType elements. JDK 11.0.3 and later versions invoke chooseClientAlias
> multiple times with a single element in the keytype array.
> Ex.
> JDK 11.0.2 and earlier:
> choseClientAlias(\{ "EC", "RSA", "DSA" }, socket);
> JDK 11.0.3 and greater:
> for (String keyType : \{ "EC", "RSA", "DSA" }) {
> choseClientAlias(\{ keyType }, socket);
> }
> ClientAuthManger.java was modified to store the SecurityException or
> GeneralSecurityException in a map based upon the keytype. This allows River
> to work with older and later versions of the JVM. The attached patch is based
> upon the Apache River 3.0 branch.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (RIVER-468) SSL Client Authentication doesn't work with JDK 11.0.3 and greater
Shawn Ellis created RIVER-468:
-
Summary: SSL Client Authentication doesn't work with JDK 11.0.3
and greater
Key: RIVER-468
URL: https://issues.apache.org/jira/browse/RIVER-468
Project: River
Issue Type: Bug
Components: net_jini_jeri
Affects Versions: River_3.0.1
Reporter: Shawn Ellis
SSL Client Authentication fails with JDK 11.0.3 and greater due to changes with
the JVM. The JVM change prevents Apache River services from communicating with
each other if SSL Client Authentication is used.
The invocation of ClientAuthManager.chooseClientAlias() was changed with JDK
11.0.3. Prior versions would invoke chooseClientAlias once with multiple
keyType elements. JDK 11.0.3 and later versions invoke chooseClientAlias
multiple times with a single element in the keytype array.
Ex.
JDK 11.0.2 and earlier:
choseClientAlias(\{ "EC", "RSA", "DSA" }, socket);
JDK 11.0.3 and greater:
for (String keyType : \{ "EC", "RSA", "DSA" }) {
choseClientAlias(\{ keyType }, socket);
}
ClientAuthManger.java was modified to store the SecurityException or
GeneralSecurityException in a map based upon the keytype. This allows River to
work with older and later versions of the JVM. The attached patch is based upon
the Apache River 3.0 branch.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (RIVER-467) NullPointerException when JoinManager is terminating
Shawn Ellis created RIVER-467:
-
Summary: NullPointerException when JoinManager is terminating
Key: RIVER-467
URL: https://issues.apache.org/jira/browse/RIVER-467
Project: River
Issue Type: Bug
Components: com_sun_jini_lookup
Affects Versions: River_3.0.0
Reporter: Shawn Ellis
Attachments: LeaseRenewalManager-NPE-1.patch
Every now and then I would encounter a NullPointerException with the
JoinManager. The way that I was able to reproduce this problem was to have a
service up and running and then switch the network on my laptop. For example, I
would switch from one wifi network to another.
I've attached a patch that protects against the NullPointerException and seems
to work fine when switching networks. [^LeaseRenewalManager-NPE-1.patch]
{code:java}
Oct 7 14:8:28 CDT SEVERE:thr 652:Exception in thread
"LeaseRenewalManager_thread-3"
Oct 7 14:8:28 CDT SEVERE:thr 652:java.lang.NullPointerException
Oct 7 14:8:28 CDT SEVERE:thr 652: at
net.jini.lookup.JoinManager$ProxyReg.terminate(JoinManager.java:1266)
Oct 7 14:8:28 CDT SEVERE:thr 652: at
net.jini.lookup.JoinManager.removeTasks(JoinManager.java:2774)
Oct 7 14:8:28 CDT SEVERE:thr 652: at
net.jini.lookup.JoinManager.access$400(JoinManager.java:456)
Oct 7 14:8:28 CDT SEVERE:thr 652: at
net.jini.lookup.JoinManager$ProxyReg$DiscLeaseListener.notify(JoinManager.java:1188)
Oct 7 14:8:28 CDT SEVERE:thr 652: at
net.jini.lease.LeaseRenewalManager.tell(LeaseRenewalManager.java:1412)
Oct 7 14:8:28 CDT SEVERE:thr 652: at
net.jini.lease.LeaseRenewalManager.access$500(LeaseRenewalManager.java:322)
Oct 7 14:8:28 CDT SEVERE:thr 652: at
net.jini.lease.LeaseRenewalManager$RenewTask.run(LeaseRenewalManager.java:451)
Oct 7 14:8:28 CDT SEVERE:thr 652: at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
Oct 7 14:8:28 CDT SEVERE:thr 652: at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
Oct 7 14:8:28 CDT SEVERE:thr 652: at
java.base/java.lang.Thread.run(Thread.java:844)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (RIVER-467) NullPointerException when JoinManager is terminating
[
https://issues.apache.org/jira/browse/RIVER-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Ellis updated RIVER-467:
--
Attachment: LeaseRenewalManager-NPE-1.patch
> NullPointerException when JoinManager is terminating
>
>
> Key: RIVER-467
> URL: https://issues.apache.org/jira/browse/RIVER-467
> Project: River
> Issue Type: Bug
> Components: com_sun_jini_lookup
>Affects Versions: River_3.0.0
>Reporter: Shawn Ellis
>Priority: Minor
> Attachments: LeaseRenewalManager-NPE-1.patch
>
>
> Every now and then I would encounter a NullPointerException with the
> JoinManager. The way that I was able to reproduce this problem was to have a
> service up and running and then switch the network on my laptop. For example,
> I would switch from one wifi network to another.
> I've attached a patch that protects against the NullPointerException and
> seems to work fine when switching networks. [^LeaseRenewalManager-NPE-1.patch]
> {code:java}
> Oct 7 14:8:28 CDT SEVERE:thr 652:Exception in thread
> "LeaseRenewalManager_thread-3"
> Oct 7 14:8:28 CDT SEVERE:thr 652:java.lang.NullPointerException
> Oct 7 14:8:28 CDT SEVERE:thr 652: at
> net.jini.lookup.JoinManager$ProxyReg.terminate(JoinManager.java:1266)
> Oct 7 14:8:28 CDT SEVERE:thr 652: at
> net.jini.lookup.JoinManager.removeTasks(JoinManager.java:2774)
> Oct 7 14:8:28 CDT SEVERE:thr 652: at
> net.jini.lookup.JoinManager.access$400(JoinManager.java:456)
> Oct 7 14:8:28 CDT SEVERE:thr 652: at
> net.jini.lookup.JoinManager$ProxyReg$DiscLeaseListener.notify(JoinManager.java:1188)
> Oct 7 14:8:28 CDT SEVERE:thr 652: at
> net.jini.lease.LeaseRenewalManager.tell(LeaseRenewalManager.java:1412)
> Oct 7 14:8:28 CDT SEVERE:thr 652: at
> net.jini.lease.LeaseRenewalManager.access$500(LeaseRenewalManager.java:322)
> Oct 7 14:8:28 CDT SEVERE:thr 652: at
> net.jini.lease.LeaseRenewalManager$RenewTask.run(LeaseRenewalManager.java:451)
> Oct 7 14:8:28 CDT SEVERE:thr 652: at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
> Oct 7 14:8:28 CDT SEVERE:thr 652: at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> Oct 7 14:8:28 CDT SEVERE:thr 652: at
> java.base/java.lang.Thread.run(Thread.java:844)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (RIVER-466) ServiceDiscoveryManager not exiting lookup loop when serviceItems.length >= minMatches
[
https://issues.apache.org/jira/browse/RIVER-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Ellis updated RIVER-466:
--
Description:
The problem occurs when a lookup for only one service is required, but more
than one is found. Currently, the lookup loop only exits if the number of
services found is equivalent to the minMatches or the timeout has expired.
How to Reproduce:
1. Have multiple instances of a service registered with reggie.
2. Have a client call that performs a lookup with a constraint of only one
service
{code:java}
lookup(serviceTemplate, 1, 1, null, 30 * 100){code}
3. The lookup loop will not exit until the timeout has expired even though more
than minMatches were found.
The attached patch causes the lookup loop to be exited which results in less
time for service lookups.
was:
The problem occurs when a lookup for only one service is required, but more
than one is found. Currently, the lookup loop only exits if the number of
services found is equivalent to the minMatches or the timeout has expired.
How to Reproduce:
1. Have multiple instances of a service registered with reggie.
2. Have a client call that performs a lookup with a constraint of only one
service
{code:java}
lookup(serviceTemplate, 1, 1, null, 30 * 100){code}
3. The lookup loop will not exit until the timeout has expired even though more
than minMatches were found.
The attached patch causes the lookup loop to be exited which results in less
time to service lookups.
> ServiceDiscoveryManager not exiting lookup loop when serviceItems.length >=
> minMatches
> --
>
> Key: RIVER-466
> URL: https://issues.apache.org/jira/browse/RIVER-466
> Project: River
> Issue Type: Bug
> Components: net_jini_lookup
>Affects Versions: River_3.0.0
>Reporter: Shawn Ellis
>Priority: Minor
> Attachments: MinMatches.patch
>
>
> The problem occurs when a lookup for only one service is required, but more
> than one is found. Currently, the lookup loop only exits if the number of
> services found is equivalent to the minMatches or the timeout has expired.
> How to Reproduce:
> 1. Have multiple instances of a service registered with reggie.
> 2. Have a client call that performs a lookup with a constraint of only one
> service
>
> {code:java}
> lookup(serviceTemplate, 1, 1, null, 30 * 100){code}
> 3. The lookup loop will not exit until the timeout has expired even though
> more than minMatches were found.
> The attached patch causes the lookup loop to be exited which results in less
> time for service lookups.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (RIVER-466) ServiceDiscoveryManager not exiting lookup loop when serviceItems.length >= minMatches
[
https://issues.apache.org/jira/browse/RIVER-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Ellis updated RIVER-466:
--
Attachment: MinMatches.patch
> ServiceDiscoveryManager not exiting lookup loop when serviceItems.length >=
> minMatches
> --
>
> Key: RIVER-466
> URL: https://issues.apache.org/jira/browse/RIVER-466
> Project: River
> Issue Type: Bug
> Components: net_jini_lookup
>Affects Versions: River_3.0.0
>Reporter: Shawn Ellis
>Priority: Minor
> Attachments: MinMatches.patch
>
>
> The problem occurs when a lookup for only one service is required, but more
> than one is found. Currently, the lookup loop only exits if the number of
> services found is equivalent to the minMatches or the timeout has expired.
> How to Reproduce:
> 1. Have multiple instances of a service registered with reggie.
> 2. Have a client call that performs a lookup with a constraint of only one
> service
>
> {code:java}
> lookup(serviceTemplate, 1, 1, null, 30 * 100){code}
> 3. The lookup loop will not exit until the timeout has expired even though
> more than minMatches were found.
> The attached patch causes the lookup loop to be exited which results in less
> time to service lookups.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (RIVER-466) ServiceDiscoveryManager not exiting lookup loop when serviceItems.length >= minMatches
Shawn Ellis created RIVER-466:
-
Summary: ServiceDiscoveryManager not exiting lookup loop when
serviceItems.length >= minMatches
Key: RIVER-466
URL: https://issues.apache.org/jira/browse/RIVER-466
Project: River
Issue Type: Bug
Components: net_jini_lookup
Affects Versions: River_3.0.0
Reporter: Shawn Ellis
Attachments: MinMatches.patch
The problem occurs when a lookup for only one service is required, but more
than one is found. Currently, the lookup loop only exits if the number of
services found is equivalent to the minMatches or the timeout has expired.
How to Reproduce:
1. Have multiple instances of a service registered with reggie.
2. Have a client call that performs a lookup with a constraint of only one
service
{code:java}
lookup(serviceTemplate, 1, 1, null, 30 * 100){code}
3. The lookup loop will not exit until the timeout has expired even though more
than minMatches were found.
The attached patch causes the lookup loop to be exited which results in less
time to service lookups.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (RIVER-447) Leaked Executor Service Threads in LoadClass
[ https://issues.apache.org/jira/browse/RIVER-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15829774#comment-15829774 ] Shawn Ellis commented on RIVER-447: --- The patch works great! Thanks. > Leaked Executor Service Threads in LoadClass > > > Key: RIVER-447 > URL: https://issues.apache.org/jira/browse/RIVER-447 > Project: River > Issue Type: Bug > Components: net_jini_loader >Affects Versions: River_3.0.0 > Environment: Linux with either JDK 1.7 or 1.8 >Reporter: Shawn Ellis > Labels: PreferredClassLoader, leaks, threads > Attachments: ExecutorShutdown.patch, River-447.patch > > > I am seeing an overall thread usage increase when using Apache River 3.0. I'm > able to reproduce the problem with both JDK 1.7 and 1.8. The issue is that > LoadClass makes use of a loaderMap that contains an Executor Service. After > 10 seconds, the loaderMap will garbage collect the Executor Service, but the > Executor Service will not be shutdown. This leaves the Executor Service > thread still running and waiting for work. > How to Reproduce: > 1. Start up an Apache River 3.0 instance > 2. Have a client connect to the River instance > 3. Wait 10 seconds > 4. Have the client connect to the River instance a second time. The > number > of threads will have increased. > The leaked threads have a stack trace similar to the one below. > > "net.jini.loader.pref.PreferredClassLoader@7af8260a["httpmd://10.0.1.5:9070/reggie-dl.jar;sha=6c5b83e0caec74d5d4226dcd2c2311d29e81ac0a > > httpmd://10.0.1.5:9070/jsk-dl.jar;sha=002bca7b77431ba20385d7ca5be8fa8ec1124a01"]_thread-0" > #30149 prio=5 os_prio=0 tid=0x3fff68f79000 nid=0x5db9 waiting on > condition [0x3ffdc344d000] > java.lang.Thread.State: WAITING (parking) >at sun.misc.Unsafe.park(Native Method) >- parking to wait for <0xf2955ff0> (a > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) >at > java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) >at > java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) >at > java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) >at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) >at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (RIVER-447) Leaked Executor Service Threads in LoadClass
[ https://issues.apache.org/jira/browse/RIVER-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Ellis updated RIVER-447: -- Labels: leaks threads (was: ) > Leaked Executor Service Threads in LoadClass > > > Key: RIVER-447 > URL: https://issues.apache.org/jira/browse/RIVER-447 > Project: River > Issue Type: Bug > Components: net_jini_loader >Affects Versions: River_3.0.0 > Environment: Linux with either JDK 1.7 or 1.8 >Reporter: Shawn Ellis > Labels: PreferredClassLoader, leaks, threads > Attachments: ExecutorShutdown.patch > > > I am seeing an overall thread usage increase when using Apache River 3.0. I'm > able to reproduce the problem with both JDK 1.7 and 1.8. The issue is that > LoadClass makes use of a loaderMap that contains an Executor Service. After > 10 seconds, the loaderMap will garbage collect the Executor Service, but the > Executor Service will not be shutdown. This leaves the Executor Service > thread still running and waiting for work. > How to Reproduce: > 1. Start up an Apache River 3.0 instance > 2. Have a client connect to the River instance > 3. Wait 10 seconds > 4. Have the client connect to the River instance a second time. The > number > of threads will have increased. > The leaked threads have a stack trace similar to the one below. > > "net.jini.loader.pref.PreferredClassLoader@7af8260a["httpmd://10.0.1.5:9070/reggie-dl.jar;sha=6c5b83e0caec74d5d4226dcd2c2311d29e81ac0a > > httpmd://10.0.1.5:9070/jsk-dl.jar;sha=002bca7b77431ba20385d7ca5be8fa8ec1124a01"]_thread-0" > #30149 prio=5 os_prio=0 tid=0x3fff68f79000 nid=0x5db9 waiting on > condition [0x3ffdc344d000] > java.lang.Thread.State: WAITING (parking) >at sun.misc.Unsafe.park(Native Method) >- parking to wait for <0xf2955ff0> (a > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) >at > java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) >at > java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) >at > java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) >at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) >at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (RIVER-447) Leaked Executor Service Threads in LoadClass
[ https://issues.apache.org/jira/browse/RIVER-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Ellis updated RIVER-447: -- Labels: PreferredClassLoader leaks threads (was: leaks threads) > Leaked Executor Service Threads in LoadClass > > > Key: RIVER-447 > URL: https://issues.apache.org/jira/browse/RIVER-447 > Project: River > Issue Type: Bug > Components: net_jini_loader >Affects Versions: River_3.0.0 > Environment: Linux with either JDK 1.7 or 1.8 >Reporter: Shawn Ellis > Labels: PreferredClassLoader, leaks, threads > Attachments: ExecutorShutdown.patch > > > I am seeing an overall thread usage increase when using Apache River 3.0. I'm > able to reproduce the problem with both JDK 1.7 and 1.8. The issue is that > LoadClass makes use of a loaderMap that contains an Executor Service. After > 10 seconds, the loaderMap will garbage collect the Executor Service, but the > Executor Service will not be shutdown. This leaves the Executor Service > thread still running and waiting for work. > How to Reproduce: > 1. Start up an Apache River 3.0 instance > 2. Have a client connect to the River instance > 3. Wait 10 seconds > 4. Have the client connect to the River instance a second time. The > number > of threads will have increased. > The leaked threads have a stack trace similar to the one below. > > "net.jini.loader.pref.PreferredClassLoader@7af8260a["httpmd://10.0.1.5:9070/reggie-dl.jar;sha=6c5b83e0caec74d5d4226dcd2c2311d29e81ac0a > > httpmd://10.0.1.5:9070/jsk-dl.jar;sha=002bca7b77431ba20385d7ca5be8fa8ec1124a01"]_thread-0" > #30149 prio=5 os_prio=0 tid=0x3fff68f79000 nid=0x5db9 waiting on > condition [0x3ffdc344d000] > java.lang.Thread.State: WAITING (parking) >at sun.misc.Unsafe.park(Native Method) >- parking to wait for <0xf2955ff0> (a > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) >at > java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) >at > java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) >at > java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) >at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) >at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (RIVER-447) Leaked Executor Service Threads in LoadClass
[ https://issues.apache.org/jira/browse/RIVER-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15822836#comment-15822836 ] Shawn Ellis edited comment on RIVER-447 at 1/14/17 3:34 PM: I've attached a patch that is a hack which calls ExecutorService.shutdown() when it is being removed. This prevents the threads from being leaked, but I realize that it's probably not the best solution. Thanks for the help. was (Author: ellisvelo): I've attached a patch that is a hack which calls ExecutorService.shutdown() when it is being removed. This prevents the threads from being leaked, but I realize that this probably not the best solution. Thanks for the help. > Leaked Executor Service Threads in LoadClass > > > Key: RIVER-447 > URL: https://issues.apache.org/jira/browse/RIVER-447 > Project: River > Issue Type: Bug > Components: net_jini_loader >Affects Versions: River_3.0.0 > Environment: Linux with either JDK 1.7 or 1.8 >Reporter: Shawn Ellis > Attachments: ExecutorShutdown.patch > > > I am seeing an overall thread usage increase when using Apache River 3.0. I'm > able to reproduce the problem with both JDK 1.7 and 1.8. The issue is that > LoadClass makes use of a loaderMap that contains an Executor Service. After > 10 seconds, the loaderMap will garbage collect the Executor Service, but the > Executor Service will not be shutdown. This leaves the Executor Service > thread still running and waiting for work. > How to Reproduce: > 1. Start up an Apache River 3.0 instance > 2. Have a client connect to the River instance > 3. Wait 10 seconds > 4. Have the client connect to the River instance a second time. The > number > of threads will have increased. > The leaked threads have a stack trace similar to the one below. > > "net.jini.loader.pref.PreferredClassLoader@7af8260a["httpmd://10.0.1.5:9070/reggie-dl.jar;sha=6c5b83e0caec74d5d4226dcd2c2311d29e81ac0a > > httpmd://10.0.1.5:9070/jsk-dl.jar;sha=002bca7b77431ba20385d7ca5be8fa8ec1124a01"]_thread-0" > #30149 prio=5 os_prio=0 tid=0x3fff68f79000 nid=0x5db9 waiting on > condition [0x3ffdc344d000] > java.lang.Thread.State: WAITING (parking) >at sun.misc.Unsafe.park(Native Method) >- parking to wait for <0xf2955ff0> (a > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) >at > java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) >at > java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) >at > java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) >at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) >at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (RIVER-447) Leaked Executor Service Threads in LoadClass
[ https://issues.apache.org/jira/browse/RIVER-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Ellis updated RIVER-447: -- Description: I am seeing an overall thread usage increase when using Apache River 3.0. I'm able to reproduce the problem with both JDK 1.7 and 1.8. The issue is that LoadClass makes use of a loaderMap that contains an Executor Service. After 10 seconds, the loaderMap will garbage collect the Executor Service, but the Executor Service will not be shutdown. This leaves the Executor Service thread still running and waiting for work. How to Reproduce: 1. Start up an Apache River 3.0 instance 2. Have a client connect to the River instance 3. Wait 10 seconds 4. Have the client connect to the River instance a second time. The number of threads will have increased. The leaked threads have a stack trace similar to the one below. "net.jini.loader.pref.PreferredClassLoader@7af8260a["httpmd://10.0.1.5:9070/reggie-dl.jar;sha=6c5b83e0caec74d5d4226dcd2c2311d29e81ac0a httpmd://10.0.1.5:9070/jsk-dl.jar;sha=002bca7b77431ba20385d7ca5be8fa8ec1124a01"]_thread-0" #30149 prio=5 os_prio=0 tid=0x3fff68f79000 nid=0x5db9 waiting on condition [0x3ffdc344d000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0xf2955ff0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) was: I am seeing an overall thread usage increase when using Apache River 3.0. I'm able to reproduce the problem with both JDK 1.7 and 1.8. The issue is that LoadClass makes use of a loaderMap that contains an Executor Service. After 10 seconds, the loaderMap will garbage collect the Executor Service, but the Executor Service will not be shutdown. This leaves the Executor Service thread still running and waiting for work. How to Reproduce: 1. Start up an Apache River 3.0 instance 2. Have a client connect to the River instance 3. Wait 10 seconds 4. Have the client connect to the River instance a second time. The number of threads will have increased. The leaked threads have a stack trace similar to the one below. "net.jini.loader.pref.PreferredClassLoader@7af8260a["httpmd://10.0.1.5:9070/reggie-dl.jar;sha=6c5b83e0caec74d5d4226dcd2c2311d29e81ac0a httpmd://10.0.1.5:9070/jsk-dl.jar;sha=002bca7b77431ba20385d7ca5be8fa8ec1124a01"]_thread-0" #30149 prio=5 os_prio=0 tid=0x3fff68f79000 nid=0x5db9 waiting on condition [0x3ffdc344d000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0xf2955ff0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) > Leaked Executor Service Threads in LoadClass > > > Key: RIVER-447 > URL: https://issues.apache.org/jira/browse/RIVER-447 > Project: River > Issue Type: Bug > Components: net_jini_loader >Affects Versions: River_3.0.0 > Environment: Linux with either JDK 1.7 or 1.8 >Reporter: Shawn Ellis > Attachments: ExecutorShutdown.patch > > > I am seeing an overall thread usage increase when using Apache River 3.0. I'm > able to reproduce the problem with both JDK 1.7 and 1.8. The issue is that > LoadClass makes use of a loaderMap that contains an Executor Service. After > 10 seconds, the loaderMap will garbage collect the Executor
[jira] [Updated] (RIVER-447) Leaked Executor Service Threads in LoadClass
[ https://issues.apache.org/jira/browse/RIVER-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Ellis updated RIVER-447: -- Attachment: ExecutorShutdown.patch I've attached a patch that is a hack which calls ExecutorService.shutdown() when it is being removed. This prevents the threads from being leaked, but I realize that this probably not the best solution. Thanks for the help. > Leaked Executor Service Threads in LoadClass > > > Key: RIVER-447 > URL: https://issues.apache.org/jira/browse/RIVER-447 > Project: River > Issue Type: Bug > Components: net_jini_loader >Affects Versions: River_3.0.0 > Environment: Linux with either JDK 1.7 or 1.8 >Reporter: Shawn Ellis > Attachments: ExecutorShutdown.patch > > > I am seeing an overall thread usage increase when using Apache River 3.0. I'm > able to reproduce the problem with both JDK 1.7 and 1.8. The issue is that > LoadClass makes use of a loaderMap that contains an Executor Service. After > 10 seconds, the loaderMap will garbage collect the Executor Service, but the > Executor Service will not be shutdown. This leaves the Executor Service > thread still running and waiting for work. > How to Reproduce: > 1. Start up an Apache River 3.0 instance > 2. Have a client connect to the River instance > 3. Wait 10 seconds > 4. Have the client connect to the River instance a second time. The > number > of threads will have increased. > The leaked threads have a stack trace similar to the one below. > > "net.jini.loader.pref.PreferredClassLoader@7af8260a["httpmd://10.0.1.5:9070/reggie-dl.jar;sha=6c5b83e0caec74d5d4226dcd2c2311d29e81ac0a > > httpmd://10.0.1.5:9070/jsk-dl.jar;sha=002bca7b77431ba20385d7ca5be8fa8ec1124a01"]_thread-0" > #30149 prio=5 os_prio=0 tid=0x3fff68f79000 nid=0x5db9 waiting on > condition [0x3ffdc344d000] > java.lang.Thread.State: WAITING (parking) >at sun.misc.Unsafe.park(Native Method) >- parking to wait for <0xf2955ff0> (a > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) >at > java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) >at > java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) >at > java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) >at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) >at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (RIVER-447) Leaked Executor Service Threads in LoadClass
Shawn Ellis created RIVER-447: - Summary: Leaked Executor Service Threads in LoadClass Key: RIVER-447 URL: https://issues.apache.org/jira/browse/RIVER-447 Project: River Issue Type: Bug Components: net_jini_loader Affects Versions: River_3.0.0 Environment: Linux with either JDK 1.7 or 1.8 Reporter: Shawn Ellis I am seeing an overall thread usage increase when using Apache River 3.0. I'm able to reproduce the problem with both JDK 1.7 and 1.8. The issue is that LoadClass makes use of a loaderMap that contains an Executor Service. After 10 seconds, the loaderMap will garbage collect the Executor Service, but the Executor Service will not be shutdown. This leaves the Executor Service thread still running and waiting for work. How to Reproduce: 1. Start up an Apache River 3.0 instance 2. Have a client connect to the River instance 3. Wait 10 seconds 4. Have the client connect to the River instance a second time. The number of threads will have increased. The leaked threads have a stack trace similar to the one below. "net.jini.loader.pref.PreferredClassLoader@7af8260a["httpmd://10.0.1.5:9070/reggie-dl.jar;sha=6c5b83e0caec74d5d4226dcd2c2311d29e81ac0a httpmd://10.0.1.5:9070/jsk-dl.jar;sha=002bca7b77431ba20385d7ca5be8fa8ec1124a01"]_thread-0" #30149 prio=5 os_prio=0 tid=0x3fff68f79000 nid=0x5db9 waiting on condition [0x3ffdc344d000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0xf2955ff0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (RIVER-444) Extract classdep and other tools to a separate project and upgrade to JDK1.8
[ https://issues.apache.org/jira/browse/RIVER-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Ellis updated RIVER-444: -- Attachment: jdk1.8.patch asm-commons-5.0.3.jar asm-5.0.3.jar asm-tree-5.0.3.jar I've attached a patch along with the later versions of asm so that classdep works with jdk1.8. > Extract classdep and other tools to a separate project and upgrade to JDK1.8 > > > Key: RIVER-444 > URL: https://issues.apache.org/jira/browse/RIVER-444 > Project: River > Issue Type: Improvement > Components: build >Affects Versions: River_2.2.2 >Reporter: Greg Trasuk > Attachments: asm-5.0.3.jar, asm-commons-5.0.3.jar, > asm-tree-5.0.3.jar, jdk1.8.patch > > > Currently the build system in the 2.2 branch includes the classdep tool, > which is built in an early phase of the build. It uses ASM3.2, which fails > under JDK8. > I proposed on the mailing list to remove the tools package to a separate > project as follows: > How about if I pull out the ‘tools’ package to a separate Maven project and > integrate the changes that Peter did on qa_refactor? Then both the 2.2 > branch and qa_refactor can use the same tools. > Process would be as follows: > - Create a project in Apache git repo for ‘river-tools’ > - Create a Maven project (I’ll have a look at the modularization that Dennis > did, I suspect this is already done) in that repository > - Integrate Peter’s updates from qa-refactor (which update to use asm-5 in > classdep) > - Do a release on river-tools, so that tools.jar can go into Maven Central > - Remove tools packages from 2.2. branch. Modify build to get tools.jar from > Central rather than building it. > - I can update qa_refactor at the same time. > - Roll a release of the 2.2. branch. > Which will leave a 2.2. release that builds under JDK1.8, qa_refactor that > uses the same tool, and one less piece of build system confusion to put off > new committers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (RIVER-426) Support for SchemeSpecificPart with URIString normalization
[ https://issues.apache.org/jira/browse/RIVER-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Ellis updated RIVER-426: -- Attachment: URIString.patch > Support for SchemeSpecificPart with URIString normalization > --- > > Key: RIVER-426 > URL: https://issues.apache.org/jira/browse/RIVER-426 > Project: River > Issue Type: Improvement >Affects Versions: River_2.2.1 >Reporter: Shawn Ellis >Priority: Minor > Attachments: URIString.patch > > > I ran into a problem with URIString because the normalization was generating > a different result with an input of > jar:file:/home/user/files.war!/WEB-INF/classes. The attached patch file has a > fix and and also a test case. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (RIVER-426) Support for SchemeSpecificPart with URIString normalization
Shawn Ellis created RIVER-426: - Summary: Support for SchemeSpecificPart with URIString normalization Key: RIVER-426 URL: https://issues.apache.org/jira/browse/RIVER-426 Project: River Issue Type: Improvement Affects Versions: River_2.2.1 Reporter: Shawn Ellis Priority: Minor Attachments: URIString.patch I ran into a problem with URIString because the normalization was generating a different result with an input of jar:file:/home/user/files.war!/WEB-INF/classes. The attached patch file has a fix and and also a test case. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (RIVER-422) Missing reference-collections and high-scale-lib in Manifest for jsk-platform
[
https://issues.apache.org/jira/browse/RIVER-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Ellis updated RIVER-422:
--
Attachment: MANIFEST.patch
Patch with the additional jar files.
> Missing reference-collections and high-scale-lib in Manifest for jsk-platform
> -
>
> Key: RIVER-422
> URL: https://issues.apache.org/jira/browse/RIVER-422
> Project: River
> Issue Type: Bug
>Reporter: Shawn Ellis
>Priority: Minor
> Attachments: MANIFEST.patch
>
>
> I'm seeing the following exceptions when attempting to use the jsk-platform
> found in the trunk.
> Missing reference-collections-1.0.1.jar:
> Exception in thread "main" java.lang.NoClassDefFoundError:
> au/net/zeus/collection/Ref
> at
> com.sun.jini.start.AggregatePolicyProvider.(AggregatePolicyProvider.java:90)
> at
> com.sun.jini.start.NonActivatableServiceDescriptor.create(NonActivatableServiceDescriptor.java:619)
> at com.sun.jini.start.ServiceStarter.create(ServiceStarter.java:287)
> at
> com.sun.jini.start.ServiceStarter.processServiceDescriptors(ServiceStarter.java:445)
> at com.sun.jini.start.ServiceStarter.main(ServiceStarter.java:476)
> Caused by: java.lang.ClassNotFoundException: au.net.zeus.collection.Ref
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
> ... 5 more
> Missing high-scale-lib.jar:
> Jun 26 8:41:43 INFO:thr 24:exception occurred during unicast discovery to
> champignon:59292 with constraints InvocationConstraints[reqs: {}, prefs: {}]
> java.rmi.server.RMIClassLoaderSpi: Provider
> net.jini.loader.pref.PreferredClassProvider could not be instantiated:
> java.lang.NoClassDefFoundError: org/cliffc/high_scale_lib/NonBlockingHashMap
> at java.util.ServiceLoader.fail(ServiceLoader.java:224)
> at java.util.ServiceLoader.access$100(ServiceLoader.java:181)
> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:377)
> at java.util.ServiceLoader$1.next(ServiceLoader.java:445)
> at
> java.rmi.server.RMIClassLoader.initializeProvider(RMIClassLoader.java:708)
> at java.rmi.server.RMIClassLoader.access$000(RMIClassLoader.java:110)
> at java.rmi.server.RMIClassLoader$1.run(RMIClassLoader.java:120)
> at java.rmi.server.RMIClassLoader$1.run(RMIClassLoader.java:119)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.rmi.server.RMIClassLoader.(RMIClassLoader.java:117)
> at
> net.jini.loader.RiverClassLoader$DefaultRiverClassLoaderSpi.loadClass(RiverClassLoader.java:113)
> at net.jini.loader.RiverClassLoader.loadClass(RiverClassLoader.java:76)
> at net.jini.loader.ClassLoading.loadClass(ClassLoading.java:137)
> at
> net.jini.io.MarshalInputStream.resolveClass(MarshalInputStream.java:295)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1610)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1515)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1769)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1348)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
> at net.jini.io.MarshalledInstance.get(MarshalledInstance.java:358)
> at
> com.sun.jini.discovery.DiscoveryV1.doUnicastDiscovery(DiscoveryV1.java:394)
> at net.jini.discovery.LookupDiscovery$13.run(LookupDiscovery.java:3394)
> at
> com.sun.jini.start.AggregatePolicyProvider$AggregateSecurityContext$2.run(AggregatePolicyProvider.java:590)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> net.jini.discovery.LookupDiscovery.doUnicastDiscovery(LookupDiscovery.java:3391)
> at
> net.jini.discovery.LookupDiscovery.doUnicastDiscovery(LookupDiscovery.java:3422)
> at
> net.jini.discovery.LookupDiscovery.access$4000(LookupDiscovery.java:697)
> at
> net.jini.discovery.LookupDiscovery$UnicastDiscoveryTask.doRun(LookupDiscovery.java:1763)
> at
> net.jini.discovery.LookupDiscovery$UnicastDiscoveryTask.access$3700(LookupDiscovery.java:1714)
> at
> net.jini.discovery.LookupDiscovery$UnicastDiscoveryTask$1.run(LookupDiscovery.java:1731)
> at java.security.AccessController.doPrivileged(Native Method)
> at net.jini.security.Security$3.run(Security.java:501)
>
[jira] [Created] (RIVER-422) Missing reference-collections and high-scale-lib in Manifest for jsk-platform
Shawn Ellis created RIVER-422:
-
Summary: Missing reference-collections and high-scale-lib in
Manifest for jsk-platform
Key: RIVER-422
URL: https://issues.apache.org/jira/browse/RIVER-422
Project: River
Issue Type: Bug
Reporter: Shawn Ellis
Priority: Minor
I'm seeing the following exceptions when attempting to use the jsk-platform
found in the trunk.
Missing reference-collections-1.0.1.jar:
Exception in thread "main" java.lang.NoClassDefFoundError:
au/net/zeus/collection/Ref
at
com.sun.jini.start.AggregatePolicyProvider.(AggregatePolicyProvider.java:90)
at
com.sun.jini.start.NonActivatableServiceDescriptor.create(NonActivatableServiceDescriptor.java:619)
at com.sun.jini.start.ServiceStarter.create(ServiceStarter.java:287)
at
com.sun.jini.start.ServiceStarter.processServiceDescriptors(ServiceStarter.java:445)
at com.sun.jini.start.ServiceStarter.main(ServiceStarter.java:476)
Caused by: java.lang.ClassNotFoundException: au.net.zeus.collection.Ref
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
... 5 more
Missing high-scale-lib.jar:
Jun 26 8:41:43 INFO:thr 24:exception occurred during unicast discovery to
champignon:59292 with constraints InvocationConstraints[reqs: {}, prefs: {}]
java.rmi.server.RMIClassLoaderSpi: Provider
net.jini.loader.pref.PreferredClassProvider could not be instantiated:
java.lang.NoClassDefFoundError: org/cliffc/high_scale_lib/NonBlockingHashMap
at java.util.ServiceLoader.fail(ServiceLoader.java:224)
at java.util.ServiceLoader.access$100(ServiceLoader.java:181)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:377)
at java.util.ServiceLoader$1.next(ServiceLoader.java:445)
at
java.rmi.server.RMIClassLoader.initializeProvider(RMIClassLoader.java:708)
at java.rmi.server.RMIClassLoader.access$000(RMIClassLoader.java:110)
at java.rmi.server.RMIClassLoader$1.run(RMIClassLoader.java:120)
at java.rmi.server.RMIClassLoader$1.run(RMIClassLoader.java:119)
at java.security.AccessController.doPrivileged(Native Method)
at java.rmi.server.RMIClassLoader.(RMIClassLoader.java:117)
at
net.jini.loader.RiverClassLoader$DefaultRiverClassLoaderSpi.loadClass(RiverClassLoader.java:113)
at net.jini.loader.RiverClassLoader.loadClass(RiverClassLoader.java:76)
at net.jini.loader.ClassLoading.loadClass(ClassLoading.java:137)
at
net.jini.io.MarshalInputStream.resolveClass(MarshalInputStream.java:295)
at
java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1610)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1515)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1769)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1348)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
at net.jini.io.MarshalledInstance.get(MarshalledInstance.java:358)
at
com.sun.jini.discovery.DiscoveryV1.doUnicastDiscovery(DiscoveryV1.java:394)
at net.jini.discovery.LookupDiscovery$13.run(LookupDiscovery.java:3394)
at
com.sun.jini.start.AggregatePolicyProvider$AggregateSecurityContext$2.run(AggregatePolicyProvider.java:590)
at java.security.AccessController.doPrivileged(Native Method)
at
net.jini.discovery.LookupDiscovery.doUnicastDiscovery(LookupDiscovery.java:3391)
at
net.jini.discovery.LookupDiscovery.doUnicastDiscovery(LookupDiscovery.java:3422)
at
net.jini.discovery.LookupDiscovery.access$4000(LookupDiscovery.java:697)
at
net.jini.discovery.LookupDiscovery$UnicastDiscoveryTask.doRun(LookupDiscovery.java:1763)
at
net.jini.discovery.LookupDiscovery$UnicastDiscoveryTask.access$3700(LookupDiscovery.java:1714)
at
net.jini.discovery.LookupDiscovery$UnicastDiscoveryTask$1.run(LookupDiscovery.java:1731)
at java.security.AccessController.doPrivileged(Native Method)
at net.jini.security.Security$3.run(Security.java:501)
at java.security.AccessController.doPrivileged(Native Method)
at net.jini.security.Security.doPrivileged(Security.java:498)
at
net.jini.discovery.LookupDiscovery$UnicastDiscoveryTask.run(LookupDiscovery.java:1729)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrator
