[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 edited comment on ISPN-7328 at 1/16/17 9:23 AM:
-------------------------------------------------------------
I've created [ISPN-7359|https://issues.jboss.org/browse/ISPN-7359] for the creation of the server side operations
was (Author: ryanemerson):
I've created https://issues.jboss.org/browse/ISPN-7359 for the creation of the server side operations
> 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)
9 years, 2 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:
------------------------------------
I've created https://issues.jboss.org/browse/ISPN-7359 for the creation of the server side operations
> 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)
9 years, 2 months
[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)
9 years, 2 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)
9 years, 2 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)
9 years, 2 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)
9 years, 2 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)
9 years, 2 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)
9 years, 2 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)
9 years, 2 months