[JBoss JIRA] (WFLY-4723) Make jgroups protocols support indexed adds
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4723?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-4723.
----------------------------
> Make jgroups protocols support indexed adds
> -------------------------------------------
>
> Key: WFLY-4723
> URL: https://issues.jboss.org/browse/WFLY-4723
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 10.0.0.Alpha3
>
>
> With the work done on WFCORE-401 it is important that if a protocol is added to a master that it appears in the correct location on the slave when the slave reconnects. This is made possible by the indexed adds introduced by WFCORE-598. If not set up as ordered children, a new protocol added to the middle of a stack would appear at the end, which is not what we want
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-5187) Standalone client fails to connect through remote connection factory over ipv6
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5187?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-5187.
----------------------------
> Standalone client fails to connect through remote connection factory over ipv6
> ------------------------------------------------------------------------------
>
> Key: WFLY-5187
> URL: https://issues.jboss.org/browse/WFLY-5187
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Beta1
> Reporter: Martin Švehla
> Assignee: Jeff Mesnil
> Fix For: 10.0.0.CR1
>
>
> When a standalone client connects to EAP over ipv6 and tries to do lookup on for RemoteConnectionFactory (as defined in the default standalone-full and standalone-full-ha configuration), the lookup fails with following error:
> Caused by: java.io.InvalidObjectException: URLDecoder: Illegal hex characters in escape (%) pattern - For input string: "et"
> at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.readExternal(ActiveMQConnectionFactory.java:117)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1308)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.jboss.naming.remote.protocol.v1.Protocol$1$3.read(Protocol.java:156)
> at org.jboss.naming.remote.protocol.v1.Protocol$1$3.read(Protocol.java:149)
> at org.jboss.naming.remote.protocol.v1.BaseProtocolCommand.readResult(BaseProtocolCommand.java:59)
> at org.jboss.naming.remote.protocol.v1.Protocol$1.handleClientMessage(Protocol.java:149)
> at org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1$MessageReceiver$1.run(RemoteNamingStoreV1.java:232)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.jboss.marshalling.TraceInformation: null
> You can reproduce the issue by running org.jboss.as.test.smoke.messaging.client.jms.JmsClientTestCase.testSendAndReceive from upstream testsuite.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-5184) Read-attribute on an EJB timer fails if there are no more timeouts
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5184?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-5184.
----------------------------
> Read-attribute on an EJB timer fails if there are no more timeouts
> ------------------------------------------------------------------
>
> Key: WFLY-5184
> URL: https://issues.jboss.org/browse/WFLY-5184
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Beta2
> Reporter: Jan Martiska
> Assignee: Jan Martiska
> Fix For: 10.0.0.CR1
>
>
> When a read-attribute operation is invoked on an EJB timer that has no timeouts remaining, the operation fails without returning any useful information to the client:
> {noformat}
> {
> "outcome" : "failed",
> "rolled-back" : true
> }
> {noformat}
> It is because a NoMoreTimeoutException is thrown from the TimerServiceImpl and this exception is not handled by the read-attribute handler. This occurs in the server log:
> {noformat}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("deployment" => "ejb-mgmt-timers.jar"),
> ("subsystem" => "ejb3"),
> ("stateless-session-bean" => "TimerBean"),
> ("service" => "timer-service"),
> ("timer" => "9a93b559-3526-4b72-95e7-760c5bc50484")
> ]): javax.ejb.NoMoreTimeoutsException: WFLYEJB0328: No more timeouts for timer [id=9a93b559-3526-4b72-95e7-760c5bc50484 timedObjectId=ejb-mgmt-timers.ejb-mgmt-timers.TimerBean auto-timer?:false persistent?:true timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@72e447ae initialExpiration=Mon Aug 24 13:38:37 CEST 2015 intervalDuration(in milli sec)=0 nextExpiration=null timerState=IN_TIMEOUT info=PersistentIntervalTimerCLITestCase]
> at org.jboss.as.ejb3.timerservice.TimerImpl.getNextTimeout(TimerImpl.java:256)
> at org.jboss.as.ejb3.subsystem.deployment.TimerResourceDefinition$6.readAttribute(TimerResourceDefinition.java:240)
> at org.jboss.as.ejb3.subsystem.deployment.TimerResourceDefinition$AbstractReadAttributeHandler.executeRuntime(TimerResourceDefinition.java:376)
> at org.jboss.as.ejb3.subsystem.deployment.TimerResourceDefinition$AbstractTimerHandler$1.execute(TimerResourceDefinition.java:340)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:846)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:637)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:362)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1272)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:394)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:225)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:207)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:129)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:151)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:147)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:147)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:298)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}
> I think the read-attribute handler should rather catch this exception, log it, and leave the next-timeout and time-remaining attributes undefined in this case.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-5123) Execution error: org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5123?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-5123.
----------------------------
> Execution error: org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-5123
> URL: https://issues.jboss.org/browse/WFLY-5123
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Alpha6, 10.0.0.Beta1
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
> Fix For: 10.0.0.CR1
>
>
> Seen regularly in basically every failover test (no matter what failover type/cache used).
> Setup: 4 node cluster, one node at time is shutdown, while standalone clients keep calling the application.
> After failing one node(failover type: jvmkill/shutdown/undeploy) - perf20 in this case, perf21 logged the following error message:
> {code}
> [JBossINF] [0m[31m12:57:35,029 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (transport-thread--p7-t10) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology 20
> [JBossINF] at org.infinispan.statetransfer.StateTransferLockImpl.waitForTransactionData(StateTransferLockImpl.java:92)
> [JBossINF] at org.infinispan.interceptors.base.BaseStateTransferInterceptor.waitForTransactionData(BaseStateTransferInterceptor.java:96)
> [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:274)
> [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:243)
> [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:119)
> [JBossINF] at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:209)
> [JBossINF] at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> [JBossINF] at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> [JBossINF] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> [JBossINF] at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1613)
> [JBossINF] at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:579)
> [JBossINF] at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:572)
> [JBossINF] at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:442)
> [JBossINF] at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:297)
> [JBossINF] at org.wildfly.clustering.server.registry.CacheRegistry.topologyChanged(CacheRegistry.java:152)
> [JBossINF] at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
> [JBossINF] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [JBossINF] at java.lang.reflect.Method.invoke(Method.java:497)
> [JBossINF] at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> [JBossINF] at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> [JBossINF] at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> [JBossINF] at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1212)
> [JBossINF] at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1170)
> [JBossINF] at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1135)
> [JBossINF] at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyTopologyChanged(CacheNotifierImpl.java:590)
> [JBossINF] at org.infinispan.statetransfer.StateTransferManagerImpl.doTopologyUpdate(StateTransferManagerImpl.java:203)
> [JBossINF] at org.infinispan.statetransfer.StateTransferManagerImpl.access$000(StateTransferManagerImpl.java:47)
> [JBossINF] at org.infinispan.statetransfer.StateTransferManagerImpl$1.updateConsistentHash(StateTransferManagerImpl.java:115)
> [JBossINF] at org.infinispan.topology.LocalTopologyManagerImpl.doHandleTopologyUpdate(LocalTopologyManagerImpl.java:282)
> [JBossINF] at org.infinispan.topology.LocalTopologyManagerImpl$1.run(LocalTopologyManagerImpl.java:217)
> [JBossINF] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] at org.infinispan.executors.SemaphoreCompletionService$QueueingTask.runInternal(SemaphoreCompletionService.java:173)
> [JBossINF] at org.infinispan.executors.SemaphoreCompletionService$QueueingTask.run(SemaphoreCompletionService.java:151)
> [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)
> [JBossINF]
> {code}
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
> This error sometimes occur just before the server shuts down, as can be seen here:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
> See also: [JBEAP-505#comment-13098103|https://issues.jboss.org/browse/JBEAP-505?focu...]
> This issue is also related to: [WFLY-4697#comment-13083024|https://issues.jboss.org/browse/WFLY-4697?focu...]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months