May 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4325) Change CloseableIterable to use AutoCloseable instead of Closeable

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4325?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4325: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Change CloseableIterable to use AutoCloseable instead of Closeable > ------------------------------------------------------------------ > > Key: ISPN-4325 > URL: https://issues.jboss.org/browse/ISPN-4325 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Beta1 > > > Now that ISPN requires Java 7 we should change CloseableIterable and CloseableIterator to instead implement AutoCloseable instead of Closeable. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4328) Upgrade JGroups to 3.5.0.Beta7

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-4328: --------------------------------- Summary: Upgrade JGroups to 3.5.0.Beta7 Key: ISPN-4328 URL: https://issues.jboss.org/browse/ISPN-4328 Project: Infinispan Issue Type: Component Upgrade Reporter: Pedro Ruivo Assignee: Pedro Ruivo Fix For: 7.0.0.Beta1 -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4327) Upgrade to Apache Lucene 4.8.1

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4327?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4327: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.0.0.Beta1 (was: 7.0.0.Alpha5) Resolution: Done > Upgrade to Apache Lucene 4.8.1 > ------------------------------ > > Key: ISPN-4327 > URL: https://issues.jboss.org/browse/ISPN-4327 > Project: Infinispan > Issue Type: Component Upgrade > Components: Lucene Directory > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 7.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

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

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2956?page=com.atlassian.jira.plugin.... ] Work on ISPN-2956 started by Galder Zamarreño. > 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.Beta1 > > > 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 was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4108) Pessimistic tx for a union CH will not be forwarded to all owners.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4108?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4108: ----------------------------------------------- Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1102048|https://bugzilla.redhat.com/show_bug.cgi?id=1102048] from NEW to POST > Pessimistic tx for a union CH will not be forwarded to all owners. > ------------------------------------------------------------------ > > Key: ISPN-4108 > URL: https://issues.jboss.org/browse/ISPN-4108 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Affects Versions: 5.2.7.Final > Reporter: Erik Salter > Assignee: Dan Berindei > Fix For: 7.0.0.Beta1 > > > There is a case where transactions originating from a LockControlCommand will not be forwarded to the new owner during state transfer. > If the transactions begin on the old primary owner after the tx list was sent to the new owner, the lock information may not be replicated to the joiner because the originator is still the primary owner in the union CH that we use during state transfer. When state transfer ends and the joiner becomes the new primary owner, it will allow other txs to lock the same key. This leads to data loss/inconsistency. > We should change PessimisticLockingInterceptor to replicate the lock command to the other owners even if the originator is the primary owner when there is a state transfer in progress. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4091) Transactions and data should prefer to be sourced from a primary owner

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4091?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4091: ----------------------------------------------- Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1102048|https://bugzilla.redhat.com/show_bug.cgi?id=1102048] from NEW to POST > Transactions and data should prefer to be sourced from a primary owner > ---------------------------------------------------------------------- > > Key: ISPN-4091 > URL: https://issues.jboss.org/browse/ISPN-4091 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Affects Versions: 5.2.7.Final > Reporter: Erik Salter > Assignee: Dan Berindei > Fix For: 7.0.0.Beta1 > > > The current state transfer mechanism will ask the backup segments for transaction and state information. However, this breaks if there is a pessimistic transaction executing on the primary data owner, Consider the following use case: > A new owner joins and sources the ongoing transactions and data for key k from the backup. Meanwhile, a local transaction has started on the primary owner for k, but has not prepared on any remote nodes. So the new node does not know about the ongoing transaction. While that's going on, a new tx starts on the new owner. Since these are pessimistic, the new transaction will acquires the lock for the same key. > So we can have data inconsistency. > The state transfer mechanism should prefer to source the transaction and state information from the primary owner. This should cover all cases: if the originator is not the primary owner, then any (backup) locks must be replicated to all the owners, either directly during the tx or during a previous state transfer. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4293) PR for ISPN-4137 causes a performance drop in repl tx mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4293?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4293: ----------------------------------------------- Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1098463|https://bugzilla.redhat.com/show_bug.cgi?id=1098463] from NEW to POST > PR for ISPN-4137 causes a performance drop in repl tx mode > ---------------------------------------------------------- > > Key: ISPN-4293 > URL: https://issues.jboss.org/browse/ISPN-4293 > Project: Infinispan > Issue Type: Bug > Reporter: Jakub Markos > Assignee: Dan Berindei > Fix For: 7.0.0.Beta1 > > > See the last graph here for example http://jawa36.mw.lab.eng.brq.redhat.com:8080/repo/reports/metric/saved/te... > Caused by this commit https://github.com/infinispan/infinispan/commit/8be817a193699ce8b59aec8da... -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4224) Kerberos auth IT fails on JDK8

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4224?page=com.atlassian.jira.plugin.... ] Tristan Tarrant commented on ISPN-4224: --------------------------------------- Would be interesting to get a log from the LDAP server side. > Kerberos auth IT fails on JDK8 > ------------------------------ > > Key: ISPN-4224 > URL: https://issues.jboss.org/browse/ISPN-4224 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Reporter: Vojtech Juranek > Assignee: Vojtech Juranek > > [Kerberos auth integration test|https://github.com/infinispan/infinispan/blob/master/integrationtest...] passes on JDK7, but fails on JDK8 with > {noformat} > Caused by: javax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "deployment.b5efb5d4-0f0d-448f-b60f-e8bd15023ebd.war:main" from Service Module Loader [Root exception is javax.naming.CommunicationException: Request: 1 cancelled] > at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:116) > at org.jboss.as.naming.InitialContext.init(InitialContext.java:99) > at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:153) > at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:90) > at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:44) > at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) > at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) > at javax.naming.InitialContext.init(InitialContext.java:242) > at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:153) > at org.jboss.security.negotiation.AdvancedLdapLoginModule.constructLdapContext(AdvancedLdapLoginModule.java:431) > ... 109 more > Caused by: javax.naming.CommunicationException: Request: 1 cancelled > at com.sun.jndi.ldap.LdapRequest.getReplyBer(LdapRequest.java:105) > at com.sun.jndi.ldap.Connection.readReply(Connection.java:449) > at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:364) > at com.sun.jndi.ldap.sasl.LdapSasl.saslBind(LdapSasl.java:126) > at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:235) > at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2740) > at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316) > at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193) > at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211) > at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154) > at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84) > at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114) > ... 118 more > {noformat} -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4091) Transactions and data should prefer to be sourced from a primary owner

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4091?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4091: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1102048 > Transactions and data should prefer to be sourced from a primary owner > ---------------------------------------------------------------------- > > Key: ISPN-4091 > URL: https://issues.jboss.org/browse/ISPN-4091 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Affects Versions: 5.2.7.Final > Reporter: Erik Salter > Assignee: Dan Berindei > Fix For: 7.0.0.Beta1 > > > The current state transfer mechanism will ask the backup segments for transaction and state information. However, this breaks if there is a pessimistic transaction executing on the primary data owner, Consider the following use case: > A new owner joins and sources the ongoing transactions and data for key k from the backup. Meanwhile, a local transaction has started on the primary owner for k, but has not prepared on any remote nodes. So the new node does not know about the ongoing transaction. While that's going on, a new tx starts on the new owner. Since these are pessimistic, the new transaction will acquires the lock for the same key. > So we can have data inconsistency. > The state transfer mechanism should prefer to source the transaction and state information from the primary owner. This should cover all cases: if the originator is not the primary owner, then any (backup) locks must be replicated to all the owners, either directly during the tx or during a previous state transfer. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4108) Pessimistic tx for a union CH will not be forwarded to all owners.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4108?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4108: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1102048 > Pessimistic tx for a union CH will not be forwarded to all owners. > ------------------------------------------------------------------ > > Key: ISPN-4108 > URL: https://issues.jboss.org/browse/ISPN-4108 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Affects Versions: 5.2.7.Final > Reporter: Erik Salter > Assignee: Dan Berindei > Fix For: 7.0.0.Beta1 > > > There is a case where transactions originating from a LockControlCommand will not be forwarded to the new owner during state transfer. > If the transactions begin on the old primary owner after the tx list was sent to the new owner, the lock information may not be replicated to the joiner because the originator is still the primary owner in the union CH that we use during state transfer. When state transfer ends and the joiner becomes the new primary owner, it will allow other txs to lock the same key. This leads to data loss/inconsistency. > We should change PessimisticLockingInterceptor to replicate the lock command to the other owners even if the originator is the primary owner when there is a state transfer in progress. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2014