[JBoss JIRA] (AS7-5379) CLONE - Stale data received with SYNC on failover
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-5379?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on AS7-5379:
---------------------------------------
Does this semi-duplicate AS7-4818, just expanding it cover REPL as well?
> CLONE - Stale data received with SYNC on failover
> -------------------------------------------------
>
> Key: AS7-5379
> URL: https://issues.jboss.org/browse/AS7-5379
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Environment: affected 6.0.0 DR CI build
> Reporter: Radoslav Husar
> Assignee: Paul Ferraro
> Priority: Critical
> Labels: as713tracking
> Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1
>
>
> After verifying fix for JBPAPP-8937 I am instead seeing stale data received when using DIST SYNC replication.
> REPL SYNC: On a failover after the application has been gracefully undeployed, a request can be getting data older by cca 40 seconds:
> {noformat}
> 2012/08/14 15:12:53:327 EDT [WARN ][Runner - 1295] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 46, received 35, Runner: 1295>
> org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 46, received 35, Runner: 1295
> at org.jboss.smartfrog.loaddriver.http.AbstractSerialNumberValidatorFactoryImpl$SerialNumberValidator.processRequest(AbstractSerialNumberValidatorFactoryImpl.java:125)
> at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
> at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
> at java.lang.Thread.run(Thread.java:662)
> {noformat}
> DIST SYNC: On server crash stale data can be received:
> {noformat}
> 2012/08/04 05:13:49:714 EDT [WARN ][Runner - 8] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 43, received 42, Runner: 8>
> org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 43, received 42, Runner: 8
> at org.jboss.smartfrog.loaddriver.http.AbstractSerialNumberValidatorFactoryImpl$SerialNumberValidator.processRequest(AbstractSerialNumberValidatorFactoryImpl.java:125)
> at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
> at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
> at java.lang.Thread.run(Thread.java:662)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (SECURITY-690) System property replacement mangles windows paths
by Brian Stansberry (JIRA)
Brian Stansberry created SECURITY-690:
-----------------------------------------
Summary: System property replacement mangles windows paths
Key: SECURITY-690
URL: https://issues.jboss.org/browse/SECURITY-690
Project: PicketBox (JBoss Security and Identity Management)
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: PicketBox_4_0_12.Final
Reporter: Brian Stansberry
Assignee: Anil Saldhana
Priority: Critical
PicketBoxSecurityVault is replacing all appearances of ":" in the KEYSTORE_URL and ENC_FILE_DIR with "::". It is assuming the ":" is separator in system property replacement expression, but ":" is also a common character in a URL. Result is:
00:17:22,777 ERROR [org.jboss.as.controller.management-operation] JBAS014612: Operation ("add") failed - address: ([("core-service" => "vault")]): java.lang.RuntimeException: JBAS015804: Error initializing vault -- org.jboss.as.server.services.security.VaultReaderException: org.jboss.security.vault.SecurityVaultException: org.jboss.security.vault.SecurityVaultException: PBOX000123: File or directory C::\development\java\jboss-as\testsuite\integration\basic/src/test/resources/security/ does not exist
at org.jboss.as.server.services.security.VaultAddHandler.performRuntime(VaultAddHandler.java:115)
at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:50) [jboss-as-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397) [jboss-as-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284) [jboss-as-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211) [jboss-as-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.controller.ParallelBootOperationStepHandler.execute(ParallelBootOperationStepHandler.java:161) [jboss-as-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397) [jboss-as-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284) [jboss-as-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211) [jboss-as-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:175) [jboss-as-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:191) [jboss-as-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.server.ServerService.boot(ServerService.java:300)
at org.jboss.as.server.ServerService.boot(ServerService.java:275)
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:156) [jboss-as-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31]
Caused by: org.jboss.as.server.services.security.VaultReaderException: org.jboss.security.vault.SecurityVaultException: org.jboss.security.vault.SecurityVaultException: PBOX000123: File or directory C::\development\java\jboss-as\testsuite\integration\basic/src/test/resources/security/ does not exist
at org.jboss.as.security.vault.RuntimeVaultReader.createVault(RuntimeVaultReader.java:84)
at org.jboss.as.server.services.security.VaultAddHandler.performRuntime(VaultAddHandler.java:113)
... 14 more
Caused by: org.jboss.security.vault.SecurityVaultException: org.jboss.security.vault.SecurityVaultException: PBOX000123: File or directory C::\development\java\jboss-as\testsuite\integration\basic/src/test/resources/security/ does not exist
at org.picketbox.plugins.vault.PicketBoxSecurityVault.init(PicketBoxSecurityVault.java:195)
at org.jboss.as.security.vault.RuntimeVaultReader.createVault(RuntimeVaultReader.java:82)
... 15 more
Caused by: org.jboss.security.vault.SecurityVaultException: PBOX000123: File or directory C::\development\java\jboss-as\testsuite\integration\basic/src/test/resources/security/ does not exist
at org.picketbox.plugins.vault.PicketBoxSecurityVault.init(PicketBoxSecurityVault.java:173)
... 16 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (AS7-5381) CLONE - "IllegalStateException: repl: Received prepare cache view request, but we are not a member"
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/AS7-5381?page=com.atlassian.jira.plugin.s... ]
Radoslav Husar updated AS7-5381:
--------------------------------
Description: Track on JBPAPP-9658. (was: We are seeing problems with view installs.
Following this event, all (or most) subsequent requests to that node fail with response code 500.
{noformat}
[JBossINF] 13:26:57,797 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-9,null) ISPN000094: Received new cluster view: [perf21/web|8] [perf21/web, perf18/web, perf19/web]
[JBossINF] 13:26:57,838 WARN [org.infinispan.commands.control.CacheViewControlCommand] (OOB-163,null) ISPN000071: Caught exception when handling command CacheViewControlCommand{cache=default-host/clusterbench, type=PREPARE_VIEW, sender=perf20/web, newViewId=13, newMembers=[perf21/web, perf18/web, perf19/web], oldViewId=12, oldMembers=[perf20/web, perf21/web, perf18/web, perf19/web]}: org.infinispan.statetransfer.StateTransferCancelledException
[JBossINF] at org.infinispan.statetransfer.BaseStateTransferTask.checkIfCancelled(BaseStateTransferTask.java:151)
[JBossINF] at org.infinispan.statetransfer.DistributedStateTransferTask.doPerformStateTransfer(DistributedStateTransferTask.java:124)
[JBossINF] at org.infinispan.statetransfer.BaseStateTransferTask.performStateTransfer(BaseStateTransferTask.java:93)
[JBossINF] at org.infinispan.statetransfer.BaseStateTransferManagerImpl.prepareView(BaseStateTransferManagerImpl.java:331)
[JBossINF] at org.infinispan.cacheviews.CacheViewsManagerImpl.handlePrepareView(CacheViewsManagerImpl.java:486)
[JBossINF] at org.infinispan.commands.control.CacheViewControlCommand.perform(CacheViewControlCommand.java:126)
[JBossINF] at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:95)
[JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:226)
[JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:203)
[JBossINF] at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:456)
[JBossINF] at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:363)
[JBossINF] at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:238)
[JBossINF] at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:601)
[JBossINF] at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130)
[JBossINF] at org.jgroups.JChannel.up(JChannel.java:716)
[JBossINF] at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1026)
[JBossINF] at org.jgroups.protocols.RSVP.up(RSVP.java:179)
[JBossINF] at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
[JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
[JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
[JBossINF] at org.jgroups.protocols.pbcast.GMS.up(GMS.java:889)
[JBossINF] at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
[JBossINF] at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:759)
[JBossINF] at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:365)
[JBossINF] at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:602)
[JBossINF] at org.jgroups.protocols.BARRIER.up(BARRIER.java:102)
[JBossINF] at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
[JBossINF] at org.jgroups.protocols.FD.up(FD.java:273)
[JBossINF] at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
[JBossINF] at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
[JBossINF] at org.jgroups.protocols.Discovery.up(Discovery.java:359)
[JBossINF] at org.jgroups.stack.Protocol.up(Protocol.java:363)
[JBossINF] at org.jgroups.protocols.TP.passMessageUp(TP.java:1185)
[JBossINF] at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1733)
[JBossINF] at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1715)
[JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
[JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
[JBossINF] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
{noformat}
and
{noformat}
[JBossINF] 13:27:48,163 WARN [org.infinispan.commands.control.CacheViewControlCommand] (OOB-14,null) ISPN000071: Caught exception when handling command CacheViewControlCommand{cache=remote-connector-client-mappings, type=PREPARE_VIEW, sender=perf21/ejb, newViewId=19, newMembers=[perf18/ejb, perf21/ejb, perf19/ejb], oldViewId=18, oldMembers=[perf18/ejb, perf21/ejb, perf19/ejb]}: java.lang.IllegalStateException: remote-connector-client-mappings: Received prepare cache view request, but we are not a member. View is CacheView{viewId=19, members=[perf18/ejb, perf21/ejb, perf19/ejb]}
[JBossINF] at org.infinispan.cacheviews.CacheViewsManagerImpl.handlePrepareView(CacheViewsManagerImpl.java:473)
[JBossINF] at org.infinispan.commands.control.CacheViewControlCommand.perform(CacheViewControlCommand.java:126)
[JBossINF] at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:95)
[JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:226)
[JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:203)
[JBossINF] at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:456)
[JBossINF] at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:363)
[JBossINF] at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:238)
[JBossINF] at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:601)
[JBossINF] at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130)
[JBossINF] at org.jgroups.JChannel.up(JChannel.java:716)
[JBossINF] at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1026)
[JBossINF] at org.jgroups.protocols.RSVP.up(RSVP.java:179)
[JBossINF] at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
[JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
[JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
[JBossINF] at org.jgroups.protocols.pbcast.GMS.up(GMS.java:889)
[JBossINF] at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
[JBossINF] at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:383)
[JBossINF] at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:706)
[JBossINF] at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:566)
[JBossINF] at org.jgroups.protocols.BARRIER.up(BARRIER.java:126)
[JBossINF] at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
[JBossINF] at org.jgroups.protocols.FD.up(FD.java:273)
[JBossINF] at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
[JBossINF] at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
[JBossINF] at org.jgroups.protocols.Discovery.up(Discovery.java:359)
[JBossINF] at org.jgroups.stack.Protocol.up(Protocol.java:363)
[JBossINF] at org.jgroups.protocols.TP.passMessageUp(TP.java:1185)
[JBossINF] at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1733)
[JBossINF] at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1715)
[JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
[JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
[JBossINF] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
{noformat}
Seen here
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-Fail...
)
> CLONE - "IllegalStateException: repl: Received prepare cache view request, but we are not a member"
> ---------------------------------------------------------------------------------------------------
>
> Key: AS7-5381
> URL: https://issues.jboss.org/browse/AS7-5381
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Environment: affected 6.0.1 DR1 CI build
> Reporter: Radoslav Husar
> Assignee: Paul Ferraro
> Priority: Blocker
> Labels: as713tracking, eap601candidate
> Fix For: 7.1.3.Final (EAP)
>
>
> Track on JBPAPP-9658.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (AS7-5381) CLONE - "IllegalStateException: repl: Received prepare cache view request, but we are not a member"
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/AS7-5381?page=com.atlassian.jira.plugin.s... ]
Radoslav Husar moved JBPAPP-9699 to AS7-5381:
---------------------------------------------
Project: Application Server 7 (was: JBoss Enterprise Application Platform)
Key: AS7-5381 (was: JBPAPP-9699)
Workflow: GIT Pull Request workflow (was: jira)
Assignee: Paul Ferraro (was: Dan Berindei)
Component/s: Clustering
(was: Clustering)
Security: (was: Public)
Fix Version/s: 7.1.3.Final (EAP)
(was: EAP 6.0.1 ER 1)
Docs QE Status: (was: NEW)
> CLONE - "IllegalStateException: repl: Received prepare cache view request, but we are not a member"
> ---------------------------------------------------------------------------------------------------
>
> Key: AS7-5381
> URL: https://issues.jboss.org/browse/AS7-5381
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Environment: affected 6.0.1 DR1 CI build
> Reporter: Radoslav Husar
> Assignee: Paul Ferraro
> Priority: Blocker
> Labels: as713tracking, eap601candidate
> Fix For: 7.1.3.Final (EAP)
>
>
> We are seeing problems with view installs.
> Following this event, all (or most) subsequent requests to that node fail with response code 500.
> {noformat}
> [JBossINF] 13:26:57,797 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-9,null) ISPN000094: Received new cluster view: [perf21/web|8] [perf21/web, perf18/web, perf19/web]
> [JBossINF] 13:26:57,838 WARN [org.infinispan.commands.control.CacheViewControlCommand] (OOB-163,null) ISPN000071: Caught exception when handling command CacheViewControlCommand{cache=default-host/clusterbench, type=PREPARE_VIEW, sender=perf20/web, newViewId=13, newMembers=[perf21/web, perf18/web, perf19/web], oldViewId=12, oldMembers=[perf20/web, perf21/web, perf18/web, perf19/web]}: org.infinispan.statetransfer.StateTransferCancelledException
> [JBossINF] at org.infinispan.statetransfer.BaseStateTransferTask.checkIfCancelled(BaseStateTransferTask.java:151)
> [JBossINF] at org.infinispan.statetransfer.DistributedStateTransferTask.doPerformStateTransfer(DistributedStateTransferTask.java:124)
> [JBossINF] at org.infinispan.statetransfer.BaseStateTransferTask.performStateTransfer(BaseStateTransferTask.java:93)
> [JBossINF] at org.infinispan.statetransfer.BaseStateTransferManagerImpl.prepareView(BaseStateTransferManagerImpl.java:331)
> [JBossINF] at org.infinispan.cacheviews.CacheViewsManagerImpl.handlePrepareView(CacheViewsManagerImpl.java:486)
> [JBossINF] at org.infinispan.commands.control.CacheViewControlCommand.perform(CacheViewControlCommand.java:126)
> [JBossINF] at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:95)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:226)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:203)
> [JBossINF] at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:456)
> [JBossINF] at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:363)
> [JBossINF] at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:238)
> [JBossINF] at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:601)
> [JBossINF] at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130)
> [JBossINF] at org.jgroups.JChannel.up(JChannel.java:716)
> [JBossINF] at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1026)
> [JBossINF] at org.jgroups.protocols.RSVP.up(RSVP.java:179)
> [JBossINF] at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
> [JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
> [JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
> [JBossINF] at org.jgroups.protocols.pbcast.GMS.up(GMS.java:889)
> [JBossINF] at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
> [JBossINF] at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:759)
> [JBossINF] at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:365)
> [JBossINF] at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:602)
> [JBossINF] at org.jgroups.protocols.BARRIER.up(BARRIER.java:102)
> [JBossINF] at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
> [JBossINF] at org.jgroups.protocols.FD.up(FD.java:273)
> [JBossINF] at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
> [JBossINF] at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
> [JBossINF] at org.jgroups.protocols.Discovery.up(Discovery.java:359)
> [JBossINF] at org.jgroups.stack.Protocol.up(Protocol.java:363)
> [JBossINF] at org.jgroups.protocols.TP.passMessageUp(TP.java:1185)
> [JBossINF] at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1733)
> [JBossINF] at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1715)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
> [JBossINF] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> {noformat}
> and
> {noformat}
> [JBossINF] 13:27:48,163 WARN [org.infinispan.commands.control.CacheViewControlCommand] (OOB-14,null) ISPN000071: Caught exception when handling command CacheViewControlCommand{cache=remote-connector-client-mappings, type=PREPARE_VIEW, sender=perf21/ejb, newViewId=19, newMembers=[perf18/ejb, perf21/ejb, perf19/ejb], oldViewId=18, oldMembers=[perf18/ejb, perf21/ejb, perf19/ejb]}: java.lang.IllegalStateException: remote-connector-client-mappings: Received prepare cache view request, but we are not a member. View is CacheView{viewId=19, members=[perf18/ejb, perf21/ejb, perf19/ejb]}
> [JBossINF] at org.infinispan.cacheviews.CacheViewsManagerImpl.handlePrepareView(CacheViewsManagerImpl.java:473)
> [JBossINF] at org.infinispan.commands.control.CacheViewControlCommand.perform(CacheViewControlCommand.java:126)
> [JBossINF] at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:95)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:226)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:203)
> [JBossINF] at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:456)
> [JBossINF] at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:363)
> [JBossINF] at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:238)
> [JBossINF] at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:601)
> [JBossINF] at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130)
> [JBossINF] at org.jgroups.JChannel.up(JChannel.java:716)
> [JBossINF] at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1026)
> [JBossINF] at org.jgroups.protocols.RSVP.up(RSVP.java:179)
> [JBossINF] at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
> [JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
> [JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
> [JBossINF] at org.jgroups.protocols.pbcast.GMS.up(GMS.java:889)
> [JBossINF] at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
> [JBossINF] at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:383)
> [JBossINF] at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:706)
> [JBossINF] at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:566)
> [JBossINF] at org.jgroups.protocols.BARRIER.up(BARRIER.java:126)
> [JBossINF] at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
> [JBossINF] at org.jgroups.protocols.FD.up(FD.java:273)
> [JBossINF] at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
> [JBossINF] at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
> [JBossINF] at org.jgroups.protocols.Discovery.up(Discovery.java:359)
> [JBossINF] at org.jgroups.stack.Protocol.up(Protocol.java:363)
> [JBossINF] at org.jgroups.protocols.TP.passMessageUp(TP.java:1185)
> [JBossINF] at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1733)
> [JBossINF] at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1715)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
> [JBossINF] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> {noformat}
> Seen here
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-Fail...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (AS7-5379) CLONE - Stale data received with SYNC on failover
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/AS7-5379?page=com.atlassian.jira.plugin.s... ]
Radoslav Husar updated AS7-5379:
--------------------------------
Summary: CLONE - Stale data received with SYNC on failover (was: CLONE - Stale data received with DIST SYNC on failover)
Description:
After verifying fix for JBPAPP-8937 I am instead seeing stale data received when using DIST SYNC replication.
REPL SYNC: On a failover after the application has been gracefully undeployed, a request can be getting data older by cca 40 seconds:
{noformat}
2012/08/14 15:12:53:327 EDT [WARN ][Runner - 1295] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 46, received 35, Runner: 1295>
org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 46, received 35, Runner: 1295
at org.jboss.smartfrog.loaddriver.http.AbstractSerialNumberValidatorFactoryImpl$SerialNumberValidator.processRequest(AbstractSerialNumberValidatorFactoryImpl.java:125)
at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
at java.lang.Thread.run(Thread.java:662)
{noformat}
DIST SYNC: On server crash stale data can be received:
{noformat}
2012/08/04 05:13:49:714 EDT [WARN ][Runner - 8] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 43, received 42, Runner: 8>
org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 43, received 42, Runner: 8
at org.jboss.smartfrog.loaddriver.http.AbstractSerialNumberValidatorFactoryImpl$SerialNumberValidator.processRequest(AbstractSerialNumberValidatorFactoryImpl.java:125)
at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
at java.lang.Thread.run(Thread.java:662)
{noformat}
was:
After verifying fix for JBPAPP-8937 I am instead seeing stale data received when using DIST SYNC replication.
On a failover after the application has been gracefully undeployed, a request can be getting data older by cca 40 seconds:
{noformat}
2012/08/14 15:12:53:327 EDT [WARN ][Runner - 1295] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 46, received 35, Runner: 1295>
org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 46, received 35, Runner: 1295
at org.jboss.smartfrog.loaddriver.http.AbstractSerialNumberValidatorFactoryImpl$SerialNumberValidator.processRequest(AbstractSerialNumberValidatorFactoryImpl.java:125)
at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
at java.lang.Thread.run(Thread.java:662)
{noformat}
On server crash stale data can be received:
{noformat}
2012/08/04 05:13:49:714 EDT [WARN ][Runner - 8] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 43, received 42, Runner: 8>
org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 43, received 42, Runner: 8
at org.jboss.smartfrog.loaddriver.http.AbstractSerialNumberValidatorFactoryImpl$SerialNumberValidator.processRequest(AbstractSerialNumberValidatorFactoryImpl.java:125)
at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
at java.lang.Thread.run(Thread.java:662)
{noformat}
> CLONE - Stale data received with SYNC on failover
> -------------------------------------------------
>
> Key: AS7-5379
> URL: https://issues.jboss.org/browse/AS7-5379
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Environment: affected 6.0.0 DR CI build
> Reporter: Radoslav Husar
> Assignee: Paul Ferraro
> Priority: Critical
> Labels: as713tracking
> Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1
>
>
> After verifying fix for JBPAPP-8937 I am instead seeing stale data received when using DIST SYNC replication.
> REPL SYNC: On a failover after the application has been gracefully undeployed, a request can be getting data older by cca 40 seconds:
> {noformat}
> 2012/08/14 15:12:53:327 EDT [WARN ][Runner - 1295] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 46, received 35, Runner: 1295>
> org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 46, received 35, Runner: 1295
> at org.jboss.smartfrog.loaddriver.http.AbstractSerialNumberValidatorFactoryImpl$SerialNumberValidator.processRequest(AbstractSerialNumberValidatorFactoryImpl.java:125)
> at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
> at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
> at java.lang.Thread.run(Thread.java:662)
> {noformat}
> DIST SYNC: On server crash stale data can be received:
> {noformat}
> 2012/08/04 05:13:49:714 EDT [WARN ][Runner - 8] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 43, received 42, Runner: 8>
> org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 43, received 42, Runner: 8
> at org.jboss.smartfrog.loaddriver.http.AbstractSerialNumberValidatorFactoryImpl$SerialNumberValidator.processRequest(AbstractSerialNumberValidatorFactoryImpl.java:125)
> at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
> at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
> at java.lang.Thread.run(Thread.java:662)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (AS7-5379) CLONE - Stale data received with DIST SYNC on failover
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-5379?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-5379:
----------------------------------
Fix Version/s: 7.2.0.Alpha1
Component/s: Clustering
> CLONE - Stale data received with DIST SYNC on failover
> ------------------------------------------------------
>
> Key: AS7-5379
> URL: https://issues.jboss.org/browse/AS7-5379
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Environment: affected 6.0.0 DR CI build
> Reporter: Radoslav Husar
> Assignee: Paul Ferraro
> Priority: Critical
> Labels: as713tracking
> Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1
>
>
> After verifying fix for JBPAPP-8937 I am instead seeing stale data received when using DIST SYNC replication.
> On a failover after the application has been gracefully undeployed, a request can be getting data older by cca 40 seconds:
> {noformat}
> 2012/08/14 15:12:53:327 EDT [WARN ][Runner - 1295] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 46, received 35, Runner: 1295>
> org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 46, received 35, Runner: 1295
> at org.jboss.smartfrog.loaddriver.http.AbstractSerialNumberValidatorFactoryImpl$SerialNumberValidator.processRequest(AbstractSerialNumberValidatorFactoryImpl.java:125)
> at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
> at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
> at java.lang.Thread.run(Thread.java:662)
> {noformat}
> On server crash stale data can be received:
> {noformat}
> 2012/08/04 05:13:49:714 EDT [WARN ][Runner - 8] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 43, received 42, Runner: 8>
> org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 43, received 42, Runner: 8
> at org.jboss.smartfrog.loaddriver.http.AbstractSerialNumberValidatorFactoryImpl$SerialNumberValidator.processRequest(AbstractSerialNumberValidatorFactoryImpl.java:125)
> at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
> at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
> at java.lang.Thread.run(Thread.java:662)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (AS7-5379) CLONE - Stale data received with DIST SYNC on failover
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/AS7-5379?page=com.atlassian.jira.plugin.s... ]
Radoslav Husar moved JBPAPP-9697 to AS7-5379:
---------------------------------------------
Project: Application Server 7 (was: JBoss Enterprise Application Platform)
Key: AS7-5379 (was: JBPAPP-9697)
Workflow: GIT Pull Request workflow (was: jira)
Security: (was: JBoss Internal)
Fix Version/s: 7.1.3.Final (EAP)
(was: EAP 6.0.1 ER 1)
Docs QE Status: (was: NEW)
> CLONE - Stale data received with DIST SYNC on failover
> ------------------------------------------------------
>
> Key: AS7-5379
> URL: https://issues.jboss.org/browse/AS7-5379
> Project: Application Server 7
> Issue Type: Bug
> Environment: affected 6.0.0 DR CI build
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Critical
> Labels: as713tracking
> Fix For: 7.1.3.Final (EAP)
>
>
> After verifying fix for JBPAPP-8937 I am instead seeing stale data received when using DIST SYNC replication.
> On a failover after the application has been gracefully undeployed, a request can be getting data older by cca 40 seconds:
> {noformat}
> 2012/08/14 15:12:53:327 EDT [WARN ][Runner - 1295] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 46, received 35, Runner: 1295>
> org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 46, received 35, Runner: 1295
> at org.jboss.smartfrog.loaddriver.http.AbstractSerialNumberValidatorFactoryImpl$SerialNumberValidator.processRequest(AbstractSerialNumberValidatorFactoryImpl.java:125)
> at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
> at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
> at java.lang.Thread.run(Thread.java:662)
> {noformat}
> On server crash stale data can be received:
> {noformat}
> 2012/08/04 05:13:49:714 EDT [WARN ][Runner - 8] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 43, received 42, Runner: 8>
> org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 43, received 42, Runner: 8
> at org.jboss.smartfrog.loaddriver.http.AbstractSerialNumberValidatorFactoryImpl$SerialNumberValidator.processRequest(AbstractSerialNumberValidatorFactoryImpl.java:125)
> at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
> at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
> at java.lang.Thread.run(Thread.java:662)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (AS7-5378) Recursive module creation triggered by bundle event
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-5378?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler moved JBOSGI-587 to AS7-5378:
--------------------------------------------
Project: Application Server 7 (was: JBoss OSGi)
Key: AS7-5378 (was: JBOSGI-587)
Workflow: GIT Pull Request workflow (was: jira)
Component/s: OSGi
(was: Core Framework)
Fix Version/s: 7.2.0.Alpha1
(was: JBossOSGi 1.2.0)
> Recursive module creation triggered by bundle event
> ---------------------------------------------------
>
> Key: AS7-5378
> URL: https://issues.jboss.org/browse/AS7-5378
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Fix For: 7.2.0.Alpha1
>
>
> {code}
> at org.jboss.as.osgi.service.ModuleLoaderIntegration.addModule(ModuleLoaderIntegration.java:128)
> at org.jboss.osgi.framework.internal.ModuleManagerPlugin.createHostModule(ModuleManagerPlugin.java:298)
> at org.jboss.osgi.framework.internal.ModuleManagerPlugin.addModule(ModuleManagerPlugin.java:196)
> at org.jboss.osgi.framework.internal.ResolverPlugin.addModules(ResolverPlugin.java:253)
> at org.jboss.osgi.framework.internal.ResolverPlugin.applyResolverResults(ResolverPlugin.java:201)
> at org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:121)
> at org.jboss.osgi.framework.internal.AbstractBundleState.ensureResolved(AbstractBundleState.java:551)
> at org.jboss.osgi.framework.internal.HostBundleRevision.findEntries(HostBundleRevision.java:126)
> at org.jboss.osgi.framework.internal.AbstractBundleState.findEntries(AbstractBundleState.java:443)
> at org.eclipse.gemini.blueprint.extender.internal.support.NamespaceManager.maybeAddNamespaceHandlerFor(NamespaceManager.java:130)
> at org.eclipse.gemini.blueprint.extender.internal.activator.ContextLoaderListener.maybeAddNamespaceHandlerFor(ContextLoaderListener.java:462)
> at org.eclipse.gemini.blueprint.extender.internal.activator.ContextLoaderListener$NamespaceBundleLister.handleEvent(ContextLoaderListener.java:169)
> at org.eclipse.gemini.blueprint.extender.internal.activator.ContextLoaderListener$BaseListener.bundleChanged(ContextLoaderListener.java:137)
> at org.jboss.osgi.framework.internal.FrameworkEventsPlugin.fireBundleEvent(FrameworkEventsPlugin.java:372)
> at org.jboss.osgi.framework.internal.AbstractBundleState.fireBundleEvent(AbstractBundleState.java:198)
> at org.jboss.osgi.framework.internal.AbstractBundleState.changeState(AbstractBundleState.java:192)
> at org.jboss.osgi.framework.internal.AbstractBundleState.changeState(AbstractBundleState.java:174)
> at org.jboss.osgi.framework.internal.ResolverPlugin.setBundleToResolved(ResolverPlugin.java:277)
> at org.jboss.osgi.framework.internal.ResolverPlugin.applyResolverResults(ResolverPlugin.java:207)
> at org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:121)
> at org.jboss.osgi.framework.internal.AbstractBundleState.ensureResolved(AbstractBundleState.java:551)
> at org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:232)
> at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:485)
> at org.jboss.as.osgi.management.BundleResourceHandler.handleOperation(BundleResourceHandler.java:145)
> at org.jboss.as.osgi.management.BundleResourceHandler.executeRuntimeStep(BundleResourceHandler.java:99)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (AS7-5377) WAB deployment requires '.' (dot) Bundle-ClassPath
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-5377?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler moved JBOSGI-559 to AS7-5377:
--------------------------------------------
Project: Application Server 7 (was: JBoss OSGi)
Key: AS7-5377 (was: JBOSGI-559)
Workflow: GIT Pull Request workflow (was: jira)
Affects Version/s: (was: JBossOSGi 1.1.0)
Component/s: OSGi
(was: WebApp)
Security: (was: Public)
Fix Version/s: 7.2.0.Alpha1
(was: JBossOSGi 1.2.0)
> WAB deployment requires '.' (dot) Bundle-ClassPath
> --------------------------------------------------
>
> Key: AS7-5377
> URL: https://issues.jboss.org/browse/AS7-5377
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Fix For: 7.2.0.Alpha1
>
>
> {code}
> 19:36:12,218 ERROR [org.jboss.as.osgi] (MSC service thread 1-4) JBAS011900: Cannot start bundle: MyWebAppBundle:1.0.0: org.osgi.framework.BundleException: Cannot transition to STARTING: MyWebAppBundle:1.0.0
> at org.jboss.osgi.framework.internal.HostBundleState.transitionToActive(HostBundleState.java:284) [jbosgi-framework-core-1.1.8.Final.jar:1.1.8.Final]
> at org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:223) [jbosgi-framework-core-1.1.8.Final.jar:1.1.8.Final]
> at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:494) [jbosgi-framework-core-1.1.8.Final.jar:1.1.8.Final]
> at org.jboss.as.osgi.deployment.BundleStartTracker$1.processService(BundleStartTracker.java:144) [jboss-as-osgi-service-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.osgi.deployment.BundleStartTracker$1.transition(BundleStartTracker.java:119) [jboss-as-osgi-service-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1416) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceControllerImpl.access$2700(ServiceControllerImpl.java:49) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:1954) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) [rt.jar:1.6.0]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) [rt.jar:1.6.0]
> at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0]
> Caused by: org.jboss.osgi.deployment.interceptor.LifecycleInterceptorException: Cannot obtain web.xml from: vfs:/D:/sdk/jboss/jboss-as-7.1.1.Final/bin/content/MyWebAppBundle.jar/WEB-INF/classes/
> at org.jboss.osgi.framework.internal.WebXMLVerifierInterceptor$1.invoke(WebXMLVerifierInterceptor.java:85) [jbosgi-framework-core-1.1.8.Final.jar:1.1.8.Final]
> at org.jboss.osgi.deployment.interceptor.AbstractLifecycleInterceptorService.handleStateChange(AbstractLifecycleInterceptorService.java:281) [jbosgi-deployment-1.0.12.Final.jar:1.0.12.Final]
> at org.jboss.osgi.framework.internal.LifecycleInterceptorPlugin.handleStateChange(LifecycleInterceptorPlugin.java:125) [jbosgi-framework-core-1.1.8.Final.jar:1.1.8.Final]
> at org.jboss.osgi.framework.internal.AbstractBundleState.changeState(AbstractBundleState.java:183) [jbosgi-framework-core-1.1.8.Final.jar:1.1.8.Final]
> at org.jboss.osgi.framework.internal.AbstractBundleState.changeState(AbstractBundleState.java:172) [jbosgi-framework-core-1.1.8.Final.jar:1.1.8.Final]
> at org.jboss.osgi.framework.internal.HostBundleState.transitionToActive(HostBundleState.java:282) [jbosgi-framework-core-1.1.8.Final.jar:1.1.8.Final]
> ... 10 more
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months