August 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5206) Intermittent NPE when invoking method requestDestroyed

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/WFLY-5206?page=com.atlassian.jira.plugin.... ] Jozef Hartinger commented on WFLY-5206: --------------------------------------- The relevant line is here: https://github.com/weld/core/blob/2.3.0.CR1/impl/src/main/java/org/jboss/... Looks like the listener receives a requestDestroyed() call before it is initialized using contextInitialized() callback. > Intermittent NPE when invoking method requestDestroyed > ------------------------------------------------------ > > Key: WFLY-5206 > URL: https://issues.jboss.org/browse/WFLY-5206 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Reporter: Michal Vinkler > Assignee: Stuart Douglas > > Setup: 4-node cluster, one node at time undeploys application (clusterbench-ee7.ear), while standalone clients keep calling the application. > This error was seen during clustering failover testing in the following scenario: > ejb-ejbservlet-repl-sync (failover of HTTP traffic accessing a servlet that locally invokes a stateful clustered EJB, with synchronously replicated cache) > After undeploying application on perf19 (second node in the cluster), NullPointerException was logged 31 times in the server log. > Stacktrace: > {code} > 2015/08/18 20:01:40:973 EDT [DEBUG][RMI TCP Connection(14)-10.16.90.52] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Going to undeploy: 'clusterbench-ee7.ear' from 'perf19' now. > 2015/08/18 20:01:41:265 EDT [DEBUG][RMI TCP Connection(14)-10.16.90.52] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Requesting: { > "operation" : "undeploy", > "address" : [{ > "deployment" : "clusterbench-ee7.ear" > }] > } > 20:01:41,706 INFO [org.xnio] (RMI TCP Connection(14)-10.16.90.52) XNIO version 3.3.1.Final > 20:01:41,918 INFO [org.xnio.nio] (RMI TCP Connection(14)-10.16.90.52) XNIO NIO Implementation Version 3.3.1.Final > 20:01:41,969 INFO [org.jboss.remoting] (RMI TCP Connection(14)-10.16.90.52) JBoss Remoting version 4.0.9.Final > [JBossINF] [0m[0m20:01:42,603 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 79) WFLYUT0022: Unregistered web context: /clusterbench > [JBossINF] [0m[0m20:01:42,603 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 78) WFLYUT0022: Unregistered web context: /clusterbench-passivating > [JBossINF] [0m[0m20:01:42,679 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 78) ISPN000029: Passivating all entries to disk > [JBossINF] [0m[0m20:01:42,679 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 81) ISPN000029: Passivating all entries to disk > [JBossINF] [0m[31m20:01:42,681 ERROR [io.undertow.servlet.request] (default task-46) UT015005: Error invoking method requestDestroyed on listener class org.jboss.weld.servlet.WeldInitialListener: java.lang.NullPointerException > [JBossINF] at org.jboss.weld.servlet.WeldInitialListener.requestDestroyed(WeldInitialListener.java:135) > [JBossINF] at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:225) > [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:325) > [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261) > [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80) > [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172) > [JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) > [JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:778) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [JBossINF] at java.lang.Thread.run(Thread.java:745) > {code} > Server log: > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e... > We also see the very same error in the scenario where the nodes shutdown instead of undeploying application - right after the server shutdown has been requested (we do not use graceful shutdown yet). > Server log: > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e... > May be relevant to https://issues.jboss.org/browse/JBEAP-863 as both errors come together, under the same conditions. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5209) Adding JGroups stack results in freeze

by Jan Kašík (JIRA)

