[JBoss JIRA] (JGRP-2232) Using NATIVE_S3_PING old members doesn't seem to get removed
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2232?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2232:
---------------------------
Fix Version/s: 4.0.10
(was: 4.0.9)
> Using NATIVE_S3_PING old members doesn't seem to get removed
> ------------------------------------------------------------
>
> Key: JGRP-2232
> URL: https://issues.jboss.org/browse/JGRP-2232
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.7
> Environment: Spring Boot / Boxfuse / AWS
> Reporter: Jesper Blomquist
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0.10
>
>
> According to: http://www.jgroups.org/manual4/index.html#FILE_PING old members should be removed if there is a reaper task is running (which seem to be the default), but this does not happen for us.
> Both the s3 file, and the "logical address cache" keeps growing. We have a cluster of about 10 members (they comes and goes due to auto scaling). Nothing is ever marked as "removable" and nothing is ever older than 60 sec (same as the reaper interval?!).
> Below is a (truncated) dump from JMX of the logical address cache (everything always has the same age):
> 967 elements:
> i-0704cf3786731075b-10202: 25c4cd46-6e4d-d198-88f5-bfa65b4bfb4e: 10.0.82.106:7800 (20 secs old)
> i-08fb0ad436efed1b2-18812: f4fef542-42ab-2c7b-a1f1-10ad90112e27: 10.0.118.75:7800 (20 secs old)
> i-0b9f077af97ef256f-11379: 47aea44c-9f2d-4200-d606-2f4c2844efc8: 10.0.85.52:7800 (20 secs old)
> i-06e220104b9e0069a-55132: b86864f0-8961-4565-c935-dc03137a16da: 10.0.67.5:7800 (20 secs old)
> i-0d3bbedeca8c7eb7d-33369: 9b37f425-7da5-d3ee-cfd5-5d1b4d2266b9: 10.0.116.207:7800 (20 secs old)
> i-074806dc606197fc9-46262: 99a2f550-5628-5d2c-1167-38268f804139: 10.0.109.149:7800 (20 secs old)
> i-0bbd38020b6184cb1-22367: e46e3ed5-0c75-1230-94aa-deb1cd1a9bf1: 10.0.124.183:7800 (20 secs old)
> i-0ff325c578faf6ad9-2376: c4c48178-cdbf-530a-155f-bba1f01a65e2: 10.0.100.143:7800 (20 secs old)
> i-03d819b23eb1357ba-64126: b89f5117-8ebf-df14-ece1-adba632c0245: 10.0.67.163:7800 (20 secs old)
> i-09e9907ee27aef2a0-37490: 8ee85310-39c7-0617-0fc8-3d4f002a1894: 10.0.108.234:7800 (20 secs old)
> i-0da90751a5093a880-28069: ecd33ad7-f261-5b71-8deb-b9fe5b4ed05d: 10.0.77.132:7800 (20 secs old)
> i-03213f181d96c70d3-57318: d962cfd0-8c5e-4129-334f-ffa10309ec30: 10.0.112.182:7800 (20 secs old)
> ...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (JGRP-2234) Unlocked locks stay locked forever
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2234?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2234:
---------------------------
Fix Version/s: 4.0.10
(was: 4.0.9)
> Unlocked locks stay locked forever
> ----------------------------------
>
> Key: JGRP-2234
> URL: https://issues.jboss.org/browse/JGRP-2234
> Project: JGroups
> Issue Type: Bug
> Reporter: Bram Klein Gunnewiek
> Assignee: Bela Ban
> Fix For: 4.0.10
>
> Attachments: ClusterSplitLockTest.java, jg_clusterlock_output_testfail.txt
>
>
> As discussed in the mailing list we have issues where locks from the central lock protocol stay locked forever when the coordinator of the cluster disconnects. We can reproduce this with the attached ClusterSplitLockTest.java. Its a race condition and we need to run the test a lot of times (sometimes > 20) before we encounter a failure.
> What we think is happening:
> In a three node cluster (node A, B and C where node A is the coordinator) unlock requests from B and/or C can be missed when node A leaves and B and/or C don't have the new view installed yet. When, for example, node B takes over coordination it creates the lock table based on the back-ups. Lets say node C has locked the lock with name 'lockX'. Node C performs an unlock of 'lockX' just after node A (gracefully) leaves and sends the unlock request to node A since node C doesn't have the correct view installed yet. Node B has and recreated the lock table where 'lockX' is locked by Node C. Node C doesn't resend the unlock request so 'lockX' gets locked forever.
> Attached is the testng test we wrote and the output of a test failure.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (JGRP-2235) ConcurrentModificationException when resend pending lock requests
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2235?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2235:
---------------------------
Fix Version/s: 4.0.10
(was: 4.0.9)
> ConcurrentModificationException when resend pending lock requests
> -----------------------------------------------------------------
>
> Key: JGRP-2235
> URL: https://issues.jboss.org/browse/JGRP-2235
> Project: JGroups
> Issue Type: Bug
> Reporter: Bram Klein Gunnewiek
> Assignee: Bela Ban
> Fix For: 4.0.10
>
>
> While testing JGRP-2234 we saw a ConcurrentModificationException in the locking protocol in some (rare) situations:
> {noformat}
> 09:46:42.856 [jgroups-7,TEST,B] ERROR org.jgroups.protocols.pbcast.GMS - JGRP000027: failed passing message up
> java.util.ConcurrentModificationException: null
> at java.util.HashMap$ValueSpliterator.forEachRemaining(HashMap.java:1630) ~[?:1.8.0_151]
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) ~[?:1.8.0_151]
> at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) ~[?:1.8.0_151]
> at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) ~[?:1.8.0_151]
> at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) ~[?:1.8.0_151]
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:1.8.0_151]
> at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) ~[?:1.8.0_151]
> at org.jgroups.protocols.Locking$ClientLockTable.lambda$resendPendingLockRequests$3(Locking.java:1085) ~[classes/:?]
> at java.util.concurrent.ConcurrentHashMap$ValuesView.forEach(ConcurrentHashMap.java:4707) ~[?:1.8.0_151]
> at org.jgroups.protocols.Locking$ClientLockTable.resendPendingLockRequests(Locking.java:1084) ~[classes/:?]
> at org.jgroups.protocols.CENTRAL_LOCK.handleView(CENTRAL_LOCK.java:147) ~[classes/:?]
> at org.jgroups.protocols.Locking.up(Locking.java:218) ~[classes/:?]
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:163) ~[classes/:?]
> at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:702) ~[classes/:?]
> at org.jgroups.protocols.pbcast.ParticipantGmsImpl.handleViewChange(ParticipantGmsImpl.java:135) ~[classes/:?]
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:918) ~[classes/:?]
> at org.jgroups.stack.Protocol.up(Protocol.java:364) [classes/:?]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:293) [classes/:?]
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:428) [classes/:?]
> at org.jgroups.protocols.pbcast.NAKACK2.deliverBatch(NAKACK2.java:962) [classes/:?]
> at org.jgroups.protocols.pbcast.NAKACK2.removeAndDeliver(NAKACK2.java:896) [classes/:?]
> at org.jgroups.protocols.pbcast.NAKACK2.handleMessages(NAKACK2.java:870) [classes/:?]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:690) [classes/:?]
> at org.jgroups.stack.Protocol.up(Protocol.java:372) [classes/:?]
> at org.jgroups.protocols.TP.passBatchUp(TP.java:1255) [classes/:?]
> at org.jgroups.util.MaxOneThreadPerSender$BatchHandlerLoop.passBatchUp(MaxOneThreadPerSender.java:284) [classes/:?]
> at org.jgroups.util.SubmitToThreadPool$BatchHandler.run(SubmitToThreadPool.java:136) [classes/:?]
> at org.jgroups.util.MaxOneThreadPerSender$BatchHandlerLoop.run(MaxOneThreadPerSender.java:273) [classes/:?]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_151]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_151]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_151]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (LOGMGR-184) Wrong values for unknown method/class
by David Lloyd (JIRA)
David Lloyd created LOGMGR-184:
----------------------------------
Summary: Wrong values for unknown method/class
Key: LOGMGR-184
URL: https://issues.jboss.org/browse/LOGMGR-184
Project: JBoss Log Manager
Issue Type: Bug
Components: core
Reporter: David Lloyd
Assignee: David Lloyd
Unknown method/class in ExtLogRecord use a value of "<unknown>", but the LogRecord spec says that {{null}} should be used.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (ELY-1300) Pem.parsePemX509Certificate() cannot parse files with non-PEM content
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1300?page=com.atlassian.jira.plugin.s... ]
Jan Kalina reassigned ELY-1300:
-------------------------------
Assignee: Jan Kalina
> Pem.parsePemX509Certificate() cannot parse files with non-PEM content
> ---------------------------------------------------------------------
>
> Key: ELY-1300
> URL: https://issues.jboss.org/browse/ELY-1300
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Peter Palaga
> Assignee: Jan Kalina
>
> Add a test like this to `PemTest`:
> {code}
> @Test
> public void testParsePemX509Certificate01() throws Exception {
> URL url = PemTest.class.getResource("/ca/certs/01.pem");
> byte[] bytes = Files.readAllBytes(Paths.get(url.toURI()));
> assertNotNull(Pem.parsePemX509Certificate(CodePointIterator.ofUtf8Bytes(bytes)));
> }
> {code}
> Note that {{ca/certs/01.pem}} should start with non-PEM content
> {code}
> Certificate:
> Data:
> ...
> {code}
> followed by the PEM content:
> {code}
> -----BEGIN CERTIFICATE-----
> {code}
> Run the test
> {code}
> mvn clean test -Dtest=PemTest#testParsePemX509Certificate01
> {code}
> Expected: Not quite sure if the parser should accept this. In any case, the following code works on Oracle/OpenJDK (while it does not on IBM JDK):
> {code}
> CertificateFactory certificateFactory = CertificateFactory.getInstance("X.509");
> InputStream is = X509EvidenceVerificationSuiteChild.class.getResourceAsStream("/ca/certs/01.pem");
> Assert.assertNotNull((X509Certificate) certificateFactory.generateCertificate(is));
> {code}
> Actual:
> {code}
> testParsePemX509Certificate01(org.wildfly.security.util.PemTest) Time elapsed: 0.116 sec <<< ERROR!
> java.lang.IllegalArgumentException: ELY03010: Malformed PEM content at offset 1
> at org.wildfly.security.pem.Pem.parsePemContent(Pem.java:79)
> at org.wildfly.security.pem.Pem.parsePemX509Certificate(Pem.java:272)
> at org.wildfly.security.util.PemTest.testParsePemX509Certificate01(PemTest.java:57)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (ELY-1298) GssapiCompatibilitySuiteChild fails on IBM JDK
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1298?page=com.atlassian.jira.plugin.s... ]
Jan Kalina commented on ELY-1298:
---------------------------------
Unassigning, as Peter has mentioned he is not working on project already.
> GssapiCompatibilitySuiteChild fails on IBM JDK
> ----------------------------------------------
>
> Key: ELY-1298
> URL: https://issues.jboss.org/browse/ELY-1298
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Testsuite
> Reporter: Peter Palaga
> Labels: ibm-java
>
> A followup of ELY-1293
> {{System.currentTimeMillis()}} is native in IBM JDK and at the same time, IBM JDK does not support java.lang.instrument API for native methods. Therefore, {{System.currentTimeMillis()}} cannot be mocked on IBM JDK using jmockit.
> {code}
> export JAVA_HOME=path/to/ibm/java8
> $JAVA_HOME/bin/java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT - tr.r14.java.green_20160818_122998
> GC - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
> mvn clean test
> {code}
> Expected: the tests mocking {{System.currentTimeMillis()}} should pass
> Actual: the tests mocking {{System.currentTimeMillis()}} throw the following exception or similar:
> {code}
> java.lang.UnsupportedOperationException: class redefinition failed: attempted to change method modifiers
> at org.wildfly.security.audit.PeriodicRotatingFileAuditEndpointTest$1.<init>(PeriodicRotatingFileAuditEndpointTest.java:212)
> at org.wildfly.security.audit.PeriodicRotatingFileAuditEndpointTest.mockTime(PeriodicRotatingFileAuditEndpointTest.java:212)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.lang.reflect.Method.invoke(Method.java:508)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> {code}
> This is currently the case with
> * GssapiCompatibilitySuiteChild
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (ELY-1298) GssapiCompatibilitySuiteChild fails on IBM JDK
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1298?page=com.atlassian.jira.plugin.s... ]
Jan Kalina reassigned ELY-1298:
-------------------------------
Assignee: (was: Peter Palaga)
> GssapiCompatibilitySuiteChild fails on IBM JDK
> ----------------------------------------------
>
> Key: ELY-1298
> URL: https://issues.jboss.org/browse/ELY-1298
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Testsuite
> Reporter: Peter Palaga
> Labels: ibm-java
>
> A followup of ELY-1293
> {{System.currentTimeMillis()}} is native in IBM JDK and at the same time, IBM JDK does not support java.lang.instrument API for native methods. Therefore, {{System.currentTimeMillis()}} cannot be mocked on IBM JDK using jmockit.
> {code}
> export JAVA_HOME=path/to/ibm/java8
> $JAVA_HOME/bin/java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT - tr.r14.java.green_20160818_122998
> GC - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
> mvn clean test
> {code}
> Expected: the tests mocking {{System.currentTimeMillis()}} should pass
> Actual: the tests mocking {{System.currentTimeMillis()}} throw the following exception or similar:
> {code}
> java.lang.UnsupportedOperationException: class redefinition failed: attempted to change method modifiers
> at org.wildfly.security.audit.PeriodicRotatingFileAuditEndpointTest$1.<init>(PeriodicRotatingFileAuditEndpointTest.java:212)
> at org.wildfly.security.audit.PeriodicRotatingFileAuditEndpointTest.mockTime(PeriodicRotatingFileAuditEndpointTest.java:212)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.lang.reflect.Method.invoke(Method.java:508)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> {code}
> This is currently the case with
> * GssapiCompatibilitySuiteChild
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (ELY-1298) GssapiCompatibilitySuiteChild fails on IBM JDK
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1298?page=com.atlassian.jira.plugin.s... ]
Jan Kalina updated ELY-1298:
----------------------------
Labels: ibm-java (was: )
> GssapiCompatibilitySuiteChild fails on IBM JDK
> ----------------------------------------------
>
> Key: ELY-1298
> URL: https://issues.jboss.org/browse/ELY-1298
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Peter Palaga
> Assignee: Peter Palaga
> Labels: ibm-java
>
> A followup of ELY-1293
> {{System.currentTimeMillis()}} is native in IBM JDK and at the same time, IBM JDK does not support java.lang.instrument API for native methods. Therefore, {{System.currentTimeMillis()}} cannot be mocked on IBM JDK using jmockit.
> {code}
> export JAVA_HOME=path/to/ibm/java8
> $JAVA_HOME/bin/java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT - tr.r14.java.green_20160818_122998
> GC - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
> mvn clean test
> {code}
> Expected: the tests mocking {{System.currentTimeMillis()}} should pass
> Actual: the tests mocking {{System.currentTimeMillis()}} throw the following exception or similar:
> {code}
> java.lang.UnsupportedOperationException: class redefinition failed: attempted to change method modifiers
> at org.wildfly.security.audit.PeriodicRotatingFileAuditEndpointTest$1.<init>(PeriodicRotatingFileAuditEndpointTest.java:212)
> at org.wildfly.security.audit.PeriodicRotatingFileAuditEndpointTest.mockTime(PeriodicRotatingFileAuditEndpointTest.java:212)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.lang.reflect.Method.invoke(Method.java:508)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> {code}
> This is currently the case with
> * GssapiCompatibilitySuiteChild
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month