[JBoss JIRA] (ISPN-8240) Coordinator sends REBALANCE_START command when there is already a rebalance in progress
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-8240?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-8240:
-------------------------------
Sprint: DataGrid Sprint #30
> Coordinator sends REBALANCE_START command when there is already a rebalance in progress
> ---------------------------------------------------------------------------------------
>
> Key: ISPN-8240
> URL: https://issues.jboss.org/browse/ISPN-8240
> Project: Infinispan
> Issue Type: Bug
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
>
> Normally the {{REBALANCE_START}} command should only be sent at the start of a rebalance, and any topology updates sent before all the nodes confirm the rebalance phase should have {{CH_UPDATE}}.
> Since the change to 4 phases, this is no longer true: first {{ClusterCacheStatus.updateTopologyMembers}} first clears the {{RebalanceConfirmationCollector}}, then it broadcasts a {{CH_UPDATE}}. Then {{queueRebalance}} immediately creates a new {{RCC}} and broadcasts a {{REBALANCE_START}}, instead of waiting for the current rebalance to finish.
> I propose we remove {{REBALANCE_START}}, as it was just a crude version of {{CacheTopology.Phase}}. We should also remove the {{isRebalance}} parameter from {{StateConsumerImpl.onTopologyUpdate()}}.
> I'm still not sure if rebalancing the pending CH immediately is ok. On the one hand, I would like the rebalance to finish with {{updateMembers(union(currentCH, pendingCH))}} as the new pending CH, so that segments that were already transferred keep an extra copy. On the other hand, that would only help for segments that have at least on owner in the current CH: if the current CH has 0 owners and {{updateMembers}} allocates new ones, those new owners won't request data from the pending CH owners anyway. Fixing that case would require the coordinator to fetch the transfer status from all the nodes before removing a node from the topology. But if the coordinator knew exactly which segments were transferred, it could finish the rebalance immediately and start a new one -- so it would be more similar to the current approach.
> Note: the {{SyncConsistentHashFactory}} allocation is not 100% stable, even when nodes are not added, so A ∈ owners(segment) in topology ABCD does not guarantee that A ∈ owners(segment) in topology ABC. But it should be good enough to keep A an owner in 90% of the cases.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 10 months
[JBoss JIRA] (ISPN-7407) Investigate flow control performance
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-7407?page=com.atlassian.jira.plugin.... ]
Dan Berindei resolved ISPN-7407.
--------------------------------
Fix Version/s: 10.0.0.Beta4
Resolution: Done
An experiment with {{UFC max_credits="8m"}} showed performance improvements.
Switching to {{UFC_NB max_credits="2m"}} reduced performance, but increasing {{max_credits}} from 2m to 3m got us back to the {{UFC max_credits="2m"}} throughput.
> Investigate flow control performance
> ------------------------------------
>
> Key: ISPN-7407
> URL: https://issues.jboss.org/browse/ISPN-7407
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 9.0.0.Beta2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Beta4
>
>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 10 months
[JBoss JIRA] (ISPN-7092) Failed to broadcast asynchronous command
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-7092?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-7092:
-------------------------------
Fix Version/s: 10.0.0.Beta4
Sprint: DataGrid Sprint #30
{{CacheTopologyControlCommand}} should not log exceptions, {{GlobalInboundInvocationHandler}} already logs them and properly ignores {{IllegalLifecycleStateException}}
> Failed to broadcast asynchronous command
> ----------------------------------------
>
> Key: ISPN-7092
> URL: https://issues.jboss.org/browse/ISPN-7092
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.2.4.Final
> Reporter: Radoslav Husar
> Assignee: Dan Berindei
> Priority: Minor
> Labels: infinispan_clean_shutdown
> Fix For: 10.0.0.Beta4
>
>
> Occured on server at the end of server stopping.
> Scenarios affected:
> eap-7x-failover-ejb-ejbremote-jvmkill-dist-sync
> eap-7x-failover-ejb-ejbremote-jvmkill-repl-async
> eap-7x-failover-ejb-ejbremote-jvmkill-repl-sync
> eap-7x-failover-ejb-ejbremote-shutdown-dist-async
> eap-7x-failover-ejb-ejbremote-shutdown-dist-sync-tcpStack
> eap-7x-failover-ejb-ejbremote-shutdown-repl-sync
> eap-7x-failover-ejb-ejbremote-undeploy-repl-sync
> eap-7x-failover-ejb-ejbservlet-shutdown-repl-async
> eap-7x-failover-ejb-ejbstateless-jvmkill-repl-async
> eap-7x-failover-http-granular-shutdown-repl-sync
> eap-7x-failover-http-session-shutdown-repl-async
> eap-7x-failover-http-session-shutdown-repl-async-tcpStack
> eap-7x-failover-http-session-shutdown-repl-sync
> eap-7x-failover-jvmkill-ha-ss
> WARN message has two variants.
> *Variant 1*:
> {code}
> 15:01:15,157 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000080: Disconnecting JGroups channel web
> [JBossINF] [0m[0m15:01:15,157 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000082: Stopping the RpcDispatcher for channel web
> [JBossINF] [0m[0m15:01:15,158 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-3) WFLYJCA0019: Stopped Driver service with driver-name = h2
> [JBossINF] [0m[33m15:01:15,158 WARN [org.infinispan.topology.CacheTopologyControlCommand] (remote-thread--p7-t13) ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=clusterbench-ee7.ear.clusterbench-ee7-web-default.war, type=REBALANCE_CONFIRM, sender=dev214, joinInfo=null, topologyId=35, rebalanceId=0, currentCH=null, pendingCH=null, availabilityMode=null, actualMembers=null, throwable=null, viewId=12}: org.infinispan.commons.CacheException: Failed to broadcast asynchronous command: CacheTopologyControlCommand{cache=clusterbench-ee7.ear.clusterbench-ee7-web-default.war, type=STABLE_TOPOLOGY_UPDATE, sender=dev213, joinInfo=null, topologyId=36, rebalanceId=17, currentCH=DefaultConsistentHash{ns=256, owners = (2)[dev214: 124+132, dev215: 132+124]}, pendingCH=null, availabilityMode=null, actualMembers=[dev214, dev215], throwable=null, viewId=12}
> [JBossINF] at org.infinispan.topology.ClusterTopologyManagerImpl.executeOnClusterAsync(ClusterTopologyManagerImpl.java:595)
> [JBossINF] at org.infinispan.topology.ClusterTopologyManagerImpl.broadcastStableTopologyUpdate(ClusterTopologyManagerImpl.java:615)
> [JBossINF] at org.infinispan.topology.ClusterCacheStatus.startQueuedRebalance(ClusterCacheStatus.java:633)
> [JBossINF] at org.infinispan.topology.ClusterCacheStatus.endRebalance(ClusterCacheStatus.java:373)
> [JBossINF] at org.infinispan.topology.ClusterCacheStatus.doConfirmRebalance(ClusterCacheStatus.java:310)
> [JBossINF] at org.infinispan.topology.ClusterTopologyManagerImpl.handleRebalanceCompleted(ClusterTopologyManagerImpl.java:263)
> [JBossINF] at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:176)
> [JBossINF] at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:153)
> [JBossINF] at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler$2.run(GlobalInboundInvocationHandler.java:159)
> [JBossINF] at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl$RunnableWrapper.run(BlockingTaskAwareExecutorServiceImpl.java:199)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at org.jboss.as.clustering.infinispan.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:48)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> [JBossINF] Caused by: org.infinispan.commons.CacheException: java.lang.IllegalStateException: channel is not connected
> [JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.rethrowAsCacheException(CommandAwareRpcDispatcher.java:158)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommands(CommandAwareRpcDispatcher.java:138)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotelyAsync(JGroupsTransport.java:578)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:532)
> [JBossINF] at org.infinispan.topology.ClusterTopologyManagerImpl.executeOnClusterAsync(ClusterTopologyManagerImpl.java:592)
> [JBossINF] ... 13 more
> [JBossINF] Caused by: java.lang.IllegalStateException: channel is not connected
> [JBossINF] at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:682)
> [JBossINF] at org.jgroups.blocks.RequestCorrelator.sendRequest(RequestCorrelator.java:172)
> [JBossINF] at org.jgroups.blocks.GroupRequest.sendRequest(GroupRequest.java:325)
> [JBossINF] at org.jgroups.blocks.GroupRequest.sendRequest(GroupRequest.java:76)
> [JBossINF] at org.jgroups.blocks.Request.execute(Request.java:67)
> [JBossINF] at org.jgroups.blocks.MessageDispatcher.cast(MessageDispatcher.java:373)
> [JBossINF] at org.jgroups.blocks.MessageDispatcher.cast(MessageDispatcher.java:386)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processCalls(CommandAwareRpcDispatcher.java:407)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommands(CommandAwareRpcDispatcher.java:133)
> [JBossINF] ... 16 more
> {code}
> *Variant 2*:
> {code}
> 15:53:27,821 INFO [org.infinispan.CLUSTER] (remote-thread--p6-t19) ISPN000336: Finished cluster-wide rebalance for cache routing, topology id = 33
> [JBossINF] [0m[0m15:53:27,829 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-8) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS]
> [JBossINF] [0m[0m15:53:27,830 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000080: Disconnecting JGroups channel web
> [JBossINF] [0m[0m15:53:27,830 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000082: Stopping the RpcDispatcher for channel web
> [JBossINF] [0m[0m15:53:27,821 INFO [org.infinispan.CLUSTER] (remote-thread--p6-t14) ISPN000336: Finished cluster-wide rebalance for cache clusterbench-ee7.ear.clusterbench-ee7-web-default.war, topology id = 39
> [JBossINF] [0m[0m15:53:27,834 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-3) WFLYJCA0019: Stopped Driver service with driver-name = h2
> [JBossINF] [0m[33m15:53:27,832 WARN [org.infinispan.topology.CacheTopologyControlCommand] (remote-thread--p6-t14) ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=clusterbench-ee7.ear.clusterbench-ee7-web-default.war, type=REBALANCE_CONFIRM, sender=dev215, joinInfo=null, topologyId=39, rebalanceId=0, currentCH=null, pendingCH=null, availabilityMode=null, actualMembers=null, throwable=null, viewId=12}: org.infinispan.commons.CacheException: Failed to broadcast asynchronous command: CacheTopologyControlCommand{cache=clusterbench-ee7.ear.clusterbench-ee7-web-default.war, type=CH_UPDATE, sender=dev213, joinInfo=null, topologyId=40, rebalanceId=21, currentCH=DefaultConsistentHash{ns=256, owners = (2)[dev214: 129+127, dev215: 127+129]}, pendingCH=null, availabilityMode=null, actualMembers=[dev214, dev215], throwable=null, viewId=12}
> [JBossINF] at org.infinispan.topology.ClusterTopologyManagerImpl.executeOnClusterAsync(ClusterTopologyManagerImpl.java:595)
> [JBossINF] at org.infinispan.topology.ClusterTopologyManagerImpl.broadcastTopologyUpdate(ClusterTopologyManagerImpl.java:606)
> [JBossINF] at org.infinispan.topology.ClusterCacheStatus.endRebalance(ClusterCacheStatus.java:369)
> [JBossINF] at org.infinispan.topology.ClusterCacheStatus.doConfirmRebalance(ClusterCacheStatus.java:310)
> [JBossINF] at org.infinispan.topology.ClusterTopologyManagerImpl.handleRebalanceCompleted(ClusterTopologyManagerImpl.java:263)
> [JBossINF] at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:176)
> [JBossINF] at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:153)
> [JBossINF] at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler$2.run(GlobalInboundInvocationHandler.java:159)
> [JBossINF] at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl$RunnableWrapper.run(BlockingTaskAwareExecutorServiceImpl.java:199)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at org.jboss.as.clustering.infinispan.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:48)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> [JBossINF] Caused by: java.lang.NullPointerException
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotelyAsync(JGroupsTransport.java:611)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:532)
> [JBossINF] at org.infinispan.topology.ClusterTopologyManagerImpl.executeOnClusterAsync(ClusterTopologyManagerImpl.java:592)
> [JBossINF] ... 12 more
> {code}
> Link to server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 10 months
[JBoss JIRA] (ISPN-7554) JGroupsTransport should expose the cluster view information atomically
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-7554?page=com.atlassian.jira.plugin.... ]
Dan Berindei resolved ISPN-7554.
--------------------------------
Fix Version/s: 9.1.0.Final
Resolution: Done
Fixed with ISPN-6971
> JGroupsTransport should expose the cluster view information atomically
> ----------------------------------------------------------------------
>
> Key: ISPN-7554
> URL: https://issues.jboss.org/browse/ISPN-7554
> Project: Infinispan
> Issue Type: Bug
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 9.1.0.Final
>
>
> Currently the view is updated while holding a lock, but reading the view id, members, or coordinator is done without a lock. This means when a thread sends a request and receives a {{SuspectException}}, it cannot simply wait for a new view before retrying: the initial request may have used the latest view, and only the members list could be outdated (even if read later).
> To allow atomically reading the view id and the member list, we should use an immutable structure similar to {{CacheTopology}}.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 10 months
[JBoss JIRA] (ISPN-9345) TimeutException involving the org.infinispan.CONFIG cache with IPv6
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-9345?page=com.atlassian.jira.plugin.... ]
Dan Berindei resolved ISPN-9345.
--------------------------------
Fix Version/s: 10.0.0.Beta4
Resolution: Done
JGroups changed the algorithm for picking the stack type with JGRP-2305 and then JGRP-2343, so it defaults to IPv4 unless the user explicitly configured an IPv6 address.
> TimeutException involving the org.infinispan.CONFIG cache with IPv6
> -------------------------------------------------------------------
>
> Key: ISPN-9345
> URL: https://issues.jboss.org/browse/ISPN-9345
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.3.0.Final
> Reporter: Gustavo Fernandes
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Beta4
>
>
> {noformat}
> Caused by: org.infinispan.commons.CacheException: Initial state transfer timed out for cache org.infinispan.CONFIG on jedha-64980
> at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:233)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.infinispan.commons.util.SecurityActions.lambda$invokeAccessibly$0(SecurityActions.java:79)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 10 months
[JBoss JIRA] (ISPN-9482) Authorization exceptions are never sent to the client if access logging is enabled
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-9482?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-9482:
-------------------------------
Sprint: DataGrid Sprint #30
> Authorization exceptions are never sent to the client if access logging is enabled
> ----------------------------------------------------------------------------------
>
> Key: ISPN-9482
> URL: https://issues.jboss.org/browse/ISPN-9482
> Project: Infinispan
> Issue Type: Bug
> Components: Server, Test Suite - Server
> Affects Versions: 9.4.0.CR1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
>
> I've noticed the problem when running {{AuthenticationTest.testAuthenticationFailNoAuth}} with trace logging enabled. The server never sends the authorization exception to the client because logging the exception also performs a security check.
> On the server side, Netty logs an unhandled exception:
> {noformat}
> 19:43:22,617 DEBUG (HotRod-ServerIO-3-1) [BaseDecoder] Exception caught
> io.netty.handler.codec.DecoderException: java.lang.SecurityException: ISPN006017: Unauthorized operation
> at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:459) ~[netty-codec-4.1.22.Final.jar:4.1.22.Final]
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:265) ~[netty-codec-4.1.22.Final.jar:4.1.22.Final]
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362) [netty-transport-4.1.22.Final.jar:4.1.22.Final]
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) [netty-transport-4.1.22.Final.jar:4.1.22.Final]
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340) [netty-transport-4.1.22.Final.jar:4.1.22.Final]
> at io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86) [netty-transport-4.1.22.Final.jar:4.1.22.Final]
> at org.infinispan.server.core.transport.StatsChannelHandler.channelRead(StatsChannelHandler.java:26) [classes/:?]
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362) [netty-transport-4.1.22.Final.jar:4.1.22.Final]
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) [netty-transport-4.1.22.Final.jar:4.1.22.Final]
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340) [netty-transport-4.1.22.Final.jar:4.1.22.Final]
> at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1414) [netty-transport-4.1.22.Final.jar:4.1.22.Final]
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362) [netty-transport-4.1.22.Final.jar:4.1.22.Final]
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) [netty-transport-4.1.22.Final.jar:4.1.22.Final]
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:945) [netty-transport-4.1.22.Final.jar:4.1.22.Final]
> at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:806) [netty-transport-native-epoll-4.1.22.Final-linux-x86_64.jar:4.1.22.Final]
> at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:404) [netty-transport-native-epoll-4.1.22.Final-linux-x86_64.jar:4.1.22.Final]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:304) [netty-transport-native-epoll-4.1.22.Final-linux-x86_64.jar:4.1.22.Final]
> at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:886) [netty-common-4.1.22.Final.jar:4.1.22.Final]
> at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) [netty-common-4.1.22.Final.jar:4.1.22.Final]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_171]
> Caused by: java.lang.SecurityException: ISPN006017: Unauthorized operation
> at org.infinispan.server.hotrod.Authentication.getSubject(Authentication.java:152) ~[classes/:?]
> at org.infinispan.server.hotrod.HotRodDecoder.getHeader(HotRodDecoder.java:133) ~[classes/:?]
> at org.infinispan.server.hotrod.HotRodDecoder.exceptionally(HotRodDecoder.java:3327) ~[classes/:?]
> at org.infinispan.server.hotrod.HotRodDecoder.decode(HotRodDecoder.java:145) ~[classes/:?]
> at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:489) ~[netty-codec-4.1.22.Final.jar:4.1.22.Final]
> at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:428) ~[netty-codec-4.1.22.Final.jar:4.1.22.Final]
> ... 19 more
> {noformat}
> On the client side, nothing is received, and the test eventually times out:
> {noformat}
> 19:43:25,192 ERROR (testng-Test) [TestSuiteProgress] Test failed: org.infinispan.client.hotrod.AuthenticationTest.testAuthenticationFailNoAuth
> org.infinispan.client.hotrod.exceptions.TransportException: java.net.SocketTimeoutException: PutOperation{(default), key=[B0x033E0161, value=[B0x033E0161, flags=6} timed out after 3000 ms
> at org.infinispan.client.hotrod.impl.Util.rewrap(Util.java:54) ~[classes/:?]
> at org.infinispan.client.hotrod.impl.Util.await(Util.java:27) ~[classes/:?]
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:264) ~[classes/:?]
> at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79) ~[classes/:?]
> at org.infinispan.client.hotrod.AuthenticationTest.testAuthenticationFailNoAuth(AuthenticationTest.java:71) ~[test-classes/:?]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_171]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_171]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_171]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_171]
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85) ~[testng-6.9.9.jar:?]
> at org.testng.internal.MethodInvocationHelper$1.runTestMethod(MethodInvocationHelper.java:196) ~[testng-6.9.9.jar:?]
> at org.infinispan.commons.test.TestNGLongTestsHook.run(TestNGLongTestsHook.java:24) ~[classes/:?]
> at org.testng.internal.MethodInvocationHelper.invokeHookable(MethodInvocationHelper.java:208) ~[testng-6.9.9.jar:?]
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:635) [testng-6.9.9.jar:?]
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:816) [testng-6.9.9.jar:?]
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1124) [testng-6.9.9.jar:?]
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) [testng-6.9.9.jar:?]
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108) [testng-6.9.9.jar:?]
> at org.testng.TestRunner.privateRun(TestRunner.java:774) [testng-6.9.9.jar:?]
> at org.testng.TestRunner.run(TestRunner.java:624) [testng-6.9.9.jar:?]
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:359) [testng-6.9.9.jar:?]
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:354) [testng-6.9.9.jar:?]
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:312) [testng-6.9.9.jar:?]
> at org.testng.SuiteRunner.run(SuiteRunner.java:261) [testng-6.9.9.jar:?]
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) [testng-6.9.9.jar:?]
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) [testng-6.9.9.jar:?]
> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1215) [testng-6.9.9.jar:?]
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1140) [testng-6.9.9.jar:?]
> at org.testng.TestNG.run(TestNG.java:1048) [testng-6.9.9.jar:?]
> at org.testng.IDEARemoteTestNG.run(IDEARemoteTestNG.java:72) [testng-plugin.jar:?]
> at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:123) [testng-plugin.jar:?]
> Caused by: java.net.SocketTimeoutException: PutOperation{(default), key=[B0x033E0161, value=[B0x033E0161, flags=6} timed out after 3000 ms
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.run(HotRodOperation.java:172) ~[classes/:?]
> at io.netty.util.concurrent.PromiseTask$RunnableAdapter.call(PromiseTask.java:38) ~[netty-common-4.1.22.Final.jar:4.1.22.Final]
> at io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:125) ~[netty-common-4.1.22.Final.jar:4.1.22.Final]
> at io.netty.util.concurrent.AbstractEventExecutor.safeExecute$$$capture(AbstractEventExecutor.java:163) ~[netty-common-4.1.22.Final.jar:4.1.22.Final]
> at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java) ~[netty-common-4.1.22.Final.jar:4.1.22.Final]
> at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:404) ~[netty-common-4.1.22.Final.jar:4.1.22.Final]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:309) ~[netty-transport-native-epoll-4.1.22.Final-linux-x86_64.jar:4.1.22.Final]
> at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:886) ~[netty-common-4.1.22.Final.jar:4.1.22.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[?:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[?:1.8.0_171]
> at java.lang.Thread.run(Thread.java:748) ~[?:1.8.0_171]
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 10 months
[JBoss JIRA] (ISPN-9761) Cannot wire or start components while the registry is not running
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-9761?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-9761:
-------------------------------
Sprint: DataGrid Sprint #30
> Cannot wire or start components while the registry is not running
> ------------------------------------------------------------------
>
> Key: ISPN-9761
> URL: https://issues.jboss.org/browse/ISPN-9761
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.4.1.Final
> Reporter: Radoslav Husar
> Assignee: Dan Berindei
> Priority: Major
>
> Looks like yet another clean shutdown issue surfaced after we changed WFLY-11324 to avoid some graceful shutdown bugs with the XA transaction table.
> {noformat}
> 16:28:38,874 ERROR [org.infinispan.commons.tx.TransactionImpl] (default task-2) ISPN000926: afterCompletion() failed for SynchronizationAdapter{localTransaction=LocalTransaction{remoteLockedNodes=[node-1, node-2], isMarkedForRollback=false, lockedKeys=[], backupKeyLocks=[SessionAccessMetaDataKey(2sYbjnFh2n-m_gkaOP2iz53e0ms4cbuARoeIdYJ5), SessionCreationMetaDataKey(2sYbjnFh2n-m_gkaOP2iz53e0ms4cbuARoeIdYJ5), SessionAttributesKey(2sYbjnFh2n-m_gkaOP2iz53e0ms4cbuARoeIdYJ5)], topologyId=5, stateTransferFlag=null} org.infinispan.transaction.synchronization.SyncLocalTransaction@72} org.infinispan.transaction.synchronization.SynchronizationAdapter@91: org.infinispan.IllegalLifecycleStateException: Cannot wire or start components while the registry is not running
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.prepareWrapperChange(BasicComponentRegistryImpl.java:610)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.wireWrapper(BasicComponentRegistryImpl.java:158)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl$ComponentWrapper.wire(BasicComponentRegistryImpl.java:736)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl$ComponentWrapper.running(BasicComponentRegistryImpl.java:712)
> at org.infinispan.transaction.impl.TransactionCoordinator.commit(TransactionCoordinator.java:148)
> at org.infinispan.transaction.impl.TransactionTable.afterCompletion(TransactionTable.java:861)
> at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:33)
> at org.infinispan.commons.tx.TransactionImpl.notifyAfterCompletion(TransactionImpl.java:506)
> at org.infinispan.commons.tx.TransactionImpl.runCommit(TransactionImpl.java:338)
> at org.infinispan.commons.tx.TransactionImpl.commit(TransactionImpl.java:110)
> at org.wildfly.clustering.ee.infinispan.InfinispanBatch.close(InfinispanBatch.java:97)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:87)
> at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:945)
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:579)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:346)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 10 months
[JBoss JIRA] (ISPN-9787) Integration tests fail on the 8.2.x branch
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-9787?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-9787:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 8.2.12.Final
Resolution: Done
> Integration tests fail on the 8.2.x branch
> ------------------------------------------
>
> Key: ISPN-9787
> URL: https://issues.jboss.org/browse/ISPN-9787
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> Affects Versions: 8.2.11.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 8.2.12.Final
>
>
> The {{JAVA_HOME}} environment variable is missing:
> {noformat}
> java.lang.RuntimeException: Arquillian has previously been attempted initialized, but failed. See cause for previous exception
> Caused by: java.lang.RuntimeException: Could not create deployable configuration
> at org.infinispan.arquillian.core.InfinispanConfigurator.configureInfinispan(InfinispanConfigurator.java:119)
> Caused by: org.jboss.arquillian.container.spi.ConfigurationException: javaHome '${env.JAVA_HOME}' must exist
> at org.jboss.arquillian.container.spi.client.deployment.Validate.configurationDirectoryExists(Validate.java:139)
> at org.jboss.as.arquillian.container.DistributionContainerConfiguration.validate(DistributionContainerConfiguration.java:102)
> at org.jboss.as.arquillian.container.managed.ManagedContainerConfiguration.validate(ManagedContainerConfiguration.java:71)
> at org.jboss.arquillian.container.impl.ContainerImpl.createDeployableConfiguration(ContainerImpl.java:115)
> at org.infinispan.arquillian.core.InfinispanConfigurator.configureInfinispan(InfinispanConfigurator.java:95)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 10 months
[JBoss JIRA] (ISPN-10322) Create unified interface for initializing commands
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-10322?page=com.atlassian.jira.plugin... ]
Dan Berindei updated ISPN-10322:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Create unified interface for initializing commands
> --------------------------------------------------
>
> Key: ISPN-10322
> URL: https://issues.jboss.org/browse/ISPN-10322
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 10.0.0.Beta3
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 10.0.0.Beta4
>
>
> Currently we rely on CommandsFactoryImpl and ModuleCommandInitializer implementations to initiatilize commands once they have been received over the wire. However, currently we do this on a per method basis, resulting in commands having various initialisation naming schemes such as {{init}}, {{inject}} etc. We should provide a interface that can be implemented by commands that require initialization and utilise this method for all initialization.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 10 months