October 2013 - infinispan-issues - Jboss List Archives

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (ISPN-3601) REST cache store has problems with modules and finding classes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3601?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3601: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1006281 > 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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (ISPN-3507) EntrySet operation in cache with LevelDB store ignores expiration

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3507?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3507: ----------------------------------------------- Michal Linhard <mlinhard(a)redhat.com> changed the Status of [bug 1007947|https://bugzilla.redhat.com/show_bug.cgi?id=1007947] from ON_QA to VERIFIED > EntrySet operation in cache with LevelDB store ignores expiration > ----------------------------------------------------------------- > > Key: ISPN-3507 > URL: https://issues.jboss.org/browse/ISPN-3507 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.0.Alpha4 > Reporter: Michal Linhard > Assignee: Mircea Markus > Priority: Critical > Labels: jdg62blocker > Fix For: 6.0.0.Beta2 > > > In cache with leveldb cache store, expired entry still appears in collection returned by entrySet operation. > test: > https://github.com/mlinhard/infinispan-cachestore-leveldb/commit/71b62c19... -- 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

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2013