March 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-447) Deadlock when marshalling session using WM listeners and fireUntilHalt

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-447?page=com.atlassian.jira.plugin... ] Mario Fusco reassigned DROOLS-447: ---------------------------------- Assignee: Mario Fusco (was: Edson Tirelli) > Deadlock when marshalling session using WM listeners and fireUntilHalt > ---------------------------------------------------------------------- > > Key: DROOLS-447 > URL: https://issues.jboss.org/browse/DROOLS-447 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.1.Final, 6.1.0.Beta1 > Reporter: Davide Sottara > Assignee: Mario Fusco > Fix For: 6.1.0.Final > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-4260) Occurences of "Exception acquiring ownership of X (via SharedLocalYieldingClusterLockManager)"

by vishal kumar (JIRA)

[ https://issues.jboss.org/browse/AS7-4260?page=com.atlassian.jira.plugin.s... ] vishal kumar commented on AS7-4260: ----------------------------------- Hi, We are facing the exactly same issue, can you please help in finding out the route cause. We are having two jboss in standalone cluster , they are giving this particular issue while using the application. Thanks > Occurences of "Exception acquiring ownership of X (via SharedLocalYieldingClusterLockManager)" > ---------------------------------------------------------------------------------------------- > > Key: AS7-4260 > URL: https://issues.jboss.org/browse/AS7-4260 > Project: Application Server 7 > Issue Type: Bug > Components: Clustering > Affects Versions: 7.1.1.Final > Reporter: Radoslav Husar > Assignee: Paul Ferraro > Labels: JBAS018080, as713tracking > Fix For: 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final) > > Attachments: SessionTravel.gif, view-perf18.log, view-perf19.log, view-perf20.log, view-perf21.log > > > There are often occurrences of "Exception acquiring ownership of X": > During shutdown, using dist: > {noformat} > 13:09:28,290 WARN [org.apache.catalina.session.ManagerBase] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) JBAS018080: Standard expiration of session qLQps+CQJxEi6pJTBSzis0g3 failed; switching to a brute force cleanup. Problem is JBAS018060: Exception acquiring ownership of qLQps+CQJxEi6pJTBSzis0g3 > {noformat} > During server crash, using repl: > {noformat} > 12:55:49,556 INFO [org.jboss.as.clustering.impl.CoreGroupCommunicationService.ejb] (Incoming-2,null) JBAS010248: New cluster view for partition ejb: 6 (org.jboss.as.clustering.impl.CoreGroupCommunicationService$GroupView@327579f6 delta: -1, merge: false) > 12:55:49,557 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,null) ISPN000094: Received new cluster view: [perf21/ejb|6] [perf21/ejb, perf20/ejb, perf18/ejb] > 12:56:31,694 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host]] (ajp-perf20-10.16.90.58-8009-211) Exception sending request initialized lifecycle event to listener instance of class org.jboss.weld.servlet.WeldListener: java.lang.RuntimeException: JBAS018060: Exception acquiring ownership of MvwC8KGWTuKPjD1-JjLW7URZ > at org.jboss.as.web.session.ClusteredSession.acquireSessionOwnership(ClusteredSession.java:528) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] > at org.jboss.as.web.session.ClusteredSession.expire(ClusteredSession.java:1260) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] > at org.jboss.as.web.session.ClusteredSession.isValid(ClusteredSession.java:1208) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] > at org.jboss.as.web.session.ClusteredSession.isValid(ClusteredSession.java:598) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] > at org.jboss.as.web.session.DistributableSessionManager.add(DistributableSessionManager.java:917) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] > at org.jboss.as.web.session.DistributableSessionManager.loadSession(DistributableSessionManager.java:1407) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] > at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:686) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] > at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:85) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] > at org.apache.catalina.connector.Request.doGetSession(Request.java:2618) [jbossweb-7.0.13.Final.jar:] > at org.apache.catalina.connector.Request.getSession(Request.java:2375) [jbossweb-7.0.13.Final.jar:] > at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:841) [jbossweb-7.0.13.Final.jar:] > at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.getSession(LazySessionBeanStore.java:72) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31] > at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.<init>(LazySessionBeanStore.java:58) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31] > at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:31) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31] > at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:16) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31] > at org.jboss.weld.servlet.WeldListener.requestInitialized(WeldListener.java:134) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31] > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143) [jbossweb-7.0.13.Final.jar:] > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:] > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:] > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:] > at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:505) [jbossweb-7.0.13.Final.jar:] > at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:445) [jbossweb-7.0.13.Final.jar:] > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:] > at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30] > Caused by: org.jboss.as.clustering.lock.TimeoutException: JBAS010223: Cannot acquire lock //default-host//clusterbench/MvwC8KGWTuKPjD1-JjLW7URZ from cluster > at org.jboss.as.clustering.lock.SharedLocalYieldingClusterLockManager.lock(SharedLocalYieldingClusterLockManager.java:439) > at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.acquireSessionOwnership(DistributedCacheManager.java:372) > at org.jboss.as.web.session.ClusteredSession.acquireSessionOwnership(ClusteredSession.java:520) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] > ... 23 more > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SECURITY-805) Overload SecurityVaultFactory.get() to be able to specify the classloader

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-805?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-805: -------------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1079930|https://bugzilla.redhat.com/show_bug.cgi?id=1079930] from NEW to ASSIGNED > Overload SecurityVaultFactory.get() to be able to specify the classloader > ------------------------------------------------------------------------- > > Key: SECURITY-805 > URL: https://issues.jboss.org/browse/SECURITY-805 > Project: PicketBox > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Kabir Khan > Assignee: Kabir Khan > Attachments: SECURITY-805-2.diff, SECURITY-805.diff > > > To work better with modular class loading in WF -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SECURITY-805) Overload SecurityVaultFactory.get() to be able to specify the classloader

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-805?page=com.atlassian.jira.plug... ] RH Bugzilla Integration updated SECURITY-805: --------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1079930 > Overload SecurityVaultFactory.get() to be able to specify the classloader > ------------------------------------------------------------------------- > > Key: SECURITY-805 > URL: https://issues.jboss.org/browse/SECURITY-805 > Project: PicketBox > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Kabir Khan > Assignee: Kabir Khan > Attachments: SECURITY-805-2.diff, SECURITY-805.diff > > > To work better with modular class loading in WF -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBEE-146) jboss-el-api_2.2_spec 1.0.2.Final cannot access public methods from non-public classes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBEE-146?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on JBEE-146: ---------------------------------------------- Matous Jobanek <mjobanek(a)redhat.com> changed the Status of [bug 1076320|https://bugzilla.redhat.com/show_bug.cgi?id=1076320] from ON_QA to VERIFIED > jboss-el-api_2.2_spec 1.0.2.Final cannot access public methods from non-public classes > -------------------------------------------------------------------------------------- > > Key: JBEE-146 > URL: https://issues.jboss.org/browse/JBEE-146 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Reporter: Farah Juma > Assignee: Farah Juma > Fix For: jboss-el-api_2.2_spec-1.0.3.Final, jboss-el-api_3.0_spec-1.0.0.Final > > > When accessing a public method of a non-public class via EL that implements a public interface or has a public superclass, the following exception occurs: > {code}java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "public" > {code} > See https://bugzilla.redhat.com/show_bug.cgi?id=1029387 for more details. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-2493) EL cannot access public methods/fields of non-public classes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2493?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2493: ----------------------------------------------- Matous Jobanek <mjobanek(a)redhat.com> changed the Status of [bug 1076320|https://bugzilla.redhat.com/show_bug.cgi?id=1076320] from ON_QA to VERIFIED > EL cannot access public methods/fields of non-public classes > ------------------------------------------------------------ > > Key: WFLY-2493 > URL: https://issues.jboss.org/browse/WFLY-2493 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JSF > Environment: JBoss AS 7.2.0.Final > Reporter: Jonáš Trantina > Attachments: elresolver_stack, reproducer.zip > > > When trying to access public method/field of non-public class that implements public interface via EL I get > {noformat} > java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "private" > {noformat} > E.g. accessing Collections.unmodifiableList(..).size() via EL will throw the exception, because #unmodifiableList returns non-public implementation of List interface. > This is apparently caused by JDK-4071957 [1], but since that is opened for over 16 years, it should be probably worth it to implement a workaround. > Workaround for this issue is setting setAccessible(true) on the method before invoking it, thus suppress Java access checking. > I have attached a simple reproducer app as well as a stack trace of the exception. > [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4071957 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3108) Can't promote --backup slave HC to master and reload without moving domain.cached-remote.xml

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3108?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3108: ----------------------------------------------- Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 1076066|https://bugzilla.redhat.com/show_bug.cgi?id=1076066] from ON_QA to VERIFIED > Can't promote --backup slave HC to master and reload without moving domain.cached-remote.xml > -------------------------------------------------------------------------------------------- > > Key: WFLY-3108 > URL: https://issues.jboss.org/browse/WFLY-3108 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 8.0.1.Final > > > The prescribed mechanism for converting a slave HC to master is to: > 1) Start the slave with --backup so a local copy of the domain config is maintained (in file domain.cached-remote.xml). > 2) Stop the existing master. > 3) Use the cli to connect to the slave and > /host=<slavename>:write-local-domain-controller > 4) Then, in the CLI > reload --host=<slavename> > Problem is this fails because the HC expects to have a domain config file "domain.xml". > 2014-03-13 09:54:04,829 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010932: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:514) [wildfly-host-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45] > Caused by: java.io.FileNotFoundException: /Users/bstansberry/tmp/WF801/slave/domain/configuration/domain.xml (No such file or directory) > at java.io.FileInputStream.open(Native Method) [rt.jar:1.7.0_45] > at java.io.FileInputStream.<init>(FileInputStream.java:146) [rt.jar:1.7.0_45] > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:100) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > ... 3 more > Or, MUCH WORSE, there happens to be a random domain.xml in the filesystem, which has content that is out of sync with the correct domain config. This domain.xml config will be used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3029) add remove-jndi operations to JMS resources

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3029?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-3029: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1079457 > add remove-jndi operations to JMS resources > ------------------------------------------- > > Key: WFLY-3029 > URL: https://issues.jboss.org/browse/WFLY-3029 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: JMS > Affects Versions: 8.0.0.Final > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 8.0.1.Final > > > JMS resources have a "add-jndi" operation to add a JNDI binding to their entries attribute but there is no mechanism to remove one JNDI binding. > A remove-jndi operation must be added to handle this use case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3144) Session replication doesn't work as expected

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-3144?page=com.atlassian.jira.plugin.... ] Stuart Douglas updated WFLY-3144: --------------------------------- Component/s: Clustering > Session replication doesn't work as expected > -------------------------------------------- > > Key: WFLY-3144 > URL: https://issues.jboss.org/browse/WFLY-3144 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld, Clustering, EJB > Affects Versions: 8.0.0.Final > Reporter: Tomas Remes > Assignee: Stuart Douglas > Attachments: translator.zip > > > I am experimenting with quite simple Stateful SessionScoped bean ( see org.jboss.weld.tests.clustering.translator.TranslatorControllerBean from attached reproducer) and actually there's not any specific exception, but the behavior is at least weird. I haven't tried with plain EJB so far. Reproducible by following steps: > 1. Run first node with "/bin/standalone.sh -c standalone-ha.xml" > 2. Run second node with "./bin/standalone.sh -c standalone-ha.xml -Djboss.socket.binding.port-offset=100 -Djboss.node.name=second" > 3. Build and deploy attached reproducer > 4. Open 127.0.0.1:8080/translator in your browser and translate something. > 5. Open 127.0.0.1:8180/translator and note that number of translated sentences is not replicated correctly. > This works correctly in EAP. I am running with default standalone-ha configuration on oracle's 1.7.0_45 jdk. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-315) Avoid running out of threads when connecting to the DC from a slave to pull down missing data

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-315?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on WFLY-315: --------------------------------------- The IO I'm talking about is writes. The reads are all done by remoting threads, so that's fine. But in many places the thread executing an op itself writes, e.g. to proxy a request, to send a prepared, failed or completed response, or to send a commit/rollback instruction. The problem with this is if an administrative action to cancel the op occurs, the thread is interrupted, and when that thread later interacts with the channel to write, the channel gets closed. Testing administratively cancelling ops from various processes I was regularly seeing the connection from a slave to the master or a server to its HC getting closed. > Avoid running out of threads when connecting to the DC from a slave to pull down missing data > --------------------------------------------------------------------------------------------- > > Key: WFLY-315 > URL: https://issues.jboss.org/browse/WFLY-315 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Kabir Khan > Assignee: Emanuel Muckenhuber > Priority: Blocker > Fix For: 9.0.0.CR1 > > > For WFLY-259 when a slave connects to the DC to pull down missing data, it does this by either getting a lock for the DC, or by joining the permit of the existing DC lock if the request to update a slave's server-config was executed as part of a composite obtaining a lock on the DC. > The way it works at present there is a thread per slave which is blocked until the transaction completes. The DC threads are a finite resource, so a large number of slaves trying to pull down dats will cause deadlock -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

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 March 2014