[JBoss JIRA] (JGRP-1993) ENCRYPTAsymmetricTest fails on IBM jdk 1.8
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1993?page=com.atlassian.jira.plugin.... ]
Bela Ban closed JGRP-1993.
--------------------------
Resolution: Won't Fix
> ENCRYPTAsymmetricTest fails on IBM jdk 1.8
> ------------------------------------------
>
> Key: JGRP-1993
> URL: https://issues.jboss.org/browse/JGRP-1993
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.6
> Environment: IBM jdk 1.8
> Reporter: Richard Janík
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.8
>
>
> org.jgroups.protocols.ENCRYPTAsymmetricTest.testKeyChangesDuringKeyServerChange fails on IBM jdk 1.8 (JGroups 3.6.6.Final):
> {code}
> Error Message
> expected [javax.crypto.spec.SecretKeySpec@174de] but found [com.ibm.crypto.provider.AESSecretKey@e562eaa8]
> Stacktrace
> java.lang.AssertionError
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:496)
> at org.testng.Assert.assertEquals(Assert.java:125)
> at org.testng.Assert.assertEquals(Assert.java:167)
> at org.jgroups.protocols.ENCRYPTAsymmetricTest.testKeyChangesDuringKeyServerChange(ENCRYPTAsymmetricTest.java:404)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:816)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1124)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
> at org.testng.TestRunner.privateRun(TestRunner.java:774)
> at org.testng.TestRunner.run(TestRunner.java:624)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:359)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:354)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:312)
> at org.testng.SuiteRunner.run(SuiteRunner.java:261)
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1215)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
> at org.testng.TestNG.run(TestNG.java:1048)
> at org.testng.TestNG.privateMain(TestNG.java:1355)
> at org.testng.TestNG.main(TestNG.java:1324)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (JGRP-2017) Optimize COMPRESS protocol by pooling / re-using byte array/buffer
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2017?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2017:
--------------------------------
Yes, it is also on branch 3.6
> Optimize COMPRESS protocol by pooling / re-using byte array/buffer
> ------------------------------------------------------------------
>
> Key: JGRP-2017
> URL: https://issues.jboss.org/browse/JGRP-2017
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 3.4.5, 3.6.7
> Environment: Wildfly 8.2.1.Final (JGroups 3.4.5)
> Reporter: Mathieu Lachance
> Assignee: Bela Ban
> Fix For: 3.6.8, 4.0
>
>
> I'm currently working to minimize our application UDP bandwith usage by enabling the COMPRESS protocol in Wildfly 8.2.1.Final.
> Enabling the COMPRESS protocol works fine on that regards by reducing approximatly by 7x the amount of UDP traffic which is really neat.
> The thing is by enabling compression we are trading off increased cpu / memory usage for lowered network bandwith usage. In our case, we actually a notable increase of the cpu / memory usage due to increased usage of the garbage collector.
> When I had a look at the COMPRESS protocol implementation we see that both Deflator and Inflator are pooled and re-used (great) but not at the byte array level (not great).
> This compression pattern is very similar to GZip compression filter we can find in any recent Http spec implementors. In the Netty project for example, there's various compression protocol and/or utilities that are available and fine-tunable and they all have in common to re-use byte buffer and/or try to avoid byte arrays instantiation/copy at maximum.
> Here is some notable classes of the Netty implementation:
> https://github.com/netty/netty/blob/4.1/codec-http/src/main/java/io/netty...
> https://github.com/netty/netty/blob/4.1/codec/src/main/java/io/netty/hand...
> https://github.com/netty/netty/blob/4.1/codec/src/main/java/io/netty/hand...
> https://github.com/netty/netty/blob/4.1/codec/src/main/java/io/netty/hand...
> I think re-implementing something similar in JGroups would yield great benefits to the COMPRESS protocol. Maybe also, there's something that could be picked off right from the JBoss XNIO and/or the Undertow projects?
> Finally, I do not know also if we could add ergonomics at the same time to automatically determine the best number of Deflator and Inflator by keeping trace of the amount of time waited to pool one of them?
> Thanks,
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5836) Stale session data received when using REPL SYNC on jvmkill
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5836?page=com.atlassian.jira.plugin.... ]
Radoslav Husar closed WFLY-5836.
--------------------------------
Assignee: Radoslav Husar (was: Paul Ferraro)
Resolution: Rejected
This can happen in this scenario, when the server crashes after the client response is committed but before the transaction was committed. An indication of a problem would have been "off by 2" versions of the session implying a stale data read.
> Stale session data received when using REPL SYNC on jvmkill
> -----------------------------------------------------------
>
> Key: WFLY-5836
> URL: https://issues.jboss.org/browse/WFLY-5836
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR4
> Reporter: Michal Vinkler
> Assignee: Radoslav Husar
> Priority: Minor
>
> Client received older data when using REPL SYNC right after failing perf21 (jvmkill).
> -- seen only once, hardly reproducible
> Timeline & stacktrace:
> {code}
> 2015/11/27 15:05:40:255 EST [INFO ][TestController] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Failing node 3 (perf21)
> 2015/11/27 15:05:40:459 EST [INFO ][TestController] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Node 3 (perf21) is down.
> 2015/11/27 15:05:40:459 EST [INFO ][TestController] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Cluster state: [UP, UP, UP, DOWN].
> 2015/11/27 15:05:45:758 EST [INFO ][Runner - 725] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Failover detected, JvmRoute changed. perf21 -> perf20
> 2015/11/27 15:05:45:774 EST [INFO ][Runner - 1962] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Failover detected, JvmRoute changed. perf21 -> perf19
> :
> :
> 2015/11/27 15:05:49:999 EST [INFO ][Runner - 522] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Failover detected, JvmRoute changed. perf21 -> perf20
> 2015/11/27 15:05:50:533 EST [INFO ][Runner - 314] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Failover detected, JvmRoute changed. perf21 -> perf20
> 2015/11/27 15:05:53:908 EST [WARN ][Runner - 14] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 139, received 138, Runner: 14>
> org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 139, received 138, Runner: 14
> at org.jboss.smartfrog.loaddriver.http.AbstractSerialNumberValidatorFactoryImpl$SerialNumberValidator.processRequest(AbstractSerialNumberValidatorFactoryImpl.java:133)
> at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52)
> at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Link
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-http-...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (JGRP-2017) Optimize COMPRESS protocol by pooling / re-using byte array/buffer
by Mathieu Lachance (JIRA)
[ https://issues.jboss.org/browse/JGRP-2017?page=com.atlassian.jira.plugin.... ]
Mathieu Lachance edited comment on JGRP-2017 at 2/23/16 7:36 AM:
-----------------------------------------------------------------
Thanks [~belaban] for the very quick follow up.
-Is there a place I could see the change? any pull request? I just might cherry pick it and test it already.-
got it, https://github.com/belaban/JGroups/commit/ab5b3b1e9c21b92501efdb36a4db935...
thanks!
was (Author: matlach):
Thanks [~belaban] for the very quick follow up.
Is there a place I could see the change? any pull request? I just might cherry pick it and test it already.
> Optimize COMPRESS protocol by pooling / re-using byte array/buffer
> ------------------------------------------------------------------
>
> Key: JGRP-2017
> URL: https://issues.jboss.org/browse/JGRP-2017
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 3.4.5, 3.6.7
> Environment: Wildfly 8.2.1.Final (JGroups 3.4.5)
> Reporter: Mathieu Lachance
> Assignee: Bela Ban
> Fix For: 3.6.8, 4.0
>
>
> I'm currently working to minimize our application UDP bandwith usage by enabling the COMPRESS protocol in Wildfly 8.2.1.Final.
> Enabling the COMPRESS protocol works fine on that regards by reducing approximatly by 7x the amount of UDP traffic which is really neat.
> The thing is by enabling compression we are trading off increased cpu / memory usage for lowered network bandwith usage. In our case, we actually a notable increase of the cpu / memory usage due to increased usage of the garbage collector.
> When I had a look at the COMPRESS protocol implementation we see that both Deflator and Inflator are pooled and re-used (great) but not at the byte array level (not great).
> This compression pattern is very similar to GZip compression filter we can find in any recent Http spec implementors. In the Netty project for example, there's various compression protocol and/or utilities that are available and fine-tunable and they all have in common to re-use byte buffer and/or try to avoid byte arrays instantiation/copy at maximum.
> Here is some notable classes of the Netty implementation:
> https://github.com/netty/netty/blob/4.1/codec-http/src/main/java/io/netty...
> https://github.com/netty/netty/blob/4.1/codec/src/main/java/io/netty/hand...
> https://github.com/netty/netty/blob/4.1/codec/src/main/java/io/netty/hand...
> https://github.com/netty/netty/blob/4.1/codec/src/main/java/io/netty/hand...
> I think re-implementing something similar in JGroups would yield great benefits to the COMPRESS protocol. Maybe also, there's something that could be picked off right from the JBoss XNIO and/or the Undertow projects?
> Finally, I do not know also if we could add ergonomics at the same time to automatically determine the best number of Deflator and Inflator by keeping trace of the amount of time waited to pool one of them?
> Thanks,
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-4416) Cannot obtain DOMImplementationRegistry instance
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4416?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-4416:
-----------------------------------
By default we add jdk module to all deployments, but in static modules it needs to be done manually.
> Cannot obtain DOMImplementationRegistry instance
> ------------------------------------------------
>
> Key: WFLY-4416
> URL: https://issues.jboss.org/browse/WFLY-4416
> Project: WildFly
> Issue Type: Bug
> Components: XML Frameworks
> Affects Versions: 8.2.0.Final
> Reporter: Thomas Diesler
> Assignee: Jason Greene
>
> {code}
> testDOMImplementationRegistry(org.jboss.as.test.smoke.xml.DOMImplementationRegistryTestCase) Time elapsed: 0.09 sec <<< ERROR!
> java.lang.ClassNotFoundException: com.sun.org.apache.xerces.internal.dom.DOMXSImplementationSourceImpl from [Module "deployment.dom-registry-test:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134)
> at org.w3c.dom.bootstrap.DOMImplementationRegistry.newInstance(DOMImplementationRegistry.java:182)
> at org.jboss.as.test.smoke.xml.DOMImplementationRegistryTestCase.testDOMImplementationRegistry(DOMImplementationRegistryTestCase.java:52)
> {code}
> CrossRef: https://github.com/wildfly-extras/wildfly-camel/issues/391
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (JGRP-2017) Optimize COMPRESS protocol by pooling / re-using byte array/buffer
by Mathieu Lachance (JIRA)
[ https://issues.jboss.org/browse/JGRP-2017?page=com.atlassian.jira.plugin.... ]
Mathieu Lachance commented on JGRP-2017:
----------------------------------------
Thanks [~belaban] for the very quick follow up.
Is there a place I could see the change? any pull request? I just might cherry pick it and test it already.
> Optimize COMPRESS protocol by pooling / re-using byte array/buffer
> ------------------------------------------------------------------
>
> Key: JGRP-2017
> URL: https://issues.jboss.org/browse/JGRP-2017
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 3.4.5, 3.6.7
> Environment: Wildfly 8.2.1.Final (JGroups 3.4.5)
> Reporter: Mathieu Lachance
> Assignee: Bela Ban
> Fix For: 3.6.8, 4.0
>
>
> I'm currently working to minimize our application UDP bandwith usage by enabling the COMPRESS protocol in Wildfly 8.2.1.Final.
> Enabling the COMPRESS protocol works fine on that regards by reducing approximatly by 7x the amount of UDP traffic which is really neat.
> The thing is by enabling compression we are trading off increased cpu / memory usage for lowered network bandwith usage. In our case, we actually a notable increase of the cpu / memory usage due to increased usage of the garbage collector.
> When I had a look at the COMPRESS protocol implementation we see that both Deflator and Inflator are pooled and re-used (great) but not at the byte array level (not great).
> This compression pattern is very similar to GZip compression filter we can find in any recent Http spec implementors. In the Netty project for example, there's various compression protocol and/or utilities that are available and fine-tunable and they all have in common to re-use byte buffer and/or try to avoid byte arrays instantiation/copy at maximum.
> Here is some notable classes of the Netty implementation:
> https://github.com/netty/netty/blob/4.1/codec-http/src/main/java/io/netty...
> https://github.com/netty/netty/blob/4.1/codec/src/main/java/io/netty/hand...
> https://github.com/netty/netty/blob/4.1/codec/src/main/java/io/netty/hand...
> https://github.com/netty/netty/blob/4.1/codec/src/main/java/io/netty/hand...
> I think re-implementing something similar in JGroups would yield great benefits to the COMPRESS protocol. Maybe also, there's something that could be picked off right from the JBoss XNIO and/or the Undertow projects?
> Finally, I do not know also if we could add ergonomics at the same time to automatically determine the best number of Deflator and Inflator by keeping trace of the amount of time waited to pool one of them?
> Thanks,
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5688) mod_cluster subsystem remains silent if connector set to http
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5688?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-5688:
--------------------------------------
Yes, correct, unfortunately discussed in the EAP7 tracker Jira: https://issues.jboss.org/browse/JBEAP-223?focusedCommentId=13129303&page=...
> mod_cluster subsystem remains silent if connector set to http
> -------------------------------------------------------------
>
> Key: WFLY-5688
> URL: https://issues.jboss.org/browse/WFLY-5688
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.0.0.CR4
> Reporter: Michal Karm Babacek
> Assignee: Radoslav Husar
> Labels: ux
>
> If one sets mod_cluster subsystem {{connector="http"}} there is nothing in the log about any mod_cluster subsystem being initialized, no warning, nothing. It appears to be dead silent even with log level DEBUG.
> When switched back to {{connector="ajp"}}, there are the well known comforting messages:
> {noformat}
> INFO [org.jboss.modcluster] (ServerService Thread Pool -- 62) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> INFO [org.jboss.modcluster] (ServerService Thread Pool -- 62) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> {noformat}
> Weird. Any obvious misconfiguration or explanation? The config is the default standalone-ha.xml otherwise.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months