[JBoss JIRA] (ISPN-7359) Allow cache statuses to be retrieved by profile and at the container level
by Ryan Emerson (JIRA)
Ryan Emerson created ISPN-7359:
----------------------------------
Summary: Allow cache statuses to be retrieved by profile and at the container level
Key: ISPN-7359
URL: https://issues.jboss.org/browse/ISPN-7359
Project: Infinispan
Issue Type: Enhancement
Components: JMX, reporting and management, Server
Affects Versions: 9.0.0.Beta1
Reporter: Ryan Emerson
Assignee: Ryan Emerson
Currently to get the status of a cache, it's necessary to perform the following DMR request on a host/server that contains the cache:
`/host=master/server=server-one/subsystem=datagrid-infinispan/cache-container=container/distributed-cache=default:read-attribute(name=cache-availability)`
This is acceptable when the status of only a few cache's is required, however this can result in many management requests from the console etc if a container contains many cache's. Therefore we should expose a method at the profile level, that retrieves the status of all cache's within a given container. For example:
`profile=clustered/subsystem=datagrid-infinispan/cache-container=clustered:get-cache-statuses()`
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 11 months
[JBoss JIRA] (ISPN-7328) Administration console - cache statuses in cache container page behave randomly
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-7328?page=com.atlassian.jira.plugin.... ]
Ryan Emerson commented on ISPN-7328:
------------------------------------
[~vblagojevic] I definitely think the ideal approach is to implement something on the server side as you state. However, in the mean time we could potentially reduce the number of server server requests by utilising wildcards to get the status of all cache types across all containers and then filtering this on the client side e.g. call:
`/host=master/server=server-one/subsystem=datagrid-infinispan/cache-container=*/distributed-cache=*:read-attribute(name=cache-availability)`
and then process the results. This approach is complicated by the fact that we would have to ensure that we send requests to a host/server combo that is valid for a specific cache.
> Administration console - cache statuses in cache container page behave randomly
> -------------------------------------------------------------------------------
>
> Key: ISPN-7328
> URL: https://issues.jboss.org/browse/ISPN-7328
> Project: Infinispan
> Issue Type: Bug
> Components: Console
> Affects Versions: 9.0.0.Beta1
> Reporter: Jiří Holuša
> Assignee: Vladimir Blagojevic
> Priority: Minor
> Attachments: screenshot1.png
>
>
> Steps to reproduce: create more caches (in my case at least ~20), go to cache container and try to refresh the page several times. It should sometimes appear that some of the cache has yellow warning status, see attached screenshot.
> This occurs very randomly and only with more caches (and probably more servers). IMHO there is some kind of timeout issue that the console fails to retrieve statuses from all caches in time.
> I think the best solution would be to, when waiting for retrieving of the cache status, have instead of "warning" icon some kind of spinner which would basically signal "I haven't got the status yet". This would also solve a bit of user-unfriendliness, which is when you go to cache container, initially all the statuses are "warning" and then they change to "OK". This moment can time quite some time when there are more caches and can confuse users quite a bit.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 11 months
[JBoss JIRA] (ISPN-7328) Administration console - cache statuses in cache container page behave randomly
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-7328?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic commented on ISPN-7328:
-------------------------------------------
I looked at this issue, tried quick and naive options but did not get too far. I think we'll need to introduce some random backoff timer to fire a DMR check status call for each cache. Hopefully, that will not overwhelm the server as much as current approach seems to be. However, the ultimate and long-term solution for this issue appears to be adding a container level call for cache statuses that will, in one swoop, return statuses for all container caches. We can then keep random time bounded timer that will fire and update status for all/individual caches real time. Thoughts [~pzapataf] [~ryanemerson]?
> Administration console - cache statuses in cache container page behave randomly
> -------------------------------------------------------------------------------
>
> Key: ISPN-7328
> URL: https://issues.jboss.org/browse/ISPN-7328
> Project: Infinispan
> Issue Type: Bug
> Components: Console
> Affects Versions: 9.0.0.Beta1
> Reporter: Jiří Holuša
> Assignee: Vladimir Blagojevic
> Priority: Minor
> Attachments: screenshot1.png
>
>
> Steps to reproduce: create more caches (in my case at least ~20), go to cache container and try to refresh the page several times. It should sometimes appear that some of the cache has yellow warning status, see attached screenshot.
> This occurs very randomly and only with more caches (and probably more servers). IMHO there is some kind of timeout issue that the console fails to retrieve statuses from all caches in time.
> I think the best solution would be to, when waiting for retrieving of the cache status, have instead of "warning" icon some kind of spinner which would basically signal "I haven't got the status yet". This would also solve a bit of user-unfriendliness, which is when you go to cache container, initially all the statuses are "warning" and then they change to "OK". This moment can time quite some time when there are more caches and can confuse users quite a bit.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 11 months
[JBoss JIRA] (ISPN-7358) Hot Rod server not dealing with pipe requests properly
by Galder Zamarreño (JIRA)
Galder Zamarreño created ISPN-7358:
--------------------------------------
Summary: Hot Rod server not dealing with pipe requests properly
Key: ISPN-7358
URL: https://issues.jboss.org/browse/ISPN-7358
Project: Infinispan
Issue Type: Bug
Components: Remote Protocols
Affects Versions: 8.2.5.Final, 9.0.0.Beta1
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Priority: Blocker
Fix For: 9.0.0.Beta2, 9.0.0.Final
This might not become so apparent with the current synchronous Java client, but with fully asynchronous clients such as the Javascript one, multiple requests can be piped one after the other.
Hot Rod server does not often deal with those well, showing exceptions such as:
{code}
org.infinispan.server.hotrod.InvalidMagicIdException: Error reading magic byte or message id: 119
{code}
{code}
org.infinispan.server.hotrod.UnknownVersionException: Unknown version:-96
{code}
This exceptions appear when applying considerable load with the Javascript client (see HRJS-24), but the same effect can be replicated with a Netty based, fully asynchronous client, such as the simplified version used [here|https://gist.github.com/galderz/94705dd73d5339b1ab5aa0a5157a9803].
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 11 months
[JBoss JIRA] (ISPN-7358) Hot Rod server not dealing with pipe requests properly
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-7358?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-7358:
-----------------------------------
Description:
This might not become so apparent with the current synchronous Java client, but with fully asynchronous clients such as the Javascript one, multiple requests can be piped one after the other.
Hot Rod server does not often deal with those well, showing exceptions such as:
{code}
org.infinispan.server.hotrod.InvalidMagicIdException:
Error reading magic byte or message id: 119
{code}
{code}
org.infinispan.server.hotrod.UnknownVersionException:
Unknown version:-96
{code}
This exceptions appear when applying considerable load with the Javascript client (see HRJS-24), but the same effect can be replicated with a Netty based, fully asynchronous client, such as the simplified version used [here|https://gist.github.com/galderz/94705dd73d5339b1ab5aa0a5157a9803].
was:
This might not become so apparent with the current synchronous Java client, but with fully asynchronous clients such as the Javascript one, multiple requests can be piped one after the other.
Hot Rod server does not often deal with those well, showing exceptions such as:
{code}
org.infinispan.server.hotrod.InvalidMagicIdException: Error reading magic byte or message id: 119
{code}
{code}
org.infinispan.server.hotrod.UnknownVersionException: Unknown version:-96
{code}
This exceptions appear when applying considerable load with the Javascript client (see HRJS-24), but the same effect can be replicated with a Netty based, fully asynchronous client, such as the simplified version used [here|https://gist.github.com/galderz/94705dd73d5339b1ab5aa0a5157a9803].
> Hot Rod server not dealing with pipe requests properly
> ------------------------------------------------------
>
> Key: ISPN-7358
> URL: https://issues.jboss.org/browse/ISPN-7358
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 9.0.0.Beta1, 8.2.5.Final
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Priority: Blocker
> Fix For: 9.0.0.Beta2, 9.0.0.Final
>
>
> This might not become so apparent with the current synchronous Java client, but with fully asynchronous clients such as the Javascript one, multiple requests can be piped one after the other.
> Hot Rod server does not often deal with those well, showing exceptions such as:
> {code}
> org.infinispan.server.hotrod.InvalidMagicIdException:
> Error reading magic byte or message id: 119
> {code}
> {code}
> org.infinispan.server.hotrod.UnknownVersionException:
> Unknown version:-96
> {code}
> This exceptions appear when applying considerable load with the Javascript client (see HRJS-24), but the same effect can be replicated with a Netty based, fully asynchronous client, such as the simplified version used [here|https://gist.github.com/galderz/94705dd73d5339b1ab5aa0a5157a9803].
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 11 months
[JBoss JIRA] (ISPN-7358) Hot Rod server not dealing with pipe requests properly
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-7358?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-7358:
-----------------------------------
Status: Open (was: New)
> Hot Rod server not dealing with pipe requests properly
> ------------------------------------------------------
>
> Key: ISPN-7358
> URL: https://issues.jboss.org/browse/ISPN-7358
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 9.0.0.Beta1, 8.2.5.Final
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Priority: Blocker
> Fix For: 9.0.0.Beta2, 9.0.0.Final
>
>
> This might not become so apparent with the current synchronous Java client, but with fully asynchronous clients such as the Javascript one, multiple requests can be piped one after the other.
> Hot Rod server does not often deal with those well, showing exceptions such as:
> {code}
> org.infinispan.server.hotrod.InvalidMagicIdException:
> Error reading magic byte or message id: 119
> {code}
> {code}
> org.infinispan.server.hotrod.UnknownVersionException:
> Unknown version:-96
> {code}
> This exceptions appear when applying considerable load with the Javascript client (see HRJS-24), but the same effect can be replicated with a Netty based, fully asynchronous client, such as the simplified version used [here|https://gist.github.com/galderz/94705dd73d5339b1ab5aa0a5157a9803].
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 11 months
[JBoss JIRA] (ISPN-7358) Hot Rod server not dealing with pipe requests properly
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-7358?page=com.atlassian.jira.plugin.... ]
Work on ISPN-7358 started by Galder Zamarreño.
----------------------------------------------
> Hot Rod server not dealing with pipe requests properly
> ------------------------------------------------------
>
> Key: ISPN-7358
> URL: https://issues.jboss.org/browse/ISPN-7358
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 9.0.0.Beta1, 8.2.5.Final
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Priority: Blocker
> Fix For: 9.0.0.Beta2, 9.0.0.Final
>
>
> This might not become so apparent with the current synchronous Java client, but with fully asynchronous clients such as the Javascript one, multiple requests can be piped one after the other.
> Hot Rod server does not often deal with those well, showing exceptions such as:
> {code}
> org.infinispan.server.hotrod.InvalidMagicIdException:
> Error reading magic byte or message id: 119
> {code}
> {code}
> org.infinispan.server.hotrod.UnknownVersionException:
> Unknown version:-96
> {code}
> This exceptions appear when applying considerable load with the Javascript client (see HRJS-24), but the same effect can be replicated with a Netty based, fully asynchronous client, such as the simplified version used [here|https://gist.github.com/galderz/94705dd73d5339b1ab5aa0a5157a9803].
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 11 months
[JBoss JIRA] (HRJS-24) "Unknown version:-96" appears sometimes on the server while put/get operation
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/HRJS-24?page=com.atlassian.jira.plugin.sy... ]
Galder Zamarreño commented on HRJS-24:
--------------------------------------
I can confirm this is an Infinispan Hot Rod server issue, I've replicated it with a unit test there.
> "Unknown version:-96" appears sometimes on the server while put/get operation
> -----------------------------------------------------------------------------
>
> Key: HRJS-24
> URL: https://issues.jboss.org/browse/HRJS-24
> Project: Infinispan Javascript client
> Issue Type: Bug
> Affects Versions: 0.3.0
> Reporter: Anna Manukyan
> Assignee: Galder Zamarreño
>
> I have extended the radargun with nodejs plugin so that later it is possible to test the xsite failover.
> The issue is that sometimes under the load while performing a put/get request over nodejs client, I am getting the following exception on the server:
> {code}
> 14:02:56,885 ERROR [org.infinispan.server.hotrod.CacheDecodeContext] (HotRodServerWorker-7-1) ISPN005003: Exception reported: org.infinispan.server.hotrod.UnknownVersionException: Unknown version:-96
> at org.infinispan.server.hotrod.HotRodDecoder.readHeader(HotRodDecoder.java:199)
> at org.infinispan.server.hotrod.HotRodDecoder.decodeHeader(HotRodDecoder.java:129)
> at org.infinispan.server.hotrod.HotRodDecoder.decode(HotRodDecoder.java:87)
> at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:387)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:245)
> at io.netty.channel.ChannelHandlerInvokerUtil.invokeChannelReadNow(ChannelHandlerInvokerUtil.java:83)
> at io.netty.channel.DefaultChannelHandlerInvoker.invokeChannelRead(DefaultChannelHandlerInvoker.java:154)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:354)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:145)
> at io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86)
> at org.infinispan.server.core.transport.StatsChannelHandler.channelRead(StatsChannelHandler.java:28)
> at io.netty.channel.ChannelHandlerInvokerUtil.invokeChannelReadNow(ChannelHandlerInvokerUtil.java:83)
> at io.netty.channel.DefaultChannelHandlerInvoker.invokeChannelRead(DefaultChannelHandlerInvoker.java:154)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:354)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:145)
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:1078)
> at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:872)
> at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:359)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:275)
> at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:742)
> at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:145)
> at java.lang.Thread.run(Thread.java:745)
> 14:02:56,888 ERROR [org.infinispan.server.hotrod.HotRodEncoder] (HotRodServerWorker-7-1) ISPN005023: Exception encoding message ErrorResponse{version=-96, messageId=-9223372036854775808, operation=ErrorResponse, status=UnknownVersion, msg=org.infinispan.server.hotrod.UnknownVersionException: Unknown version:-96}: scala.MatchError: -96 (of class java.lang.Byte)
> at org.infinispan.server.hotrod.HotRodEncoder.getEncoder(HotRodEncoder.scala:79)
> at org.infinispan.server.hotrod.HotRodEncoder.encode(HotRodEncoder.scala:38)
> at io.netty.handler.codec.MessageToByteEncoder.write(MessageToByteEncoder.java:107)
> at io.netty.channel.ChannelHandlerInvokerUtil.invokeWriteNow(ChannelHandlerInvokerUtil.java:157)
> at io.netty.channel.DefaultChannelHandlerInvoker.invokeWrite(DefaultChannelHandlerInvoker.java:372)
> at io.netty.channel.AbstractChannelHandlerContext.invokeWriteAndFlush(AbstractChannelHandlerContext.java:400)
> at io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:266)
> at io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:272)
> at io.netty.channel.DefaultChannelPipeline.writeAndFlush(DefaultChannelPipeline.java:1186)
> at io.netty.channel.AbstractChannel.writeAndFlush(AbstractChannel.java:286)
> at org.infinispan.server.hotrod.HotRodExceptionHandler.exceptionCaught(HotRodExceptionHandler.java:31)
> at io.netty.channel.ChannelHandlerInvokerUtil.invokeExceptionCaughtNow(ChannelHandlerInvokerUtil.java:64)
> at io.netty.channel.DefaultChannelHandlerInvoker.invokeExceptionCaught(DefaultChannelHandlerInvoker.java:111)
> at io.netty.channel.AbstractChannelHandlerContext.invokeExceptionCaught(AbstractChannelHandlerContext.java:346)
> at io.netty.channel.AbstractChannelHandlerContext.fireExceptionCaught(AbstractChannelHandlerContext.java:131)
> at io.netty.channel.ChannelInboundHandlerAdapter.exceptionCaught(ChannelInboundHandlerAdapter.java:131)
> at io.netty.channel.ChannelHandlerInvokerUtil.invokeExceptionCaughtNow(ChannelHandlerInvokerUtil.java:64)
> at io.netty.channel.DefaultChannelHandlerInvoker.invokeExceptionCaught(DefaultChannelHandlerInvoker.java:111)
> at io.netty.channel.AbstractChannelHandlerContext.invokeExceptionCaught(AbstractChannelHandlerContext.java:346)
> at io.netty.channel.AbstractChannelHandlerContext.fireExceptionCaught(AbstractChannelHandlerContext.java:131)
> at io.netty.channel.ChannelInboundHandlerAdapter.exceptionCaught(ChannelInboundHandlerAdapter.java:131)
> at io.netty.channel.ChannelHandlerInvokerUtil.invokeExceptionCaughtNow(ChannelHandlerInvokerUtil.java:64)
> at io.netty.channel.DefaultChannelHandlerInvoker.invokeExceptionCaught(DefaultChannelHandlerInvoker.java:111)
> at io.netty.channel.AbstractChannelHandlerContext.invokeExceptionCaught(AbstractChannelHandlerContext.java:346)
> at io.netty.channel.AbstractChannelHandlerContext.fireExceptionCaught(AbstractChannelHandlerContext.java:131)
> at io.netty.channel.ChannelHandlerAdapter.exceptionCaught(ChannelHandlerAdapter.java:78)
> at io.netty.channel.ChannelHandlerInvokerUtil.invokeExceptionCaughtNow(ChannelHandlerInvokerUtil.java:64)
> at io.netty.channel.DefaultChannelHandlerInvoker.invokeExceptionCaught(DefaultChannelHandlerInvoker.java:111)
> at io.netty.channel.AbstractChannelHandlerContext.invokeExceptionCaught(AbstractChannelHandlerContext.java:346)
> at io.netty.channel.AbstractChannelHandlerContext.fireExceptionCaught(AbstractChannelHandlerContext.java:131)
> at io.netty.channel.ChannelInboundHandlerAdapter.exceptionCaught(ChannelInboundHandlerAdapter.java:131)
> at io.netty.channel.ChannelHandlerInvokerUtil.invokeExceptionCaughtNow(ChannelHandlerInvokerUtil.java:64)
> at io.netty.channel.DefaultChannelHandlerInvoker.invokeExceptionCaught(DefaultChannelHandlerInvoker.java:111)
> at io.netty.channel.AbstractChannelHandlerContext.invokeExceptionCaught(AbstractChannelHandlerContext.java:346)
> at io.netty.channel.AbstractChannelHandlerContext.fireExceptionCaught(AbstractChannelHandlerContext.java:131)
> at io.netty.channel.ChannelInboundHandlerAdapter.exceptionCaught(ChannelInboundHandlerAdapter.java:131)
> at io.netty.channel.ChannelHandlerInvokerUtil.invokeExceptionCaughtNow(ChannelHandlerInvokerUtil.java:64)
> at io.netty.channel.DefaultChannelHandlerInvoker.invokeExceptionCaught(DefaultChannelHandlerInvoker.java:111)
> at io.netty.channel.AbstractChannelHandlerContext.invokeExceptionCaught(AbstractChannelHandlerContext.java:346)
> at io.netty.channel.AbstractChannelHandlerContext.fireExceptionCaught(AbstractChannelHandlerContext.java:131)
> at io.netty.channel.DefaultChannelPipeline.fireExceptionCaught(DefaultChannelPipeline.java:1066)
> at org.infinispan.server.hotrod.HotRodDecoder.decode(HotRodDecoder.java:124)
> at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:387)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:245)
> at io.netty.channel.ChannelHandlerInvokerUtil.invokeChannelReadNow(ChannelHandlerInvokerUtil.java:83)
> at io.netty.channel.DefaultChannelHandlerInvoker.invokeChannelRead(DefaultChannelHandlerInvoker.java:154)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:354)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:145)
> at io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86)
> at org.infinispan.server.core.transport.StatsChannelHandler.channelRead(StatsChannelHandler.java:28)
> at io.netty.channel.ChannelHandlerInvokerUtil.invokeChannelReadNow(ChannelHandlerInvokerUtil.java:83)
> at io.netty.channel.DefaultChannelHandlerInvoker.invokeChannelRead(DefaultChannelHandlerInvoker.java:154)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:354)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:145)
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:1078)
> at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:872)
> at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:359)
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:275)
> at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:742)
> at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:145)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> I am using the infinispan-js-client 0.3.0. For server different versions are tried - 8.4.2.Final, 9.0.0.Alpha4 - the issue still appears. For 20000 requests I am getting this error for about 3-4 times (maybe more, because after the error appears I am getting an exception on Java side).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 11 months
[JBoss JIRA] (ISPN-7357) Implement ClusterExecutor support in CDI
by Sebastian Łaskawiec (JIRA)
Sebastian Łaskawiec created ISPN-7357:
-----------------------------------------
Summary: Implement ClusterExecutor support in CDI
Key: ISPN-7357
URL: https://issues.jboss.org/browse/ISPN-7357
Project: Infinispan
Issue Type: Feature Request
Reporter: Sebastian Łaskawiec
Assignee: Sebastian Łaskawiec
Currently CDI supports only {{DefaultExecutorService}}. We should add support also for {{ClusterExecutor}}.
However there is a simple workaround for this:
{code}
@Inject
EmbeddedCacheManager ecm;
...
ecm.executor().submit(myRunnable);
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 11 months