January 2011 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Updated: (ISPN-884) @Merged not working

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-884?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-884: ------------------------------- Summary: @Merged not working (was: @MergeView not working) > @Merged not working > ------------------- > > Key: ISPN-884 > URL: https://issues.jboss.org/browse/ISPN-884 > Project: Infinispan > Issue Type: Bug > Reporter: Mircea Markus > Assignee: Manik Surtani > > and there's no UT to check this functionality -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (ISPN-881) A listener which receives CacheEntryCreatedEvent + CacheEntryModifiedEvent events always has a null value after a Cache.put while a Cache.put which replaces delivers the actual value.

by Miroslav Pokorny (JIRA)

A listener which receives CacheEntryCreatedEvent + CacheEntryModifiedEvent events always has a null value after a Cache.put while a Cache.put which replaces delivers the actual value. --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: ISPN-881 URL: https://issues.jboss.org/browse/ISPN-881 Project: Infinispan Issue Type: Bug Components: Listeners Affects Versions: 4.2.0.CR3 Environment: N/A Reporter: Miroslav Pokorny Assignee: Manik Surtani It would be advantageous if the beheaviour of the delivered modify events did not deliver null values after a put which is different from a put which replaces which does deliver the actual value. It is also not possible to take the key from the create event and try and read the cache. I have tried printing both when the Event.isPre() field is false and true and the value is null. Please examine the provided test harness which includes some prints the output which demonstrates the problem... --- package miroslav.pokorny.cache.infinispan; import org.infinispan.manager.DefaultCacheManager; import org.infinispan.manager.EmbeddedCacheManager; import org.infinispan.notifications.Listener; import org.infinispan.notifications.cachelistener.annotation.CacheEntryCreated; import org.infinispan.notifications.cachelistener.annotation.CacheEntryModified; import org.infinispan.notifications.cachelistener.event.CacheEntryCreatedEvent; import org.infinispan.notifications.cachelistener.event.CacheEntryModifiedEvent; public class InfinispanValueProblemTest { private final static String KEY = "key"; private final static String VALUE = "*Value*"; static public void main(final String[] ignored) { final EmbeddedCacheManager manager = new DefaultCacheManager(); final org.infinispan.Cache<String, String> cache = manager.getCache(); cache.addListener(new InfinispanCacheListener()); cache.put(KEY, VALUE); } @Listener static final public class InfinispanCacheListener { @CacheEntryCreated public void entryCreated(final CacheEntryCreatedEvent<String, String> event) { System.out.println("CREATE EVENT\n\t" + event.getKey() + "= cant do get value\n\tisPre=" + event.isPre() + "\n\tevent.getCache().get(event.getKey())=" + event.getCache().get(event.getKey())); } @CacheEntryModified public void entryModified(final CacheEntryModifiedEvent<String, String> event) { System.out.println("MODIFIED EVENT\n\t" + event.getKey() + "=" + event.getValue() + "\n\tisPre=" + event.isPre() + "\n\tevent.getCache().get(event.getKey())=" + event.getCache().get(event.getKey())); } } } ------------------------------------------- Running the test should print something like this [ GlobalComponentRegistry] - Infinispan version: Infinispan 'Ursus' 4.2.0.CR3 [ ComponentRegistry] - Infinispan version: Infinispan 'Ursus' 4.2.0.CR3 CREATE EVENT key= cant do get value isPre=true event.getCache().get(event.getKey())=null CREATE EVENT key= cant do get value isPre=false event.getCache().get(event.getKey())=null MODIFIED EVENT key=null isPre=true event.getCache().get(event.getKey())=null MODIFIED EVENT key=*Value* isPre=false event.getCache().get(event.getKey())=null -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

2
6
0 / 0

[JBoss JIRA] Created: (ISPN-654) Lost cache data on insert and state transfer with async DIST cache

by Erik Salter (JIRA)

Lost cache data on insert and state transfer with async DIST cache ------------------------------------------------------------------ Key: ISPN-654 URL: https://jira.jboss.org/browse/ISPN-654 Project: Infinispan Issue Type: Bug Affects Versions: 4.1.0.Final Reporter: Erik Salter Assignee: Manik Surtani We have a performance test that is putting 10K objects into a 4-node cluster, with each of the nodes on separate physical machines. We are seeing loss of data after an insert and loss of a data node. The test directions and code are attached to this JIRA. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

4
23
0 / 0

[JBoss JIRA] Created: (ISPN-880) Hash impls use String.getBytes(), may get non UTF8 bytes

by Patrick McFarland (JIRA)

Hash impls use String.getBytes(), may get non UTF8 bytes -------------------------------------------------------- Key: ISPN-880 URL: https://issues.jboss.org/browse/ISPN-880 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 4.2.1.Final Reporter: Patrick McFarland Assignee: Manik Surtani According to Sun's Java docs, String.getBytes() will return bytes in the platform's native encoding, which may not be UTF-8. Cross platform (or same platforms configured differently) may end up with problems in the same cluster. The fix seems to be replace all String.getBytes() uses with String.getBytes(Charset.forName("UTF-8")) to always force UTF-8 conversion. This bug may also apply to other unrelated places in Infinispan, I haven't checked. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (ISPN-861) Avoid writing to a shared CacheStore during rehash

by Sanne Grinovero (JIRA)

