December 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1981) Request.execute() acquires unneeded lock

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1981?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1981: -------------------------------- No, the lock is needed as we change state (`done`) after the condvar unblocks. Closing this issue... > Request.execute() acquires unneeded lock > ---------------------------------------- > > Key: JGRP-1981 > URL: https://issues.jboss.org/browse/JGRP-1981 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.7 > > > {{Request.execute()}} at one point calls {{responsesComplete()}} which calls {{ConditionVar.waitFor()}}, and both methods acquire the lock. The first lock acquition is not required. > The effect is minimal as acquiring an already acquired lock is cheap. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1981) Request.execute() acquires unneeded lock

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1981?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1981. ---------------------------- Resolution: Rejected Removing the lock would not be correct > Request.execute() acquires unneeded lock > ---------------------------------------- > > Key: JGRP-1981 > URL: https://issues.jboss.org/browse/JGRP-1981 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.7 > > > {{Request.execute()}} at one point calls {{responsesComplete()}} which calls {{ConditionVar.waitFor()}}, and both methods acquire the lock. The first lock acquition is not required. > The effect is minimal as acquiring an already acquired lock is cheap. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[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 updated JGRP-1993: --------------------------- Fix Version/s: 3.6.8 (was: 3.6.7) Priority: Minor (was: Major) > 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, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5857) HASingleton Stop is called in Node1 (Master) during down of Node2 in cluster, but start is not called in Node1 again after Node1 is selected Master again

by Serg Jakean19019 (JIRA)

