January 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2662) Invalid formatting character in TxCompletionNotificationCommand

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-2662?page=com.atlassian.jira.plugin.... ] Work on ISPN-2662 started by Adrian Nistor. > Invalid formatting character in TxCompletionNotificationCommand > --------------------------------------------------------------- > > Key: ISPN-2662 > URL: https://issues.jboss.org/browse/ISPN-2662 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 5.2.0.Beta6 > Reporter: Radim Vansa > Assignee: Adrian Nistor > Priority: Minor > Fix For: 5.2.0.Final > > > Trace logging reveals that in {{org.infinispan.commands.remote.recovery.TxCompletionNotificationCommand.forwardCommandRemotely}} is a typo - {{%w}} instead of {{%s}} -- 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

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2751) NPE after JBossMarshaller stops

by Michal Linhard (JIRA)

[ https://issues.jboss.org/browse/ISPN-2751?page=com.atlassian.jira.plugin.... ] Michal Linhard commented on ISPN-2751: -------------------------------------- Because this exception is reported by JGroups, it's output only as one line ERROR message (see the link). I managed to catch it via exception breakpoint and see it directly in Eclipse, but I can't find my notes, where I pasted the stacktrace and it's quite a long process to recreate it. The JGroups code triggering it is this one: https://github.com/belaban/JGroups/blob/master/src/org/jgroups/blocks/Req... > NPE after JBossMarshaller stops > ------------------------------- > > Key: ISPN-2751 > URL: https://issues.jboss.org/browse/ISPN-2751 > Project: Infinispan > Issue Type: Bug > Components: Marshalling > Affects Versions: 5.2.0.CR2 > Reporter: Michal Linhard > Assignee: Galder Zamarreño > Priority: Minor > Fix For: 5.2.0.Final > > > JBossMarshaller is used by JGroups even after it's stopped > which produces NPE on nonexistent externalizerTable: > https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o... -- 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

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2632) Uneven request balancing after node crash

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2632?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2632: ----------------------------------------------- Michal Linhard <mlinhard(a)redhat.com> changed the Status of [bug 886549|https://bugzilla.redhat.com/show_bug.cgi?id=886549] from ON_QA to VERIFIED > Uneven request balancing after node crash > ----------------------------------------- > > Key: ISPN-2632 > URL: https://issues.jboss.org/browse/ISPN-2632 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 5.2.0.CR1 > Reporter: Michal Linhard > Assignee: Dan Berindei > Priority: Blocker > Fix For: 5.2.0.CR2, 5.2.0.Final > > > This is a new manifestation of ISPN-1995, but in this case this happens after killing only one node: the hot rod requests aren't very well balanced. > these runs still manifest also ISPN-2550 and it may be cause of this bug. > The uneven balancing of requests can be seen here: > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EDG6/view/EDG-REPOR... -- 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

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2750) Uneven request balancing via hotrod

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2750?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2750: ----------------------------------------------- Michal Linhard <mlinhard(a)redhat.com> made a comment on [bug 886549|https://bugzilla.redhat.com/show_bug.cgi?id=886549] OK. Understood. Number of entries (that's stable during a phase with same number of nodes) don't differ more than 8% - so still less than the expected ~10%. The throughput number is much more volatile - it doesn't depend only on the number of entries and the CH, but also all the nondeterminism of network so it's only an illustrative indicator - the numbers around 17-19% are maximums over whole test so the average will be somewhere closer to the acceptable 10% + randomness of network. I'm marking this verified. > Uneven request balancing via hotrod > ----------------------------------- > > Key: ISPN-2750 > URL: https://issues.jboss.org/browse/ISPN-2750 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 5.2.0.CR2 > Reporter: Michal Linhard > Assignee: Dan Berindei > > The load sent to servers in the cluster isn't balanced > tried in 32 node resilience tests: > http://dev39.mw.lab.eng.bos.redhat.com/~mlinhard/hyperion3/run0035-resi-3... > http://dev39.mw.lab.eng.bos.redhat.com/~mlinhard/hyperion3/run0036-resi-3... > this differs from ISPN-2632 in that the load is unbalanced from the beginning of the test. -- 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

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2750) Uneven request balancing via hotrod

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2750?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2750: ----------------------------------------------- Michal Linhard <mlinhard(a)redhat.com> changed the Status of [bug 886549|https://bugzilla.redhat.com/show_bug.cgi?id=886549] from ON_QA to VERIFIED > Uneven request balancing via hotrod > ----------------------------------- > > Key: ISPN-2750 > URL: https://issues.jboss.org/browse/ISPN-2750 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 5.2.0.CR2 > Reporter: Michal Linhard > Assignee: Dan Berindei > > The load sent to servers in the cluster isn't balanced > tried in 32 node resilience tests: > http://dev39.mw.lab.eng.bos.redhat.com/~mlinhard/hyperion3/run0035-resi-3... > http://dev39.mw.lab.eng.bos.redhat.com/~mlinhard/hyperion3/run0036-resi-3... > this differs from ISPN-2632 in that the load is unbalanced from the beginning of the test. -- 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

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2632) Uneven request balancing after node crash

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2632?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2632: ----------------------------------------------- Michal Linhard <mlinhard(a)redhat.com> made a comment on [bug 886549|https://bugzilla.redhat.com/show_bug.cgi?id=886549] OK. Understood. Number of entries (that's stable during a phase with same number of nodes) don't differ more than 8% - so still less than the expected ~10%. The throughput number is much more volatile - it doesn't depend only on the number of entries and the CH, but also all the nondeterminism of network so it's only an illustrative indicator - the numbers around 17-19% are maximums over whole test so the average will be somewhere closer to the acceptable 10% + randomness of network. I'm marking this verified. > Uneven request balancing after node crash > ----------------------------------------- > > Key: ISPN-2632 > URL: https://issues.jboss.org/browse/ISPN-2632 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 5.2.0.CR1 > Reporter: Michal Linhard > Assignee: Dan Berindei > Priority: Blocker > Fix For: 5.2.0.CR2, 5.2.0.Final > > > This is a new manifestation of ISPN-1995, but in this case this happens after killing only one node: the hot rod requests aren't very well balanced. > these runs still manifest also ISPN-2550 and it may be cause of this bug. > The uneven balancing of requests can be seen here: > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EDG6/view/EDG-REPOR... -- 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

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2766) Improve and adapt notification model to fit JSR107 notification model

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-2766?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-2766: -------------------------------------- Assignee: Galder Zamarreño (was: Mircea Markus) > Improve and adapt notification model to fit JSR107 notification model > --------------------------------------------------------------------- > > Key: ISPN-2766 > URL: https://issues.jboss.org/browse/ISPN-2766 > Project: Infinispan > Issue Type: Sub-task > Components: Listeners > Affects Versions: 5.2.0.CR3 > Reporter: Vladimir Blagojevic > Assignee: Galder Zamarreño > > Out current notification (listener) model does not fit JSR 107 notification model and thus needs a slight adaptation in order to implement JSR 107. > More specifically the problem is with JSR107 CacheEntryCreatedListener and CacheEntryExpiredListener. > The first one is not easy to implement because we need both key/value pair for jsr listener and our CacheEntryCreatedEvent does not provide value. > The second is related to CacheEntryExpired event. True, spec is not rigorous that such an event has to be fired immediately after an entry has expired but eventually (which might be on access). However, we do not have such an event at all as of now. > -- 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

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2767) Retrofit storeAsBinary to allow implementation of JSR107 store by value