Avoid writing to a shared CacheStore during rehash -------------------------------------------------- Key: ISPN-861 URL: https://issues.jboss.org/browse/ISPN-861 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 4.2.0.Final, 4.1.0.Final Reporter: Sanne Grinovero Assignee: Manik Surtani When a node receives new data as new owner during a rehash, it has to write this data to the underlying cachestore when each node has a different store, but it's actually writing to the store also in case the store is shared. This brings a small performance penalty, but also makes it possible for values which where originally stored using Flag.SKIP_STORE to be actually written to permanent store during a rehash. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (ISPN-864) Passivate in-memory entries to cache store upon shutdown

by Dave Marion (JIRA)

Passivate in-memory entries to cache store upon shutdown -------------------------------------------------------- Key: ISPN-864 URL: https://issues.jboss.org/browse/ISPN-864 Project: Infinispan Issue Type: Feature Request Components: Loaders and Stores Affects Versions: 4.2.0.Final Reporter: Dave Marion Assignee: Manik Surtani When cache store configured, passivate in-memory entries when cache is shutdown. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

2
6
0 / 0

[JBoss JIRA] Resolved: (ISPN-39) Distributed executors

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-39?page=com.atlassian.jira.plugin.sy... ] Galder Zamarreño resolved ISPN-39. ---------------------------------- Resolution: Done > Distributed executors > --------------------- > > Key: ISPN-39 > URL: https://issues.jboss.org/browse/ISPN-39 > Project: Infinispan > Issue Type: Feature Request > Components: RPC > Reporter: Manik Surtani > Assignee: Vladimir Blagojevic > Priority: Critical > Labels: hackathon > Fix For: 5.0.0.ALPHA2, 5.0.0.Final > > > A new API to allow users to provide a Runnable/Callable and a set of keys to run this on, and the ability to move the code to where the data is and execute it there, returning results (if any) across a network. > Scope and objectives of this task are described in https://community.jboss.org/wiki/InfinispanDistributedExecutionFramework -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (ISPN-777) Eager cluster wide locks not cleaned upon rollback

by Vladimir Blagojevic (JIRA)

Eager cluster wide locks not cleaned upon rollback -------------------------------------------------- Key: ISPN-777 URL: https://jira.jboss.org/browse/ISPN-777 Project: Infinispan Issue Type: Bug Components: Locking and Concurrency Affects Versions: 4.2.0.BETA1 Reporter: Vladimir Blagojevic Assignee: Mircea Markus Fix For: 4.2.0.CR1 It seems that rollback sometimes does not release acquired eager locks. See attached test program and run two JVM instances on the same machine. Program schedules a task to run every 5 seconds. Tasks simply locks a key, gets the value, increases the value and puts it back surrounded by begin/commit/rollback tx boundary. Steps to reproduce: 1) Kill one running instance. 2) Restart it See attached example output of a run. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

4
23
0 / 0

[JBoss JIRA] Assigned: (ISPN-878) update documentation for http://community.jboss.org/wiki/MultipleTiersofCaches

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-878?page=com.atlassian.jira.plugin.s... ] Mircea Markus reassigned ISPN-878: ---------------------------------- Assignee: Mircea Markus (was: Manik Surtani) > update documentation for http://community.jboss.org/wiki/MultipleTiersofCaches > ------------------------------------------------------------------------------- > > Key: ISPN-878 > URL: https://issues.jboss.org/browse/ISPN-878 > Project: Infinispan > Issue Type: Task > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 5.0.0.Final > > > Update http://community.jboss.org/wiki/MultipleTiersofCaches as follows: > Feedback from Galder: though, the text in the diagram is very very small and can hardly be read. Maybe you can improve it a little? > Feedback from Manik: > Also some more feedback: > * Spelling: "Multi-Tiered", not "Multiered" > * Your diagram probably wants to demonstrate 2 separate tiers, not just 1 client with a clustered server backend. E.g., > FE1 --- FE2 --- FE3 > =============== > BE1 --- BE2 --- BE3 > where FE = front-end servers (embedded, maybe an app server running a webapp, with an embedded Infinispan instance as a "near cache") > BE = backend, dedicated cache tier, running Hot Rod endpoints > FE configured with RemoteCacheStore, and also using Invalidation so that FE's can invalidate each other > BE's running DIST for max addressable space + ultimate scalability > This way, with the FE's running in INVAL mode, it doesn't matter if the BE's cannot communicate changes back to the FE's, since the FE's wil already know about changes and will invalidate accordingly. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (ISPN-832) TimeoutException with 2 or more nodes when there are Entity inserts, updates or removes.

by Cyrille Charron (JIRA)

TimeoutException with 2 or more nodes when there are Entity inserts, updates or removes. ---------------------------------------------------------------------------------------- Key: ISPN-832 URL: https://issues.jboss.org/browse/ISPN-832 Project: Infinispan Issue Type: Bug Components: State transfer Affects Versions: 4.2.0.CR3 Environment: Windows XP + Hibernate 3.6.1-SNAPSHOT + OpenEjb 3.2-SNAPSHOT Reporter: Cyrille Charron Assignee: Manik Surtani Hello, I have some difficulties to run more than one Node with Infinispan as a JPA Level2 cache (default configuration) with Hibernate as JPA provider and with OpenEjb as JEE container. There are a lot of Locks between Nodes when I try to insert entities, even if each Node insert entities with a unique ID. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

3
29
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2011