March 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2034) Add backwards serialization compatibility tests

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-2034?page=com.atlassian.jira.plugin.... ] Ion Savin updated ISPN-2034: ---------------------------- Fix Version/s: 7.0.0.Alpha3 (was: 7.0.0.Alpha2) > Add backwards serialization compatibility tests > ----------------------------------------------- > > Key: ISPN-2034 > URL: https://issues.jboss.org/browse/ISPN-2034 > Project: Infinispan > Issue Type: Enhancement > Components: Marshalling > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Labels: compatibility > Fix For: 7.0.0.Alpha3 > > > Take each existing minor branch, i.e. 4.1.x, 4.0.x,...etc and modify VersionAwareMarshallerTest so that payloads are stored in a data file. > Then, take data files for each branch and store in git (master and 5.1.x), and try reading them with the existing externalizer/marshalling set up. > It should work... -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-1986) Make putForExternalRead return a boolean instead of void

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-1986?page=com.atlassian.jira.plugin.... ] Ion Savin updated ISPN-1986: ---------------------------- Fix Version/s: 7.0.0.Alpha3 (was: 7.0.0.Alpha2) > Make putForExternalRead return a boolean instead of void > -------------------------------------------------------- > > Key: ISPN-1986 > URL: https://issues.jboss.org/browse/ISPN-1986 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Critical > Fix For: 7.0.0.Alpha3, 7.0.0.Final > > > Related to ISPN-1983 and https://hibernate.onjira.com/browse/HHH-7256, I'd like to change the API of putForExternalRead() to return a boolean instead of void. > The reason for doing this is to be able to find out if the PFER did actually end up storing something or not. -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-833) Revisit cache name predefinition limitation for cache servers

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-833?page=com.atlassian.jira.plugin.s... ] Ion Savin updated ISPN-833: --------------------------- Fix Version/s: 7.0.0.Alpha3 (was: 7.0.0.Alpha2) > Revisit cache name predefinition limitation for cache servers > ------------------------------------------------------------- > > Key: ISPN-833 > URL: https://issues.jboss.org/browse/ISPN-833 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Alpha3, 7.0.0.Final > > > There're are two primary reasons why Infinispan servers require predefined caches to be started up on startup, and do not allow invocations to undefined caches: > 1. Concurrent cache startups were resulting in NPEs (ISPN-635) - This is already solved since the 4.2.x days. > 2. Infinispan has issues dealing with asymmetric clusters (ISPN-658). > Once these two issues have been resolved, revisit the limitation. -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-2324) Add user documentation for NSBT

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-2324?page=com.atlassian.jira.plugin.... ] Ion Savin updated ISPN-2324: ---------------------------- Fix Version/s: 7.0.0.Alpha3 (was: 7.0.0.Alpha2) > Add user documentation for NSBT > -------------------------------- > > Key: ISPN-2324 > URL: https://issues.jboss.org/browse/ISPN-2324 > Project: Infinispan > Issue Type: Feature Request > Components: Documentation-Core > Affects Versions: 5.2.0.Alpha3 > Reporter: Mircea Markus > Assignee: Dan Berindei > Labels: documentation > Fix For: 7.0.0.Alpha3 > > > To be linked from the user guide page:https://docs.jboss.org/author/display/ISPN/User+Guide -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-2342) Cross-Site Replication: State Transfer between sites

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-2342?page=com.atlassian.jira.plugin.... ] Ion Savin updated ISPN-2342: ---------------------------- Fix Version/s: 7.0.0.Alpha3 (was: 7.0.0.Alpha2) > Cross-Site Replication: State Transfer between sites > ---------------------------------------------------- > > Key: ISPN-2342 > URL: https://issues.jboss.org/browse/ISPN-2342 > Project: Infinispan > Issue Type: Feature Request > Components: Cross-Site Replication > Affects Versions: 6.0.1.Final > Reporter: Erik Salter > Assignee: Pedro Ruivo > Labels: roadmap > Fix For: 7.0.0.Alpha3, 7.0.0.Final > > > To bring up a new site or recover a failed site, I need an inter-site state transfer mechanism for synchronizing keys. > Note that initially, this should a manual process that is invoked on one site to one of its configured backups. > This should be based on the non-blocking state transfer mechanism for consistency. > The pseudo-design may look similar to the following: > - Manually invokable, background thread > - Since the bridge end is open, there are writes happening to keys. Keep track of the puts/removes on the main data owner. > - Iterate through the key set. > - If the key has already been modified since the process started, discard. > - Else synchronously write the key value in a TX context -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-2240) Per-key lock container leads to superfluous TimeoutExceptions on concurrent access to same key

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-2240?page=com.atlassian.jira.plugin.... ] Ion Savin updated ISPN-2240: ---------------------------- Fix Version/s: 7.0.0.Alpha3 (was: 7.0.0.Alpha2) > Per-key lock container leads to superfluous TimeoutExceptions on concurrent access to same key > ---------------------------------------------------------------------------------------------- > > Key: ISPN-2240 > URL: https://issues.jboss.org/browse/ISPN-2240 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.1.6.FINAL, 5.1.x > Reporter: Robert Stupp > Assignee: Mircea Markus > Priority: Critical > Fix For: 7.0.0.Alpha3, 7.0.0.Final > > Attachments: ISPN-2240_fix_TimeoutExceptions.patch, somehow.zip > > > Hi, > I've encountered a lot of TimeoutExceptions just running a load test against an infinispan cluster. > I tracked down the reason and found out, that the code in org.infinispan.util.concurrent.locks.containers.AbstractPerEntryLockContainer#releaseLock() causes these superfluous TimeoutExceptions. > A small test case (which just prints out timeouts, too late timeouts and "paints" a lot of dots to the console - more dots/second on the console means better throughput ;-) > In a short test I extended the class ReentrantPerEntryLockContainer and changed the implementation of releaseLock() as follows: > {noformat} > public void releaseLock(Object lockOwner, Object key) { > ReentrantLock l = locks.get(key); > if (l != null) { > if (!l.isHeldByCurrentThread()) > throw new IllegalStateException("Lock for [" + key + "] not held by current thread " + Thread.currentThread()); > while (l.isHeldByCurrentThread()) > unlock(l, lockOwner); > if (!l.hasQueuedThreads()) > locks.remove(key); > } > else > throw new IllegalStateException("No lock for [" + key + ']'); > } > {noformat} > The main improvement is that locks are not removed from the concurrent map as long as other threads are waiting on that lock. > If the lock is removed from the map while other threads are waiting for it, they may run into timeouts and force TimeoutExceptions to the client. > The above methods "paints more dots per second" - means: it gives a better throughput for concurrent accesses to the same key. > The re-implemented method should also fix some replication timeout exceptions. > Please, please add this to 5.1.7, if possible. -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-2577) Silence SuspectExceptions

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-2577?page=com.atlassian.jira.plugin.... ] Ion Savin updated ISPN-2577: ---------------------------- Fix Version/s: 7.0.0.Alpha3 (was: 7.0.0.Alpha2) > Silence SuspectExceptions > ------------------------- > > Key: ISPN-2577 > URL: https://issues.jboss.org/browse/ISPN-2577 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 5.2.0.Beta4, 6.0.0.Final > Reporter: Michal Linhard > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.0.0.Alpha3, 7.0.0.Final > > > There are lots of SuspectExceptions in resilience test run: > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EDG6/view/EDG-REPOR... > We managed to keep these under cover for 5.1.x branch. > This is of course a cosmetic problem, but it polutes the log with unnecessary ERRORs. > Parsed logs here: > http://www.qa.jboss.com/~mlinhard/test_results/run54-parsed/ -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-2820) POST request with multipart/form-data encoding stores wrong content type

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-2820?page=com.atlassian.jira.plugin.... ] Ion Savin updated ISPN-2820: ---------------------------- Fix Version/s: 7.0.0.Alpha3 (was: 7.0.0.Alpha2) > POST request with multipart/form-data encoding stores wrong content type > ------------------------------------------------------------------------ > > Key: ISPN-2820 > URL: https://issues.jboss.org/browse/ISPN-2820 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 5.2.1.Final > Reporter: Dan Berindei > Assignee: Tristan Tarrant > Fix For: 7.0.0.Alpha3 > > > The REST server uses the {{Content-Type}} header of the POST request to determine the content type of the stored entry. But with {{Content-Type: multipart/form-data}}, each parameter can have its own content type (and {{multipart/form-data}} is definitely not any parameter's content type). > This seems to be the way to do get the content type of each parameter: http://www.mkyong.com/webservices/jax-rs/file-upload-example-in-resteasy/ -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-2958) Lucene Directory Read past EOF

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-2958?page=com.atlassian.jira.plugin.... ] Ion Savin updated ISPN-2958: ---------------------------- Fix Version/s: 7.0.0.Alpha3 (was: 7.0.0.Alpha2) > Lucene Directory Read past EOF > ------------------------------ > > Key: ISPN-2958 > URL: https://issues.jboss.org/browse/ISPN-2958 > Project: Infinispan > Issue Type: Bug > Components: Lucene Directory > Affects Versions: 5.2.1.Final > Reporter: Clement Pang > Assignee: Pedro Ruivo > Labels: retest, stable_embedded_query > Fix For: 7.0.0.Alpha3 > > > This seems to be happening rather deterministically. > Infinispan configuration (in JBoss EAP 6.1.0.Alpha): > {code} > <cache-container name="lucene"> > <local-cache name="dshell-index-data" start="EAGER"> > <eviction strategy="LIRS" max-entries="50000"/> > <file-store path="lucene" passivation="true" purge="false"/> > </local-cache> > <local-cache name="dshell-index-metadata" start="EAGER"> > <file-store path="lucene" passivation="true" purge="false"/> > </local-cache> > <local-cache name="dshell-index-lock" start="EAGER"> > <file-store path="lucene" passivation="true" purge="false"/> > </local-cache> > </cache-container> > {code} > Upon shutting down the server and confirming that passivation did indeed write the data to disk, the subsequent start-up would fail right away with: > {code} > Caused by: org.hibernate.search.SearchException: Could not initialize index > at org.hibernate.search.store.impl.DirectoryProviderHelper.initializeIndexIfNeeded(DirectoryProviderHelper.java:162) > at org.hibernate.search.infinispan.impl.InfinispanDirectoryProvider.start(InfinispanDirectoryProvider.java:103) > at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:104) > at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:227) > ... 64 more > Caused by: java.io.IOException: Read past EOF > at org.infinispan.lucene.SingleChunkIndexInput.readByte(SingleChunkIndexInput.java:77) > at org.apache.lucene.store.ChecksumIndexInput.readByte(ChecksumIndexInput.java:41) > at org.apache.lucene.store.DataInput.readInt(DataInput.java:86) > at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:272) > at org.apache.lucene.index.IndexFileDeleter.<init>(IndexFileDeleter.java:182) > at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:1168) > at org.hibernate.search.store.impl.DirectoryProviderHelper.initializeIndexIfNeeded(DirectoryProviderHelper.java:157) > ... 67 more > {code} -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-2857) Support asynchronous listeners and events with old values for JSR-107

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-2857?page=com.atlassian.jira.plugin.... ] Ion Savin updated ISPN-2857: ---------------------------- Fix Version/s: 7.0.0.Alpha3 (was: 7.0.0.Alpha2) > Support asynchronous listeners and events with old values for JSR-107 > ---------------------------------------------------------------------- > > Key: ISPN-2857 > URL: https://issues.jboss.org/browse/ISPN-2857 > Project: Infinispan > Issue Type: Sub-task > Components: JCache, Listeners > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Alpha3 > > > These parts of the JSR-107 listener section are not currently tested by the TCK (version 0.6) -- 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

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2014