[JBoss JIRA] (WFLY-4589) java.lang.IllegalStateException: PBOX000048: Failed to obtain ApplicationPolicy for domain other
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4589?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-4589.
----------------------------
> java.lang.IllegalStateException: PBOX000048: Failed to obtain ApplicationPolicy for domain other
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-4589
> URL: https://issues.jboss.org/browse/WFLY-4589
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 9.0.0.CR1
> Environment: java version "1.8.0_25"
> Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
> cheffamille:wildfly-9.0.0.CR1 jfarcand$
> Reporter: Jeanfrancois Arcand
> Assignee: Stuart Douglas
> Priority: Minor
> Fix For: 10.0.0.Beta1
>
>
> Deploy atmosphere-chat.war (download it from Maven). Deploy, use WebSockets, then shutdown Wildfly 9.0.0.CR1
> 08:47:41,792 ERROR [io.undertow.websockets.jsr.request] (default task-17) UT026006: Exception running web socket method: java.lang.IllegalStateException: PBOX000048: Failed to obtain ApplicationPolicy for domain other
> at org.jboss.security.plugins.mapping.JBossMappingManager.getMappingContext(JBossMappingManager.java:67)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.setup(SecurityContextThreadSetupAction.java:110)
> at io.undertow.servlet.core.CompositeThreadSetupAction.setup(CompositeThreadSetupAction.java:42)
> at io.undertow.websockets.jsr.ServerWebSocketContainer.invokeEndpointMethod(ServerWebSocketContainer.java:416)
> at io.undertow.websockets.jsr.ServerWebSocketContainer$3.run(ServerWebSocketContainer.java:403)
> at io.undertow.websockets.jsr.OrderedExecutor$ExecutorTask.run(OrderedExecutor.java:67)
> 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)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (WFLY-5188) DistributedWorkManager needs to handle unknown fork responses.
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5188?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-5188.
----------------------------
> DistributedWorkManager needs to handle unknown fork responses.
> --------------------------------------------------------------
>
> Key: WFLY-5188
> URL: https://issues.jboss.org/browse/WFLY-5188
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, JCA
> Affects Versions: 10.0.0.Beta2
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 10.0.0.CR1
>
>
> The JGroupsTransport employed by the DistributedWorkManager uses synchronous multicasting via the RpcDispatcher. Since the JCA default configuration was modified to use fork channels, we need to ensure that it handles an exception case specific for fork channels, i.e. the case where a message is received by a node on which no such DWM exists.
> As I see it, there are 2 ways we can fix this:
> # Configure the RpcDispatcher with a custom response marshaller capable of recognizing unknown fork responses
> # Implement a transport that leverages CommandDispatcher, which already handles this exception case.
> #1 is the easiest. The only hiccup is that the RpcDispatcher field in JGroupsTransport is private, which requires reflection to access from a subclass.
> #2 is probably the ideal long term solution. The DistributedWorkManager already employs a command pattern, so using CommandDispatcher is a natural fit. Using the CommandDispatcher will also simplifies marshalling/unmarshalling of the transport parameters. Additionally, using the public clustering API allows us to remove the direct dependency on org.jgroups module from the connector subsystems. The only hiccup here is that in order to optimize the marshalling of the command objects, requires the use of the marshalling API introduced as part of WFLY-5091, which, at the time of this writing, has not yet been merged into WF master.
> Given the above, I suggest a 2 phase solution, where we implement #1 for now, and #2 when the missing pieces are in place.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[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)
7 years, 1 month
[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)
7 years, 1 month
[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)
7 years, 1 month
[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)
7 years, 1 month