[JBoss JIRA] (AS7-4278) CLONE - Performance regression introduced in AS7-4205
by Radoslav Husar (JIRA)
Radoslav Husar created AS7-4278:
-----------------------------------
Summary: CLONE - Performance regression introduced in AS7-4205
Key: AS7-4278
URL: https://issues.jboss.org/browse/AS7-4278
Project: Application Server 7
Issue Type: Bug
Components: Clustering
Affects Versions: No Release
Reporter: Radoslav Husar
Assignee: Paul Ferraro
Fix For: 7.1.2.Final
After https://github.com/jbossas/jboss-as/pull/1869 we are seeing read time-outs on the clients and TimeoutException on the server.
{noformat}
[JBossINF] 12:46:55,011 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (OOB-5717,null) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [15 seconds] on key [OKaB26plMWYsWpHQS+UmsJ7R] for requestor [GlobalTransaction:<perf21/web>:3592818:remote]! Lock held by [GlobalTransaction:<perf21/web>:3591864:remote]
[JBossINF] at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:204)
[JBossINF] at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLock(LockManagerImpl.java:178)
[JBossINF] at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLock(LockManagerImpl.java:168)
[JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockKeyAndCheckOwnership(AbstractTxLockingInterceptor.java:209)
[JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAndRegisterBackupLock(AbstractTxLockingInterceptor.java:136)
[JBossINF] at org.infinispan.interceptors.locking.OptimisticLockingInterceptor$LockAcquisitionVisitor.visitPutKeyValueCommand(OptimisticLockingInterceptor.java:202)
[JBossINF] at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76)
[JBossINF] at org.infinispan.interceptors.locking.OptimisticLockingInterceptor.acquireLocksVisitingCommands(OptimisticLockingInterceptor.java:262)
[JBossINF] at org.infinispan.interceptors.locking.OptimisticLockingInterceptor.visitPrepareCommand(OptimisticLockingInterceptor.java:92)
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:131)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
[JBossINF] at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:58)
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:131)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
[JBossINF] at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:113)
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:131)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
[JBossINF] at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:106)
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:131)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
[JBossINF] at org.infinispan.interceptors.StateTransferLockInterceptor.handleWithRetries(StateTransferLockInterceptor.java:208)
[JBossINF] at org.infinispan.interceptors.StateTransferLockInterceptor.visitPrepareCommand(StateTransferLockInterceptor.java:85)
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:131)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
[JBossINF] at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:113)
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:131)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
[JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:130)
[JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:89)
[JBossINF] at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:113)
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:131)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
[JBossINF] at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:113)
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:131)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
[JBossINF] at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:70)
[JBossINF] at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:113)
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:131)
[JBossINF] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345)
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.perform(PrepareCommand.java:127)
[JBossINF] at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:127)
[JBossINF] at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithWaitForBlocks(InboundInvocationHandlerImpl.java:136)
[JBossINF] at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithRetry(InboundInvocationHandlerImpl.java:162)
[JBossINF] at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:114)
[JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:221)
[JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:201)
[JBossINF] at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:456) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:363) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:238) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:543) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.JChannel.up(JChannel.java:716) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1026) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.RSVP.up(RSVP.java:181) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.FRAG2.up(FRAG2.java:181) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:418) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:400) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.pbcast.GMS.up(GMS.java:882) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:759) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:365) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:595) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.BARRIER.up(BARRIER.java:102) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.FD.up(FD.java:273) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:282) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.MERGE2.up(MERGE2.java:205) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.Discovery.up(Discovery.java:359) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.stack.Protocol.up(Protocol.java:358) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.TP.passMessageUp(TP.java:1174) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1722) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1704) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[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}
--
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
14 years, 1 month
[JBoss JIRA] (AS7-4252) Same persistence unit names in unrelated deployments cause service name collision, prevents deployment ("Service jboss.naming.context.java.myEMF is already registered")
by Ondrej Zizka (JIRA)
Ondrej Zizka created AS7-4252:
---------------------------------
Summary: Same persistence unit names in unrelated deployments cause service name collision, prevents deployment ("Service jboss.naming.context.java.myEMF is already registered")
Key: AS7-4252
URL: https://issues.jboss.org/browse/AS7-4252
Project: Application Server 7
Issue Type: Bug
Components: JPA / Hibernate
Affects Versions: 7.1.1.Final
Reporter: Ondrej Zizka
Assignee: Scott Marlow
{code}
11:03:13,184 INFO [org.jboss.as.repository] (management-handler-thread - 11) JBAS014900: Content added at location /home/ondra/work/AS7/ozizka-git2/build/target/jboss-as-7.1.1.Final-redhat-1/standalone/data/content/d7/ef102ffa0086dd1ed05a85c063618f1ddab907/content
11:03:13,300 INFO [org.jboss.as.server.deployment] (MSC service thread 1-15) JBAS015876: Starting deployment of "as7-quickstart-wicket-war.war"
11:03:15,144 INFO [org.jboss.as.jpa] (MSC service thread 1-15) JBAS011401: Read persistence.xml for defaultPersistenceUnit
11:03:15,213 INFO [org.jboss.weld.deployer] (MSC service thread 1-12) JBAS016002: Processing weld deployment as7-quickstart-wicket-war.war
11:03:15,326 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-12) JNDI bindings for session bean named ContactDaoBean in deployment unit deployment "as7-quickstart-wicket-war.war" are as follows:
java:global/as7-quickstart-wicket-war/ContactDaoBean!org.jboss.as.quickstarts.wicket.war.dao.ContactDaoLocal
java:app/as7-quickstart-wicket-war/ContactDaoBean!org.jboss.as.quickstarts.wicket.war.dao.ContactDaoLocal
java:module/ContactDaoBean!org.jboss.as.quickstarts.wicket.war.dao.ContactDaoLocal
java:global/as7-quickstart-wicket-war/ContactDaoBean
java:app/as7-quickstart-wicket-war/ContactDaoBean
java:module/ContactDaoBean
11:03:15,566 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-14) MSC00001: Failed to start service jboss.deployment.unit."as7-quickstart-wicket-war.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."as7-quickstart-wicket-war.war".INSTALL: Failed to process phase INSTALL of deployment "as7-quickstart-wicket-war.war"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_26]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_26]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_26]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011446: Failed to add persistence unit service for defaultPersistenceUnit
at org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor.deployPersistenceUnit(PersistenceUnitDeploymentProcessor.java:383)
at org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor.addPuService(PersistenceUnitDeploymentProcessor.java:258)
at org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor.handleWarDeployment(PersistenceUnitDeploymentProcessor.java:194)
at org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor.deploy(PersistenceUnitDeploymentProcessor.java:118)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
... 5 more
Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.naming.context.java.myEMF is already registered
at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:154) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:227) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:560) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:201) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2228) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:201) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2228) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:307) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor.deployPersistenceUnit(PersistenceUnitDeploymentProcessor.java:358)
... 9 more
11:03:15,835 INFO [org.jboss.as.server] (management-handler-thread - 11) JBAS015870: Deploy of deployment "as7-quickstart-wicket-war.war" was rolled back with failure message {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"as7-quickstart-wicket-war.war\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"as7-quickstart-wicket-war.war\".INSTALL: Failed to process phase INSTALL of deployment \"as7-quickstart-wicket-war.war\""}}
11:03:15,861 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015877: Stopped deployment as7-quickstart-wicket-war.war in 26ms
11:03:15,863 INFO [org.jboss.as.controller] (management-handler-thread - 11) JBAS014774: Service status report
JBAS014777: Services which failed to start: service jboss.deployment.unit."as7-quickstart-wicket-war.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."as7-quickstart-wicket-war.war".INSTALL: Failed to process phase INSTALL of deployment "as7-quickstart-wicket-war.war"
{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
14 years, 1 month
[JBoss JIRA] (AS7-4273) Re-visit Namespace Handling in Domain Parsing
by Darran Lofthouse (JIRA)
Darran Lofthouse created AS7-4273:
-------------------------------------
Summary: Re-visit Namespace Handling in Domain Parsing
Key: AS7-4273
URL: https://issues.jboss.org/browse/AS7-4273
Project: Application Server 7
Issue Type: Task
Components: Domain Management
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Priority: Critical
Fix For: 7.1.2.Final
This issue is picking at implementation details within the XML parsing - however this is something that is going to need to be maintained long term so we need to ensure it is right - we had already previously started to have exceptional if statements creeping in before the last clean up and this just leads to confusing code as each method then needs to be compared against every version of the schema - the method per version approach removes that but we need to ensure it is applied consistently.
As an example we now have the following method: -
void parseDomainSocketBindingGroups(final XMLExtendedStreamReader reader, final ModelNode address, final Namespace expectedNs,
final List<ModelNode> list, final Set<String> interfaces) throws XMLStreamException {
while (reader.hasNext() && reader.nextTag() != END_ELEMENT) {
requireNamespace(reader, expectedNs);
final Element element = Element.forName(reader.getLocalName());
switch (element) {
case SOCKET_BINDING_GROUP: {
switch (expectedNs) {
case DOMAIN_1_0:
// parse 1.0 socket binding group
this.parseSocketBindingGroup_1_0(reader, interfaces, address, expectedNs, list);
break;
case DOMAIN_1_1:
case DOMAIN_1_2:
// parse 1.1 socket binding group
this.parseSocketBindingGroup_1_1(reader, interfaces, address, expectedNs, list);
break;
default:
unexpectedElement(reader);
}
break;
}
default: {
throw unexpectedElement(reader);
}
}
}
}
There should not be a case for 1.1 and 1.2 of the schema, at the very top level when parsing began we have already confirmed that the schema is one of 1.0, 1.1 or 1.2 before this method is even called.
We do not support switching schema versions in a single document so the call requireNamespace(reader, expectedNs) has verified that the version has not changed - in this method both 1.1 and 1.2 can be handled as default. We only need to handle a list of versions like this once a new parseSocketBindingGroup_1_ method is added - at that point we will list the versions that match 1_1 and the newest will go to default.
The reason this is important is as it stands every time the schema version is incremented this method is going to need to be modified to keep adding new schema versions even if it is not affected by the updates.
--
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
14 years, 1 month
[JBoss JIRA] (JBPORTAL-2489) Site Import/Export Error
by Biljana Kramer (JIRA)
Biljana Kramer created JBPORTAL-2489:
----------------------------------------
Summary: Site Import/Export Error
Key: JBPORTAL-2489
URL: https://issues.jboss.org/browse/JBPORTAL-2489
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Portal WSRP
Environment: JBoss Enterprise Portal Platform 5.2
Reporter: Biljana Kramer
Assignee: Chris Laprun
When I try to export a site that contains pages with WSRP portlet, it fails with the following exception:
Caused by: org.gatein.management.api.binding.BindingException: javax.xml.stream.XMLStreamException: WSRP portlet marshalling not supported.
at org.exoplatform.portal.mop.management.binding.xml.PageMarshaller.marshal(PageMarshaller.java:75)
at org.exoplatform.portal.mop.management.binding.xml.PageMarshaller.marshal(PageMarshaller.java:49)
at org.exoplatform.portal.mop.management.exportimport.PageExportTask.export(PageExportTask.java:77)
at org.gatein.management.core.api.binding.zip.ExportResourceModelMarshaller.marshal(ExportResourceModelMarshaller.java:78)
... 28 more
Caused by: javax.xml.stream.XMLStreamException: WSRP portlet marshalling not supported.
at org.exoplatform.portal.mop.management.binding.xml.AbstractMarshaller.marshalModelObject(AbstractMarshaller.java:79)
at org.exoplatform.portal.mop.management.binding.xml.PageMarshaller.marshalPage(PageMarshaller.java:145)
at org.exoplatform.portal.mop.management.binding.xml.PageMarshaller.marshal(PageMarshaller.java:64)
... 31 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
14 years, 1 month
[JBoss JIRA] (AS7-4192) Shutdown HC/DC result unpredictable
by Heiko Rupp (JIRA)
Heiko Rupp created AS7-4192:
-------------------------------
Summary: Shutdown HC/DC result unpredictable
Key: AS7-4192
URL: https://issues.jboss.org/browse/AS7-4192
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Affects Versions: 7.1.1.Final
Reporter: Heiko Rupp
Assignee: Brian Stansberry
Issuing the /host=foo:shutdown operation sometimes returns a success result and sometimes
Operation <Operation{operation='shutdown', address=Address{path: host=master}, additionalProperties={}}> returned <"Socket closed","rolled-back":false,"response-headers":null,"result":null,"success":false,"throwable":null,"failureDescription":"Socket closed, rolled-back=false","responseHeaders":null,"outcome":"failure","rolledBack":false}>
This seems to have to do with the timing of the shutdown of the managed servers
--
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
14 years, 1 month
[JBoss JIRA] (AS7-4269) Binding failure when it occurs right after an unbind()
by Jeff Mesnil (JIRA)
Jeff Mesnil created AS7-4269:
--------------------------------
Summary: Binding failure when it occurs right after an unbind()
Key: AS7-4269
URL: https://issues.jboss.org/browse/AS7-4269
Project: Application Server 7
Issue Type: Bug
Components: JMS
Affects Versions: 7.1.1.Final
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
When a JMS ConnectionFactory attribute is changed, HornetQ recreates the JNDI binding for the connection factory.
It does so by calling unbind()/bind() on its BindingRegistry SPI.
AS7BindingRegistry is implementing this interface. bind() creates a BinderService and unbind() stops it.
However unbind() implementation does not guarantee that the service is effectively removed when the method returns. If bind() is called right after that, it will fail to install a BinderService *with the same name* because there is already one in the state REMOVING.
--
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
14 years, 1 month