[ https://issues.jboss.org/browse/WFLY-5857?page=com.atlassian.jira.plugin.... ] Serg Jakean19019 commented on WFLY-5857: ---------------------------------------- Thanks To my sorrow i can not test it in WL10 now, because of shortage of time. The solution from Link works in Wildfly 9.0.1.Final: quorum 1. The difference is only that Function "PrefferedNode" doesn't work and Stop/new Start of Singletone in Node1 (or Node2) is not called during down of other Node2(or Node1) - Singleton doesn't Start everything again in case of down of another Node. If Singleton was in Node that is down than it will be started in other Node. Is there any Description of methods at all? Despite of Examples in GitHub -some background was-is absent. Will be old solutions supported in new versions of WF? > HASingleton Stop is called in Node1 (Master) during down of Node2 in cluster, but start is not called in Node1 again after Node1 is selected Master again > --------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-5857 > URL: https://issues.jboss.org/browse/WFLY-5857 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.1.Final > Environment: Wildfly-9.0.1.Final. Full HA Configuration. Cluster Full Ha > Reporter: Serg Jakean19019 > Assignee: Paul Ferraro > > HASingleton Stop is called in Node1 (Master) during down of Node2 in cluster, but Start is not called in Node1 again after Node1 is selected Master again. > If Node2 ist started again, than Start is called in Node1 again. > This Solution worked in 8.2.0.Final and was taken from GitHub > Part of Log after Stop in Singletone: > 2015-12-16 10:25:39,832 WARN [org.wildfly.clustering.server] (remote-thread--p8-t5) WFLYCLSV0007: Just reached required quorum of 1 for jboss.quickstart.ha.singleton.default service. If this cluster loses another member, no node will be chosen to provide this service. > 2015-12-16 10:25:39,832 INFO [org.wildfly.clustering.server] (remote-thread--p8-t5) WFLYCLSV0003: DevNode1 elected as the singleton provider of the jboss.quickstart.ha.singleton.default service > 2015-12-16 10:25:40,410 WARN [org.hornetq.core.client] (Thread-514 (HornetQ-client-global-threads-816000930)) HQ212037: Connection failure has been detected: HQ119015: The connection was disconnected because of server shutdown [code=DISCONNECTED] > 2015-12-16 10:25:40,424 WARN [org.hornetq.core.client] (Thread-515 (HornetQ-client-global-threads-816000930)) HQ212037: Connection failure has been detected: HQ119015: The connection was disconnected because of server shutdown [code=DISCONNECTED] > 2015-12-16 10:25:40,442 INFO [org.hornetq.core.server] (Thread-16 (HornetQ-server-HornetQServerImpl::serverUUID=5f62a17c-a33d-11e5-b968-cda4b2119720-1601129088)) HQ221029: stopped bridge sf.my-cluster.b27b8fc6-a33e-11e5-84b8-b7bbc6dfe24c > 2015-12-16 10:25:40,495 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-5,ee,DevNode1) ISPN000094: Received new cluster view for channel server: [Node1|2] (1) [DevNode1] > 2015-12-16 10:25:40,496 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-5,ee,DevNode1) ISPN000094: Received new cluster view for channel ejb: [Node1|2] (1) [DevNode1] > 2015-12-16 10:25:40,497 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-5,ee,DevNode1) ISPN000094: Received new cluster view for channel hibernate: [DevNode1|2] (1) [DevNode1] > 2015-12-16 10:25:57,010 WARNING [org.jgroups.protocols.UDP] (INT-1,hq-cluster,DevNode1) JGRP000012: discarded message from different cluster ee (our cluster is hq-cluster). Sender was DevNode1 (received 38 identical messages from DevNode1 in the last 63946 ms) > 2015-12-16 10:26:30,810 WARNING [org.jgroups.protocols.UDP] (Incoming-13,ee,DevNode1) JGRP000012: discarded message from different cluster hq-cluster (our cluster is ee). Sender was DevNode1 (received 80 identical messages from DevNode1 in the last 60008 ms) > This issue also in: > https://developer.jboss.org/thread/266831 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-459) javassist should also be exported to Hibernate (native) applications

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-459?page=com.atlassian.jira.plugin.s... ] Stuart Douglas commented on WFLY-459: ------------------------------------- Why is javassist needed by these deployments? I assume it is for proxy handlers? Ideally we would not export javassist as it can conflict with a user supplied version. Also if an application is bundling hibernate they must also bundle javassist, as our copy may not be compatible with their required version. > javassist should also be exported to Hibernate (native) applications > -------------------------------------------------------------------- > > Key: WFLY-459 > URL: https://issues.jboss.org/browse/WFLY-459 > Project: WildFly > Issue Type: Task > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 10.0.0.CR5 > > > Originally this jira was to stop exporting the javassist module to JPA deployments but it turns out that is fine to do. In addition, native Hibernate applications that depend on Hibernate, should also get the javassist dependency. > # native Hibernate applications will get the javassist dependency via the application dependency on org.hibernate. > # container managed JPA applications will get the javassist dependency via org.jboss.as.jpa.processor.JPADependencyProcessor (JPA deployer). > # container managed JPA applications that embed their own copy of Hibernate jars will also get the javassist dependency via org.jboss.as.jpa.processor.JPADependencyProcessor (JPA deployer). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-459) javassist should also be exported to Hibernate (native) applications

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-459?page=com.atlassian.jira.plugin.s... ] Jason Greene commented on WFLY-459: ----------------------------------- :( If we do this we would be adding yet another breakage from the ideal of modular class loading. The only thing a modular class loader should see is APIs. It should never see implementation dependencies. Most of the time this happens, its because the framework is using the wrong class loader (e.g TCCL to load its own classes vs the defining class loader). We have some historic baggage here but we should not be adding new cases of it > javassist should also be exported to Hibernate (native) applications > -------------------------------------------------------------------- > > Key: WFLY-459 > URL: https://issues.jboss.org/browse/WFLY-459 > Project: WildFly > Issue Type: Task > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 10.0.0.CR5 > > > Originally this jira was to stop exporting the javassist module to JPA deployments but it turns out that is fine to do. In addition, native Hibernate applications that depend on Hibernate, should also get the javassist dependency. > # native Hibernate applications will get the javassist dependency via the application dependency on org.hibernate. > # container managed JPA applications will get the javassist dependency via org.jboss.as.jpa.processor.JPADependencyProcessor (JPA deployer). > # container managed JPA applications that embed their own copy of Hibernate jars will also get the javassist dependency via org.jboss.as.jpa.processor.JPADependencyProcessor (JPA deployer). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5865) Undertow file resources may not work if root path is non canonical

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-5865: ------------------------------------ Summary: Undertow file resources may not work if root path is non canonical Key: WFLY-5865 URL: https://issues.jboss.org/browse/WFLY-5865 Project: WildFly Issue Type: Bug Components: Web (Undertow) Reporter: Stuart Douglas Assignee: Stuart Douglas -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5864) Undertow file resources may not work if root path is non canonical

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-5864: ------------------------------------ Summary: Undertow file resources may not work if root path is non canonical Key: WFLY-5864 URL: https://issues.jboss.org/browse/WFLY-5864 Project: WildFly Issue Type: Bug Components: Web (Undertow) Reporter: Stuart Douglas Assignee: Stuart Douglas -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5688) mod_cluster subsystem remains silent if connector set to http

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-5688?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-5688: -------------------------------------- Isn't it connector="default" rather than connector="http" (i.e. this is a reference to the connector name in the Undertow subsystem)? > 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 > 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, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-761) Not possible to overlay non existing file in WAR

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-761?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated WFCORE-761: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1147352, https://bugzilla.redhat.com/show_bug.cgi?id=1287732 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1147352) > Not possible to overlay non existing file in WAR > ------------------------------------------------ > > Key: WFCORE-761 > URL: https://issues.jboss.org/browse/WFCORE-761 > Project: WildFly Core > Issue Type: Bug > Components: Server > Reporter: Bartosz Baranowski > Assignee: Lin Gao > > It is either bug in how deployments are treated or how overlay/vfs work. > Steps to reproduce: > 1. deploy undexploded war with jar inside > 2. add overlay that will add non existing file in jar > Result: exception: > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay WEB-INF/lib/overlayed.jar//META-INF/x/file.txt at WEB-INF/lib/overlayed.jar//META-INF/x/file.txt > Caused by: java.io.FileNotFoundException: /content/shell.war/WEB-INF/lib/overlayed.jar/META-INF/x/file.txt"}} > at org.jboss.as.test.integration.management.ManagementOperations.executeOperation(ManagementOperations.java:67) > at org.jboss.as.test.integration.management.ManagementOperations.executeOperation(ManagementOperations.java:37) > at org.jboss.as.test.integration.deployment.deploymentoverlay.jar.OverlayUtils.setupOverlay(OverlayUtils.java:76) > at org.jboss.as.test.integration.deployment.deploymentoverlay.war.OverlayNonExistingResourceTestCase.testOverlay(OverlayNonExistingResourceTestCase.java:67) > Expectation: > should work. It actually does work, if war is really exploded or > 'if(exploded)' part in overlay is removed from overlay processor and everything is handled via: https://github.com/stuartwdouglas/wildfly-core/blob/a75af9118c4062fafb899... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2015