by Vladimir Blagojevic (JIRA)

Vladimir Blagojevic created ISPN-2767: ----------------------------------------- Summary: Retrofit storeAsBinary to allow implementation of JSR107 store by value Key: ISPN-2767 URL: https://issues.jboss.org/browse/ISPN-2767 Project: Infinispan Issue Type: Sub-task Components: Core API, Marshalling Affects Versions: 5.2.0.CR3 Reporter: Vladimir Blagojevic Assignee: Galder Zamarreño storeAsBinary in Infinispan was designed with the following purposes in mind, in order of importance: 1) Performance. Prevent serialising/deserializing an entry multiple times (e.g., to write through to disk, to replicate over the network, concurrent threads needing to read the object representation). 2) Classloader isolation (as Galder mentioned). This became a secondary purpose of this feature (originally observed as a side-effect). Enhanced by allowing storeKeyAsBinary and storeValueAsBinary options for more fine-grained control of this behaviour. Now lets consider what JSR 107 needs. Similarly named, the feature in JSR 107 serves a completely different purpose, and this is referential integrity. Think database-style isolation (repeatable read, etc) where concurrent threads holding object references to the same value, and mutating the same value, are not visible until a commit. I originally thought that Infinispan's storeAsBinary can be used for this, but apparently not without some additional changes/tweaks. Maybe we need: 1) A new config option for this behaviour. <storeAsBinary defensive="true" /> ? 2) If enabled, maybe use a subclass of MarshalledValue (DefensiveMarshalledValue?) that *always* stores a byte[] and never caches the object representation? -- 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

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2394) Use DataRehashedEvent to signal end of state transfer

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-2394?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-2394: ------------------------------------- DataRehashedEvent works again on 5.2 after ISPN-2507 was fixed. All we need to do is use this event in places like TestingUtil.waitForRehashToComplete(). > Use DataRehashedEvent to signal end of state transfer > ----------------------------------------------------- > > Key: ISPN-2394 > URL: https://issues.jboss.org/browse/ISPN-2394 > Project: Infinispan > Issue Type: Task > Components: State transfer > Affects Versions: 5.2.0.ALPHA1 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 6.0.0.Final > > > Since NBST was introduced the actual completion of state transfer happens later than the TopologyChangedEvent. In unit tests there is currently no simple way to find out when this actually happens so we resorted to some ugly polling (see TestingUtil.waitForRehashToComplete()). Also some other core components could benefit from such an event (eg. StaleTransactionCleanupService, see ISPN-2383). > The event should contain the CacheTopology that is being confirmed as stable. -- 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

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2729) [FineGrainedAtomicMap] Class Cast Exception in Clustered + Repeatable Read + Write Skew

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2729?page=com.atlassian.jira.plugin.... ] Work on ISPN-2729 started by Galder Zamarreño. > [FineGrainedAtomicMap] Class Cast Exception in Clustered + Repeatable Read + Write Skew > --------------------------------------------------------------------------------------- > > Key: ISPN-2729 > URL: https://issues.jboss.org/browse/ISPN-2729 > Project: Infinispan > Issue Type: Bug > Components: Core API, Fine-grained API, Locking and Concurrency > Environment: Mac OSx 10.5, Java 1.6 sun-jdk, maven 3.0.4 > Reporter: Pedro Ruivo > Assignee: Galder Zamarreño > Labels: atomic_map, clustered, write-skew > Fix For: 5.2.0.Final > > > Test case available in here [1] > When a transaction commits, the write skew check performs the validation by casting the cache entry to a ClusteredRepeatableReadEntry. However, the entry is a DeltaAwareCacheEntry. > This happens when you have operations over a map inside a transaction. > The tests failing are: > WriteSkewFineGrainedAtomicMapAPITest.testSizeOnCache() > WriteSkewFineGrainedAtomicMapAPITest.testCreateMapInTx() > [1]https://github.com/pruivo/infinispan/commits/t_atomic_map_issue -- 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

11 years, 11 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2013