[JBoss JIRA] (ISPN-7643) Coordinator status is unavailable in Infinispan cluster
by Sebastian Łaskawiec (JIRA)
Sebastian Łaskawiec created ISPN-7643:
-----------------------------------------
Summary: Coordinator status is unavailable in Infinispan cluster
Key: ISPN-7643
URL: https://issues.jboss.org/browse/ISPN-7643
Project: Infinispan
Issue Type: Bug
Components: JMX, reporting and management
Reporter: Sebastian Łaskawiec
Assignee: Sebastian Łaskawiec
It seems that Coordinator field uses JGroups Address class which can be displayed properly. Since we already have a Coordinator Address field, maybe the best way would be to remove this from JMX.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7642) Administration console - remote sites are not displayed correctly on cache container page
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-7642?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic commented on ISPN-7642:
-------------------------------------------
[~rmacor] So in summary, on cache detail page, only BRN is show and not the other site?
> Administration console - remote sites are not displayed correctly on cache container page
> -----------------------------------------------------------------------------------------
>
> Key: ISPN-7642
> URL: https://issues.jboss.org/browse/ISPN-7642
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 9.0.0.CR2
> Reporter: Roman Macor
> Attachments: Screenshot-cacheContainer.png, Screenshot-detail-cache.png
>
>
> Have 2 caches each configured with a different remote site.
> When you click on cache container, both remote sites are displayed on both cache cards. Clicking on a cache to see cache detail page shows correct remote site. Please see the attached screenshots.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7642) Administration console - remote sites are not displayed correctly on cache container page
by Roman Macor (JIRA)
Roman Macor created ISPN-7642:
---------------------------------
Summary: Administration console - remote sites are not displayed correctly on cache container page
Key: ISPN-7642
URL: https://issues.jboss.org/browse/ISPN-7642
Project: Infinispan
Issue Type: Bug
Components: JMX, reporting and management
Affects Versions: 9.0.0.CR2
Reporter: Roman Macor
Attachments: Screenshot-cacheContainer.png, Screenshot-detail-cache.png
Have 2 caches each configured with a different remote site.
When you click on cache container, both remote sites are displayed on both cache cards. Clicking on a cache to see cache detail page shows correct remote site. Please see the attached screenshots.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7641) Do not use the Triangle when in server mode
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-7641?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-7641:
------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/4994
> Do not use the Triangle when in server mode
> -------------------------------------------
>
> Key: ISPN-7641
> URL: https://issues.jboss.org/browse/ISPN-7641
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 9.0.0.CR2
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Labels: performance
> Fix For: 9.0.0.Final
>
>
> The triangle algorithm optimizes the scenario where the originator is not the primary owner of key, by sending ordered update from the primary to the backup.
> Current implementation orders the updates by segments and if 2 or more keys in the same segment are updated concurrently, they must be updated in the backup sequential by the same order (safety condition, keeps the data consistent).
> This approach has a negative impact in the scenario where the originator is the primary owner. However, in server mode (more precise in hot rod protocol), the clients connect directly to the primary owner of a key. This leads to a performance degradation with the triangle.
> Using the old algorithm only in server mode brings the performance back to normal.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7641) Do not use the Triangle when in server mode
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-7641?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-7641:
------------------------------
Labels: performance (was: )
> Do not use the Triangle when in server mode
> -------------------------------------------
>
> Key: ISPN-7641
> URL: https://issues.jboss.org/browse/ISPN-7641
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 9.0.0.CR2
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Labels: performance
> Fix For: 9.0.0.Final
>
>
> The triangle algorithm optimizes the scenario where the originator is not the primary owner of key, by sending ordered update from the primary to the backup.
> Current implementation orders the updates by segments and if 2 or more keys in the same segment are updated concurrently, they must be updated in the backup sequential by the same order (safety condition, keeps the data consistent).
> This approach has a negative impact in the scenario where the originator is the primary owner. However, in server mode (more precise in hot rod protocol), the clients connect directly to the primary owner of a key. This leads to a performance degradation with the triangle.
> Using the old algorithm only in server mode brings the performance back to normal.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7641) Do not use the Triangle when in server mode
by Pedro Ruivo (JIRA)
Pedro Ruivo created ISPN-7641:
---------------------------------
Summary: Do not use the Triangle when in server mode
Key: ISPN-7641
URL: https://issues.jboss.org/browse/ISPN-7641
Project: Infinispan
Issue Type: Enhancement
Components: Server
Affects Versions: 9.0.0.CR2
Reporter: Pedro Ruivo
Assignee: Pedro Ruivo
Fix For: 9.0.0.Final
The triangle algorithm optimizes the scenario where the originator is not the primary owner of key, by sending ordered update from the primary to the backup.
Current implementation orders the updates by segments and if 2 or more keys in the same segment are updated concurrently, they must be updated in the backup sequential by the same order (safety condition, keeps the data consistent).
This approach has a negative impact in the scenario where the originator is the primary owner. However, in server mode (more precise in hot rod protocol), the clients connect directly to the primary owner of a key. This leads to a performance degradation with the triangle.
Using the old algorithm only in server mode brings the performance back to normal.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7641) Do not use the Triangle when in server mode
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-7641?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-7641:
------------------------------
Status: Open (was: New)
> Do not use the Triangle when in server mode
> -------------------------------------------
>
> Key: ISPN-7641
> URL: https://issues.jboss.org/browse/ISPN-7641
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 9.0.0.CR2
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Labels: performance
> Fix For: 9.0.0.Final
>
>
> The triangle algorithm optimizes the scenario where the originator is not the primary owner of key, by sending ordered update from the primary to the backup.
> Current implementation orders the updates by segments and if 2 or more keys in the same segment are updated concurrently, they must be updated in the backup sequential by the same order (safety condition, keeps the data consistent).
> This approach has a negative impact in the scenario where the originator is the primary owner. However, in server mode (more precise in hot rod protocol), the clients connect directly to the primary owner of a key. This leads to a performance degradation with the triangle.
> Using the old algorithm only in server mode brings the performance back to normal.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7628) Administration console - the cluster status doesn't reflect "reload-required" state of its nodes
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-7628?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic commented on ISPN-7628:
-------------------------------------------
Thanks [~rmacor] I updated PR to reflect your input. The new logic is:
cluster is in reload required state if at least one server is in reload required state
cluster is in restart required state if at least one server is in restart required state
cluster is in running state if at least one server is in running state and all others in stopped state, i.e. not reload/restart required
cluster is in stopped state if all servers are in stopped state
degraded state is reserved for view incosistency
> Administration console - the cluster status doesn't reflect "reload-required" state of its nodes
> ------------------------------------------------------------------------------------------------
>
> Key: ISPN-7628
> URL: https://issues.jboss.org/browse/ISPN-7628
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 9.0.0.CR2
> Reporter: Roman Macor
> Assignee: Vladimir Blagojevic
>
> The cluster has "Started" status even though all of its nodes have "reload-required" status.
> Expected result:
> The cluster status should also be "reload-required"
> Another suggestion:
> "Reload" action should be available from the cluster so that the user doesn't need to perform this action on individual nodes (there could be hundreds of them )
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (HRJS-33) Cluster tests randomly fail iteration
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/HRJS-33?page=com.atlassian.jira.plugin.sy... ]
Galder Zamarreño resolved HRJS-33.
----------------------------------
Resolution: Done
> Cluster tests randomly fail iteration
> -------------------------------------
>
> Key: HRJS-33
> URL: https://issues.jboss.org/browse/HRJS-33
> Project: Infinispan Javascript client
> Issue Type: Bug
> Affects Versions: 0.3.0
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 0.4.0
>
> Attachments: server-trace-logs.tgz
>
>
> Very sheldon the cluster spec iteration tests fail with:
> {code}
> Failures:
> 1) Infinispan cluster client can iterate over entries in a cluster
> Message:
> java.util.NoSuchElementException
> Stacktrace:
> undefined
> 2) Infinispan cluster client can remove listener in cluster
> Message:
> timeout: timed out after 5000 msec waiting for spec to complete
> Stacktrace:
> undefined
> 3) Infinispan cluster client can execute a script remotely to store and retrieve data in cluster mode
> Message:
> Expected 'cluster-typed-key' to be 'listen-distinct-1'.
> Stacktrace:
> Error: Expected 'cluster-typed-key' to be 'listen-distinct-1'.
> at EventEmitter.<anonymous> (/Users/g/0/infinispan/js-client/spec/utils/testing.js:317:26)
> at EventEmitter.emit (events.js:106:17)
> at emitKeyVersion (/Users/g/0/infinispan/js-client/lib/protocols.js:411:29)
> at /Users/g/0/infinispan/js-client/lib/protocols.js:399:18
> at Function.<anonymous> (/Users/g/0/infinispan/js-client/lib/functional.js:185:16)
> at /Users/g/0/infinispan/js-client/lib/functional.js:173:19
> at ListenersMixin.decodeEvent (/Users/g/0/infinispan/js-client/lib/protocols.js:475:18)
> at Socket.onData (/Users/g/0/infinispan/js-client/lib/io.js:103:38)
> 4) Infinispan cluster client can execute a script remotely to store and retrieve data in cluster mode
> Message:
> timeout: timed out after 5000 msec waiting for spec to complete
> Stacktrace:
> undefined
> 5) Infinispan cluster client can execute a script remotely to store and retrieve data in distributed mode
> Message:
> Expected 'dist-cluster-typed-key' to be 'listen-distinct-1'.
> Stacktrace:
> Error: Expected 'dist-cluster-typed-key' to be 'listen-distinct-1'.
> at EventEmitter.<anonymous> (/Users/g/0/infinispan/js-client/spec/utils/testing.js:317:26)
> at EventEmitter.emit (events.js:106:17)
> at emitKeyVersion (/Users/g/0/infinispan/js-client/lib/protocols.js:411:29)
> at /Users/g/0/infinispan/js-client/lib/protocols.js:399:18
> at Function.<anonymous> (/Users/g/0/infinispan/js-client/lib/functional.js:185:16)
> at /Users/g/0/infinispan/js-client/lib/functional.js:173:19
> at ListenersMixin.decodeEvent (/Users/g/0/infinispan/js-client/lib/protocols.js:475:18)
> at Socket.onData (/Users/g/0/infinispan/js-client/lib/io.js:103:38)
> Finished in 12.721 seconds
> 10 tests, 26 assertions, 5 failures, 0 skipped
> {code}
> See attached TRACE logs from server (unfortunately no client logs)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (HRJS-33) Cluster tests randomly fail iteration
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/HRJS-33?page=com.atlassian.jira.plugin.sy... ]
Galder Zamarreño reopened HRJS-33:
----------------------------------
> Cluster tests randomly fail iteration
> -------------------------------------
>
> Key: HRJS-33
> URL: https://issues.jboss.org/browse/HRJS-33
> Project: Infinispan Javascript client
> Issue Type: Bug
> Affects Versions: 0.3.0
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 0.4.0
>
> Attachments: server-trace-logs.tgz
>
>
> Very sheldon the cluster spec iteration tests fail with:
> {code}
> Failures:
> 1) Infinispan cluster client can iterate over entries in a cluster
> Message:
> java.util.NoSuchElementException
> Stacktrace:
> undefined
> 2) Infinispan cluster client can remove listener in cluster
> Message:
> timeout: timed out after 5000 msec waiting for spec to complete
> Stacktrace:
> undefined
> 3) Infinispan cluster client can execute a script remotely to store and retrieve data in cluster mode
> Message:
> Expected 'cluster-typed-key' to be 'listen-distinct-1'.
> Stacktrace:
> Error: Expected 'cluster-typed-key' to be 'listen-distinct-1'.
> at EventEmitter.<anonymous> (/Users/g/0/infinispan/js-client/spec/utils/testing.js:317:26)
> at EventEmitter.emit (events.js:106:17)
> at emitKeyVersion (/Users/g/0/infinispan/js-client/lib/protocols.js:411:29)
> at /Users/g/0/infinispan/js-client/lib/protocols.js:399:18
> at Function.<anonymous> (/Users/g/0/infinispan/js-client/lib/functional.js:185:16)
> at /Users/g/0/infinispan/js-client/lib/functional.js:173:19
> at ListenersMixin.decodeEvent (/Users/g/0/infinispan/js-client/lib/protocols.js:475:18)
> at Socket.onData (/Users/g/0/infinispan/js-client/lib/io.js:103:38)
> 4) Infinispan cluster client can execute a script remotely to store and retrieve data in cluster mode
> Message:
> timeout: timed out after 5000 msec waiting for spec to complete
> Stacktrace:
> undefined
> 5) Infinispan cluster client can execute a script remotely to store and retrieve data in distributed mode
> Message:
> Expected 'dist-cluster-typed-key' to be 'listen-distinct-1'.
> Stacktrace:
> Error: Expected 'dist-cluster-typed-key' to be 'listen-distinct-1'.
> at EventEmitter.<anonymous> (/Users/g/0/infinispan/js-client/spec/utils/testing.js:317:26)
> at EventEmitter.emit (events.js:106:17)
> at emitKeyVersion (/Users/g/0/infinispan/js-client/lib/protocols.js:411:29)
> at /Users/g/0/infinispan/js-client/lib/protocols.js:399:18
> at Function.<anonymous> (/Users/g/0/infinispan/js-client/lib/functional.js:185:16)
> at /Users/g/0/infinispan/js-client/lib/functional.js:173:19
> at ListenersMixin.decodeEvent (/Users/g/0/infinispan/js-client/lib/protocols.js:475:18)
> at Socket.onData (/Users/g/0/infinispan/js-client/lib/io.js:103:38)
> Finished in 12.721 seconds
> 10 tests, 26 assertions, 5 failures, 0 skipped
> {code}
> See attached TRACE logs from server (unfortunately no client logs)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years