[JBoss JIRA] (ISPN-3602) Cache statistics update differently in library and Client-Server mode
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3602?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3602:
-----------------------------------------------
Jiri Holusa <jholusa(a)redhat.com> made a comment on [bug 1016450|https://bugzilla.redhat.com/show_bug.cgi?id=1016450]
When running jdg quickstart carmart ( https://github.com/infinispan/jdg-quickstart/tree/master/carmart ) I noticed interesting thing.
When calling replace() in library mode, the number of stores in cache statistics doesn't change whereas when calling in Client-Server mode, the number of stores increase by 1.
I went deeper into the code and I found out that in CacheMgmtInterceptor, where there are implemented methods for such statistics updates (like for put() ), there isn't implemented method for updating stats for replace() method, so the control flow is just passed.
I think it should be consistent, but I don't know which approach is intended, if either increase by 1 or leave it the same.
If increase is the answer than the solution is simple, implement CacheMgmtInterceptor.visitReplaceCommand(...) the same way as e.g. visitPutKeyValueCommand.
> Cache statistics update differently in library and Client-Server mode
> ---------------------------------------------------------------------
>
> Key: ISPN-3602
> URL: https://issues.jboss.org/browse/ISPN-3602
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 6.0.0.CR1
> Reporter: Jiří Holuša
> Assignee: Mircea Markus
> Priority: Minor
>
> When running jdg quickstart carmart ( https://github.com/infinispan/jdg-quickstart/tree/master/carmart ) I noticed interesting thing.
> When calling replace() in library mode, the number of stores in cache statistics doesn't change whereas when calling in Client-Server mode, the number of stores increase by 1.
> I went deeper into the code and I found out that in CacheMgmtInterceptor, where there are implemented methods for such statistics updates (like for put() ), there isn't implemented method for updating stats for replace() method, so the control flow is just passed.
> I think it should be consistent, but I don't know which approach is intended, if either increase by 1 or leave it the same.
> If increase is the answer than the solution is simple, implement CacheMgmtInterceptor.visitReplaceCommand(...) the same way as e.g. visitPutKeyValueCommand.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-3602) Cache statistics update differently in library and Client-Server mode
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3602?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-3602:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1016450
> Cache statistics update differently in library and Client-Server mode
> ---------------------------------------------------------------------
>
> Key: ISPN-3602
> URL: https://issues.jboss.org/browse/ISPN-3602
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 6.0.0.CR1
> Reporter: Jiří Holuša
> Assignee: Mircea Markus
> Priority: Minor
>
> When running jdg quickstart carmart ( https://github.com/infinispan/jdg-quickstart/tree/master/carmart ) I noticed interesting thing.
> When calling replace() in library mode, the number of stores in cache statistics doesn't change whereas when calling in Client-Server mode, the number of stores increase by 1.
> I went deeper into the code and I found out that in CacheMgmtInterceptor, where there are implemented methods for such statistics updates (like for put() ), there isn't implemented method for updating stats for replace() method, so the control flow is just passed.
> I think it should be consistent, but I don't know which approach is intended, if either increase by 1 or leave it the same.
> If increase is the answer than the solution is simple, implement CacheMgmtInterceptor.visitReplaceCommand(...) the same way as e.g. visitPutKeyValueCommand.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-3602) Cache statistics update differently in library and Client-Server mode
by Jiří Holuša (JIRA)
Jiří Holuša created ISPN-3602:
---------------------------------
Summary: Cache statistics update differently in library and Client-Server mode
Key: ISPN-3602
URL: https://issues.jboss.org/browse/ISPN-3602
Project: Infinispan
Issue Type: Bug
Components: Core API
Affects Versions: 6.0.0.CR1
Reporter: Jiří Holuša
Assignee: Mircea Markus
Priority: Minor
When running jdg quickstart carmart ( https://github.com/infinispan/jdg-quickstart/tree/master/carmart ) I noticed interesting thing.
When calling replace() in library mode, the number of stores in cache statistics doesn't change whereas when calling in Client-Server mode, the number of stores increase by 1.
I went deeper into the code and I found out that in CacheMgmtInterceptor, where there are implemented methods for such statistics updates (like for put() ), there isn't implemented method for updating stats for replace() method, so the control flow is just passed.
I think it should be consistent, but I don't know which approach is intended, if either increase by 1 or leave it the same.
If increase is the answer than the solution is simple, implement CacheMgmtInterceptor.visitReplaceCommand(...) the same way as e.g. visitPutKeyValueCommand.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-3598) ISPN testsuite fails for RHEL 5, 6 && IBM JDK6
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3598?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3598:
-----------------------------------------------
Anna Manukyan <amanukya(a)redhat.com> made a comment on [bug 1016046|https://bugzilla.redhat.com/show_bug.cgi?id=1016046]
Tristan, I've rechecked our build process and the script. Each time the tests run, first the existing infinispan/ dir is deleted, the new one is cloned from the git with corresponding repository version and then the tests are run.
> ISPN testsuite fails for RHEL 5,6 && IBM JDK6
> ---------------------------------------------
>
> Key: ISPN-3598
> URL: https://issues.jboss.org/browse/ISPN-3598
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 6.0.0.Beta1
> Environment: RHEL{5, 6} && IBM JDK6
> Reporter: Anna Manukyan
> Assignee: Mircea Markus
> Labels: testsuite_stability
> Attachments: ibm6_infinispan_failure_rhel5_x32.log, ibm6_infinispan_failure_rhel5_x64.log, ibm6_infinispan_failure_rhel6_x32.log, ibm6_infinispan_failure_rhel6_x64.log
>
>
> The ISPN testsuite fails for the environment specified in the description.
> You can find the core module's tracelog for all configurations attached.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-3599) CommitCommand with replayed PrepareCommand executes rollback and then commit
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-3599?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-3599:
-----------------------------------
Actually, I am not sure - I've noticed this behaviour when tracking down ISPN-3600 (and the inconsistency was caused by the 3600). However, I believe that it can lead to inconsistency as the locks are released (is it, during the rollback, right?) before the entries are committed.
> CommitCommand with replayed PrepareCommand executes rollback and then commit
> ----------------------------------------------------------------------------
>
> Key: ISPN-3599
> URL: https://issues.jboss.org/browse/ISPN-3599
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer, Transactions
> Affects Versions: 6.0.0.CR1
> Reporter: Radim Vansa
> Assignee: Mircea Markus
> Priority: Critical
>
> During state-transfer in tx cache, the node can receive {{CommitCommand}} from other node. After the node gets transaction data for affected segments, it creates the transaction with {{missingLookedUpEntries=true}} and the {{CommitCommand}} can be executed.
> In this command's {{perform(...)}} the transaction is *first* marked as completed, then it enters the interceptor chain. There, the {{PrepareCommand}} is created in {{StateTransferInterceptor.visitCommitCommand}} but after this is processed the {{TxInterceptor}} finds out that the transaction is already completed and executes {{RollbackCommand}}, clearing locks etc.
> Nevertheless, {{StateTransferInterceptor}} executes the initial {{CommitCommand}} afterwards. I suspect that this may be executed without the locks held.
> Anyway, it is not correct to execute both commit and rollback on the same transaction.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-3601) REST cache store has problems with modules and finding classes
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3601?page=com.atlassian.jira.plugin.... ]
Work on ISPN-3601 started by William Burns.
> REST cache store has problems with modules and finding classes
> --------------------------------------------------------------
>
> Key: ISPN-3601
> URL: https://issues.jboss.org/browse/ISPN-3601
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 6.0.0.Alpha4
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 6.0.0.Final
>
>
> Found in DR4 as the first release which contains Infinispan 6.0.0.Aplha4 and therefore REST Cache Store + possibility of REST Rolling Upgrades.
> I've experienced problems with starting JDG node using standalone-rest-rolling-upgrade.xml example configuration (for target node).
> Please see report in attachment.
> You can find 2 console outputs of jdg server. The second one is after some changes in modules.xml (in rest cachestore module).
> Details are shown and described in that file.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-3601) REST cache store has problems with modules and finding classes
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3601?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-3601:
--------------------------------
Component/s: Server
> REST cache store has problems with modules and finding classes
> --------------------------------------------------------------
>
> Key: ISPN-3601
> URL: https://issues.jboss.org/browse/ISPN-3601
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 6.0.0.Alpha4
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 6.0.0.Final
>
>
> Found in DR4 as the first release which contains Infinispan 6.0.0.Aplha4 and therefore REST Cache Store + possibility of REST Rolling Upgrades.
> I've experienced problems with starting JDG node using standalone-rest-rolling-upgrade.xml example configuration (for target node).
> Please see report in attachment.
> You can find 2 console outputs of jdg server. The second one is after some changes in modules.xml (in rest cachestore module).
> Details are shown and described in that file.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-3601) REST cache store has problems with modules and finding classes
by William Burns (JIRA)
William Burns created ISPN-3601:
-----------------------------------
Summary: REST cache store has problems with modules and finding classes
Key: ISPN-3601
URL: https://issues.jboss.org/browse/ISPN-3601
Project: Infinispan
Issue Type: Bug
Affects Versions: 6.0.0.Alpha4
Reporter: William Burns
Assignee: William Burns
Fix For: 6.0.0.Final
Found in DR4 as the first release which contains Infinispan 6.0.0.Aplha4 and therefore REST Cache Store + possibility of REST Rolling Upgrades.
I've experienced problems with starting JDG node using standalone-rest-rolling-upgrade.xml example configuration (for target node).
Please see report in attachment.
You can find 2 console outputs of jdg server. The second one is after some changes in modules.xml (in rest cachestore module).
Details are shown and described in that file.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months