[ https://issues.jboss.org/browse/WFLY-5209?page=com.atlassian.jira.plugin.... ] Jan Kašík moved JBEAP-872 to WFLY-5209: --------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-5209 (was: JBEAP-872) Workflow: GIT Pull Request workflow (was: CDW v1) Affects Version/s: 10.0.0.Beta2 (was: 7.0.0.DR9) Component/s: Web Console (was: Web Console) Target Release: (was: 7.0.0.GA) > Adding JGroups stack results in freeze > -------------------------------------- > > Key: WFLY-5209 > URL: https://issues.jboss.org/browse/WFLY-5209 > Project: WildFly > Issue Type: Bug > Components: Web Console > Affects Versions: 10.0.0.Beta2 > Reporter: Jan Kašík > Assignee: Heiko Braun > Priority: Critical > > Adding new JGroups stack with randomly chosen (non existing) socket binding name results in web console freeze. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5209) Adding JGroups stack results in freeze

by Jan Kašík (JIRA)

[ https://issues.jboss.org/browse/WFLY-5209?page=com.atlassian.jira.plugin.... ] Jan Kašík updated WFLY-5209: ---------------------------- Steps to Reproduce: # Run Wildfly in domain mode # Navigate to JGroups stack table in web console: Configuration -> Profiles -> full-ha -> JGroups and click on View # Click on {{Add}} button # Fill form in wizard ## Fill random name ## Choose {{UDP}} transport ## Fill random socket binding (e.g. asdfasdf) # Click on {{Next}} button # Fill form in wizard ## Select {{UNICAST2}} name ## Fill random socket binding (e.g. gfsdfgsg) ## Click on {{Append}} button # Click on {{Done}} button # Web Console is now frozen (try for example click on back arrow and then selecting any subsystem) was: # Run EAP 7 in domain mode # Navigate to JGroups stack table in web console: Configuration -> Profiles -> full-ha -> JGroups and click on View # Click on {{Add}} button # Fill form in wizard ## Fill random name ## Choose {{UDP}} transport ## Fill random socket binding (e.g. asdfasdf) # Click on {{Next}} button # Fill form in wizard ## Select {{UNICAST2}} name ## Fill random socket binding (e.g. gfsdfgsg) ## Click on {{Append}} button # Click on {{Done}} button # Web Console is now frozen (try for example click on back arrow and then selecting any subsystem) > Adding JGroups stack results in freeze > -------------------------------------- > > Key: WFLY-5209 > URL: https://issues.jboss.org/browse/WFLY-5209 > Project: WildFly > Issue Type: Bug > Components: Web Console > Affects Versions: 10.0.0.Beta2 > Reporter: Jan Kašík > Assignee: Heiko Braun > Priority: Critical > > Adding new JGroups stack with randomly chosen (non existing) socket binding name results in web console freeze. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-782) DefaultAuthenticationCacheFactory should not use internal Infinispan classes

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-782?page=com.atlassian.jira.plugin.s... ] Paul Ferraro closed WFLY-782. ----------------------------- Fix Version/s: 9.0.0.Final (was: 10.0.0.CR1) Resolution: Out of Date This was fixed by https://github.com/wildfly/wildfly/commit/4718770ce4321d8f1f8be9c9720b7a8... > DefaultAuthenticationCacheFactory should not use internal Infinispan classes > ---------------------------------------------------------------------------- > > Key: WFLY-782 > URL: https://issues.jboss.org/browse/WFLY-782 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: NadirX > Assignee: Paul Ferraro > Fix For: 9.0.0.Final > > > The DefaultAuthenticationCacheFactory class (and the AuthenticationCacheEvictionListener class) use internal Infinispan classes which are subject to change without API stability guarantees. The code should be rewritten to use an Infinispan cache instead. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1290) WildFly 10 + Hibernate 5 + Spring 4.2 + JTA stack results in ResourceException

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1290?page=com.atlassian.jira.plugin... ] Jesper Pedersen closed JBJCA-1290. ---------------------------------- Resolution: Rejected Use the user forum for questions > WildFly 10 + Hibernate 5 + Spring 4.2 + JTA stack results in ResourceException > ------------------------------------------------------------------------------ > > Key: JBJCA-1290 > URL: https://issues.jboss.org/browse/JBJCA-1290 > Project: IronJacamar > Issue Type: Bug > Affects Versions: 1.2.5.Final > Reporter: Tomas Repel > Assignee: Jesper Pedersen > > I have EAR with simple non-JPA Hibernate based domain and dao submodules and web submodule. I want to use JTA and container managed transactions. When deploying on WildFly 9 (using Hibernate4) everything works fine. I migrated the app to WildFly 10 (using Hibernate5) but after several clicks in browser an exception is thrown: > {code} > ... > Caused by: javax.resource.ResourceException: IJ000453: Unable to get managed connection for java:jboss/datasources/ExampleDS > at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:646) > at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:430) > at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:737) > at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138) > ... 43 more > Caused by: javax.resource.ResourceException: IJ000655: No managed connections available within configured blocking timeout (30000 [ms]) > at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:569) > at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:627) > at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:599) > at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:579) > ... 46 more > {code} > I have created simple reproducer on github, see https://github.com/trepel/primrose-hibernate-simple > There is also Stack Overflow question, see > http://stackoverflow.com/questions/32114110/wildfly-10-hibernate-5-spring... > It was suggested that this might be related to IronJacamar. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-907) Make the wrapping of the GSSCredential in the KerberosLoginModule configurable.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/SECURITY-907?page=com.atlassian.jira.plug... ] Darran Lofthouse resolved SECURITY-907. --------------------------------------- Resolution: Done > Make the wrapping of the GSSCredential in the KerberosLoginModule configurable. > ------------------------------------------------------------------------------- > > Key: SECURITY-907 > URL: https://issues.jboss.org/browse/SECURITY-907 > Project: PicketBox > Issue Type: Task > Components: Negotiation > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: Negotiation_2_3_8_Final > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-907) Make the wrapping of the GSSCredential in the KerberosLoginModule configurable.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/SECURITY-907?page=com.atlassian.jira.plug... ] Darran Lofthouse updated SECURITY-907: -------------------------------------- Fix Version/s: Negotiation_2_3_8_Final (was: Negotiation_2_3_8_CR1) > Make the wrapping of the GSSCredential in the KerberosLoginModule configurable. > ------------------------------------------------------------------------------- > > Key: SECURITY-907 > URL: https://issues.jboss.org/browse/SECURITY-907 > Project: PicketBox > Issue Type: Task > Components: Negotiation > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: Negotiation_2_3_8_Final > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-908) Release JBoss Negotiation 2.3.8.Final

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/SECURITY-908?page=com.atlassian.jira.plug... ] Darran Lofthouse updated SECURITY-908: -------------------------------------- Fix Version/s: Negotiation_2_3_8_Final (was: Negotiation_2_3_8_CR1) > Release JBoss Negotiation 2.3.8.Final > ------------------------------------- > > Key: SECURITY-908 > URL: https://issues.jboss.org/browse/SECURITY-908 > Project: PicketBox > Issue Type: Release > Components: Negotiation > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: Negotiation_2_3_8_Final > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-908) Release JBoss Negotiation 2.3.8.Final

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/SECURITY-908?page=com.atlassian.jira.plug... ] Darran Lofthouse updated SECURITY-908: -------------------------------------- Summary: Release JBoss Negotiation 2.3.8.Final (was: Release JBoss Negotiation 2.3.8.CR1) > Release JBoss Negotiation 2.3.8.Final > ------------------------------------- > > Key: SECURITY-908 > URL: https://issues.jboss.org/browse/SECURITY-908 > Project: PicketBox > Issue Type: Release > Components: Negotiation > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: Negotiation_2_3_8_Final > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-264) JPAKnowledgeService stops to work suddenly

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-264?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-264. -------------------------------- Resolution: Out of Date This problem is related with the old reteoo algorithm and cannot happen in phreak because that removeAgendaItem() method is not used there. I just made the separation more evident with this commit https://github.com/droolsjbpm/drools/commit/0282bf6db > JPAKnowledgeService stops to work suddenly > ------------------------------------------ > > Key: DROOLS-264 > URL: https://issues.jboss.org/browse/DROOLS-264 > Project: Drools > Issue Type: Bug > Affects Versions: 5.5.0.Final > Environment: PostgreSQL 8.4 > Linux Ubuntu > JBoss 5.1.0 > Reporter: Nedo Nedic > Assignee: Mario Fusco > > From time to time, while facts are being inserted into session and persisted in database, the following exception occurs. > The session is no more updated because SQL sentences can't be executed anymore. Sometimes, when session is restored from marshalled snapshot the same error happens. > 2013-09-17 11:17:03,959 ERROR [org.drools.persistence.jpa.JpaTimerJobInstance] Unable to execute timer job! > java.lang.RuntimeException: Unable to load session snapshot > at org.drools.persistence.SessionMarshallingHelper.loadSnapshot(SessionMarshallingHelper.java:96) > at org.drools.persistence.SingleSessionCommandService.initKsession(SingleSessionCommandService.java:269) > at org.drools.persistence.SingleSessionCommandService.execute(SingleSessionCommandService.java:369) > at org.drools.persistence.jpa.JpaTimerJobInstance.call(JpaTimerJobInstance.java:34) > at org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:1) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98) > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:619) > Caused by: java.lang.NullPointerException > at org.drools.time.impl.JDKTimerService.removeJob(JDKTimerService.java:133) > at org.drools.common.Scheduler.removeAgendaItem(Scheduler.java:75) > at org.drools.common.DefaultAgenda.removeScheduleItem(DefaultAgenda.java:474) > at org.drools.common.DefaultAgenda.removeActivation(DefaultAgenda.java:349) > at org.drools.common.DefaultAgenda.cancelActivation(DefaultAgenda.java:687) > at org.drools.reteoo.RuleTerminalNode.retractLeftTuple(RuleTerminalNode.java:320) > at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateRetractLeftTuple(SingleLeftTupleSinkAdapter.java:224) > at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateRetractLeftTuple(SingleLeftTupleSinkAdapter.java:98) > at org.drools.reteoo.NotNode.propagateRetractLeftTuple(NotNode.java:444) > at org.drools.reteoo.NotNode.assertObject(NotNode.java:142) > at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59) > at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:364) > at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235) > at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240) > at org.drools.marshalling.impl.ProtobufInputMarshaller.assertHandleIntoOTN(ProtobufInputMarshaller.java:483) > at org.drools.marshalling.impl.ProtobufInputMarshaller.readFactHandles(ProtobufInputMarshaller.java:459) > at org.drools.marshalling.impl.ProtobufInputMarshaller.readSession(ProtobufInputMarshaller.java:259) > at org.drools.marshalling.impl.ProtobufInputMarshaller.readSession(ProtobufInputMarshaller.java:116) > at org.drools.marshalling.impl.ProtobufMarshaller.unmarshall(ProtobufMarshaller.java:143) > at org.drools.persistence.SessionMarshallingHelper.loadSnapshot(SessionMarshallingHelper.java:88) > ... 11 more -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2015