February 2014 - infinispan-issues

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

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2324?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-2324: ------------------------------- Fix Version/s: 7.0.0.Alpha2 (was: 7.0.0.Alpha1) > 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.Alpha2 > > > 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

10 years, 9 months

1
0
0 / 0

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

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2342?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-2342: ------------------------------- Fix Version/s: 7.0.0.Alpha2 (was: 7.0.0.Alpha1) > 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 > Fix For: 7.0.0.Final, 7.0.0.Alpha2 > > > 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

10 years, 9 months

1
0
0 / 0

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

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2857?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-2857: ------------------------------- Fix Version/s: 7.0.0.Alpha2 (was: 7.0.0.Alpha1) > 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.Alpha2 > > > 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

10 years, 9 months

1
0
0 / 0

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

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2820?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-2820: ------------------------------- Fix Version/s: 7.0.0.Alpha2 (was: 7.0.0.Alpha1) > 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.Alpha2 > > > 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2854) REST server discards Content Encoding information from client

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2854?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-2854: ------------------------------- Fix Version/s: 7.0.0.Alpha2 (was: 7.0.0.Alpha1) > REST server discards Content Encoding information from client > ------------------------------------------------------------- > > Key: ISPN-2854 > URL: https://issues.jboss.org/browse/ISPN-2854 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 5.2.2.Final > Reporter: NadirX > Fix For: 7.0.0.Alpha2 > > > The REST server discards the Content-Encoding header from the client and therefore does not serve it back when the content is being read, possibly causing misinterpretation -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3045) Drop wrappers from RemoteCacheStore once HotRod server supports raw keys/values

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3045?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3045: ------------------------------- Fix Version/s: 7.0.0.Alpha2 (was: 7.0.0.Alpha1) > Drop wrappers from RemoteCacheStore once HotRod server supports raw keys/values > ------------------------------------------------------------------------------- > > Key: ISPN-3045 > URL: https://issues.jboss.org/browse/ISPN-3045 > Project: Infinispan > Issue Type: Task > Components: Remote Protocols > Reporter: NadirX > Assignee: Tristan Tarrant > Fix For: 7.0.0.Alpha2 > > -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3039) Add JCache quickstarts

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3039?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3039: ------------------------------- Fix Version/s: 7.0.0.Alpha2 (was: 7.0.0.Alpha1) > Add JCache quickstarts > ---------------------- > > Key: ISPN-3039 > URL: https://issues.jboss.org/browse/ISPN-3039 > Project: Infinispan > Issue Type: Task > Components: JCache > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Alpha2 > > > Quickstarts should be added to https://github.com/infinispan/infinispan-quickstart so that users can get started quickly with JCache API. -- 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

10 years, 9 months

1
0
0 / 0

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

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2958?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-2958: ------------------------------- Fix Version/s: 7.0.0.Alpha2 (was: 7.0.0.Alpha1) > 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.Alpha2 > > > 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2956) putIfAbsent on Hot Rod Java client doesn't reliably fulfil contract

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2956?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-2956: ------------------------------- Fix Version/s: 7.0.0.Alpha2 (was: 7.0.0.Alpha1) > putIfAbsent on Hot Rod Java client doesn't reliably fulfil contract > ------------------------------------------------------------------- > > Key: ISPN-2956 > URL: https://issues.jboss.org/browse/ISPN-2956 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Minor > Labels: hotrod-java-client, remote-clients > Fix For: 7.0.0.Alpha2 > > > Hot Rod's putIfAbsent might have issues on some edge cases: > {quote}I want to know whether the putting entry already exists in the remote > cache cluster, or not. > I thought that RemoteCache.putIfAbsent() would be useful for that > purpose, i.e., > {code} > if (remoteCache.putIfAbsent(k,v) == null) { > // new entry. > } else { > // k already exists. > } > {code} > But no. > The putIfAbsent() for new entry may return non-null value, if one of the > server crushed while putting. > The behavior is like the following: > 1. Client do putIfAbsent(k,v). > 2. The server receives the request and sends replication requests to > other servers. If the server crushed before completing replication, some > servers own that (k,v), but others not. > 3. Client receives the error. The putIfAbsent() internally retries the > same request to the next server in the cluster server list. > 4. If the next server owns the (k,v), the putIfAbsent() returns the > replicated (k,v) at the step 2, without any error. > So, putIfAbsent() is not reliable for knowing whether the putting entry > is *exactly* new or not. > Does anyone have any idea/workaround for this purpose?{quote} > A workaround is to do this: > {quote}We got a simple solution, which can be applied to our customer's application. > If each value part of putting (k,v) is unique or contains unique value, > the client can do *double check* wether the entry is new. > {code} > val = System.nanoTime(); // or uuid is also useful. > if ((ret = cache.putIfAbsent(key, val)) == null > || ret.equals(val)) { > // new entry, if the return value is just the same. > } else { > // key already exists. > } > {code} > We are proposing this workaround which almost works fine.{quote} > However, this is a bit of a cludge. > Hot Rod should be improved with an operation that allows a version to be passed when entry is created, instead of relying on the client generating it. -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3181) Retrieving entries via REST doesn't work

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3181?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3181: ------------------------------- Fix Version/s: 7.0.0.Alpha2 (was: 7.0.0.Alpha1) > Retrieving entries via REST doesn't work > ---------------------------------------- > > Key: ISPN-3181 > URL: https://issues.jboss.org/browse/ISPN-3181 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 5.3.0.Final > Reporter: Jakub Markos > Assignee: Tristan Tarrant > Fix For: 7.0.0.Alpha2 > > Attachments: console_output.txt, server.log, standalone-dist.xml > > > Retrieving an entry stored via REST fails with 404 http response. > The test is located here: > https://code.engineering.redhat.com/gerrit/gitweb?p=jdg-functional-tests.... > {code:java} > String fullPathKey = fullPathKey(KEY_A); > post(fullPathKey, "data", "application/text"); > HttpResponse resp = get(fullPathKey, "data"); > {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

10 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2014