June 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4398) Hot Rod server event results in connection/class leak

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-4398: -------------------------------------- Summary: Hot Rod server event results in connection/class leak Key: ISPN-4398 URL: https://issues.jboss.org/browse/ISPN-4398 Project: Infinispan Issue Type: Bug Security Level: Public (Everyone can see) Components: Remote Protocols Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 7.0.0.Alpha5 On linux systems, running Hot Rod server testsuite results in {code}Caused by: java.io.IOException: Too many open files{code} errors. These were introduced when remote events was integrated. There's a leak when listener is removed, the eventSenders in ClientListenerRegistry is not updated to remove it. The channel should be closed client side. Needs investigating further. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4396) DSL Query: right condition lost

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4396?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4396: ----------------------------------------------- Adrian Nistor <anistor(a)redhat.com> changed the Status of [bug 1108695|https://bugzilla.redhat.com/show_bug.cgi?id=1108695] from NEW to POST > DSL Query: right condition lost > ------------------------------- > > Key: ISPN-4396 > URL: https://issues.jboss.org/browse/ISPN-4396 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Embedded Querying > Affects Versions: 7.0.0.Alpha4 > Reporter: Radim Vansa > Assignee: Adrian Nistor > > Condition created through query like this: > {code} > Query q = qf.from(User.class) > .not( > qf.having("name").eq("John") > .or(qf.having("surname").eq("Man"))) > .toBuilder().build(); > {code} > is not correctly parsed into JPQL query; it is > {code} > FROM org.infinispan.query.dsl.embedded.sample_domain_model.User _gen0 WHERE NOT (_gen0.name = 'John') > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4395) Query tests slow

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-4395?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-4395: ------------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2635 > Query tests slow > ---------------- > > Key: ISPN-4395 > URL: https://issues.jboss.org/browse/ISPN-4395 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Test Suite - Query > Affects Versions: 7.0.0.Alpha4 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > > Mailing list discussion: http://lists.jboss.org/pipermail/infinispan-dev/2014-June/015062.html -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4396) DSL Query: right condition lost

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-4396?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-4396: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2634 > DSL Query: right condition lost > ------------------------------- > > Key: ISPN-4396 > URL: https://issues.jboss.org/browse/ISPN-4396 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Embedded Querying > Affects Versions: 7.0.0.Alpha4 > Reporter: Radim Vansa > Assignee: Adrian Nistor > > Condition created through query like this: > {code} > Query q = qf.from(User.class) > .not( > qf.having("name").eq("John") > .or(qf.having("surname").eq("Man"))) > .toBuilder().build(); > {code} > is not correctly parsed into JPQL query; it is > {code} > FROM org.infinispan.query.dsl.embedded.sample_domain_model.User _gen0 WHERE NOT (_gen0.name = 'John') > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4387) Write Skew Check does not work with Passivation

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4387?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4387: ------------------------------ Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2633 > Write Skew Check does not work with Passivation > ----------------------------------------------- > > Key: ISPN-4387 > URL: https://issues.jboss.org/browse/ISPN-4387 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Transactions > Affects Versions: 7.0.0.Alpha4 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 7.0.0.Alpha5 > > > Write Skew Check does not perform the validation correctly when Passivation is enabled. > Issue: > The current implementation checks the most recent version/value in DataContainer. However, the entry may be passivated and it is not present in DataContainer. The Write Skew Check will abort the transaction when the transaction read some value (say version V), because it is expecting to find the version V but it does not find the entry. It assumes that the entry was removed and aborts the transaction. > A more dangerous case is when at least two transactions are writing to a new key. The first commits and before the second transaction is prepared, the entry is passivated. In this case, it assumes the entry does not exists and let the second transaction to commit. > Solution: > It needs to try to load the entry from Persistence. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4387) Write Skew Check does not work with Passivation

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4387?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4387: ------------------------------ Fix Version/s: 7.0.0.Alpha5 (was: 7.0.0.Beta1) > Write Skew Check does not work with Passivation > ----------------------------------------------- > > Key: ISPN-4387 > URL: https://issues.jboss.org/browse/ISPN-4387 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Transactions > Affects Versions: 7.0.0.Alpha4 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 7.0.0.Alpha5 > > > Write Skew Check does not perform the validation correctly when Passivation is enabled. > Issue: > The current implementation checks the most recent version/value in DataContainer. However, the entry may be passivated and it is not present in DataContainer. The Write Skew Check will abort the transaction when the transaction read some value (say version V), because it is expecting to find the version V but it does not find the entry. It assumes that the entry was removed and aborts the transaction. > A more dangerous case is when at least two transactions are writing to a new key. The first commits and before the second transaction is prepared, the entry is passivated. In this case, it assumes the entry does not exists and let the second transaction to commit. > Solution: > It needs to try to load the entry from Persistence. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4397) HR server is not able to connect to KDC server

by Vojtech Juranek (JIRA)

Vojtech Juranek created ISPN-4397: ------------------------------------- Summary: HR server is not able to connect to KDC server Key: ISPN-4397 URL: https://issues.jboss.org/browse/ISPN-4397 Project: Infinispan Issue Type: Bug Security Level: Public (Everyone can see) Components: Server Reporter: Vojtech Juranek Assignee: Tristan Tarrant After upgrade to WildFly 8.1 (commit [2eb84c2824d82530e508b2063409b1d22225772d|https://github.com/infinispan/in...]), HotRod server endpoint is not able to connect to KDC server (when kerberos sasl server-context-name name is specified) and startup teh the HR server fails with {noformat} Caused by: javax.security.auth.login.LoginException: Cannot locate KDC at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:763) [rt.jar:1.7.0_45] at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:584) [rt.jar:1.7.0_45] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_45] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_45] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45] at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45] at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784) [rt.jar:1.7.0_45] at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_45] at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698) [rt.jar:1.7.0_45] at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696) [rt.jar:1.7.0_45] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_45] at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695) [rt.jar:1.7.0_45] at javax.security.auth.login.LoginContext.login(LoginContext.java:594) [rt.jar:1.7.0_45] at org.infinispan.server.endpoint.subsystem.ProtocolServerService.getServerSubject(ProtocolServerService.java:235) at org.infinispan.server.endpoint.subsystem.ProtocolServerService.start(ProtocolServerService.java:126) ... 5 more Caused by: KrbException: Cannot locate KDC at sun.security.krb5.Config.getKDCList(Config.java:1236) [rt.jar:1.7.0_45] at sun.security.krb5.KdcComm.send(KdcComm.java:210) [rt.jar:1.7.0_45] at sun.security.krb5.KdcComm.send(KdcComm.java:191) [rt.jar:1.7.0_45] at sun.security.krb5.KrbAsReqBuilder.send(KrbAsReqBuilder.java:319) [rt.jar:1.7.0_45] at sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:364) [rt.jar:1.7.0_45] at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:735) [rt.jar:1.7.0_45] ... 19 more Caused by: KrbException: Generic error (description in e-text) (60) - Unable to locate KDC for realm INFINISPAN.ORG at sun.security.krb5.Config.getKDCFromDNS(Config.java:1333) [rt.jar:1.7.0_45] at sun.security.krb5.Config.getKDCList(Config.java:1209) [rt.jar:1.7.0_45] ... 24 more {noformat} In this case KDC run on port 6088 and it's very likely (more in-depth investigation is needed), that krb client used by server ignores path to krb setup (env. var {{java.security.krb5.conf}}) and tried to connect to port 88. This seems to be a bug in WildFly 8.1. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4310) StateResponse chunk with lastChunk=true from cancelled ST stops receiving data in next ST

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4310?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4310: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.0.0.Alpha5 Resolution: Done > StateResponse chunk with lastChunk=true from cancelled ST stops receiving data in next ST > ----------------------------------------------------------------------------------------- > > Key: ISPN-4310 > URL: https://issues.jboss.org/browse/ISPN-4310 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: State Transfer > Affects Versions: 6.0.2.Final, 7.0.0.Alpha4 > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > Labels: 63gablocker > Fix For: 7.0.0.Alpha5 > > > 1. A requests segment from B (there are multiple chunks) > 2. B sends all chunks, but before A receives them, new topology arrives and A cancels the ST. > 3. Another topology comes and A requests this segment again > 4. A receives the old StateResponseCommand with lastChunk=true and thinks that it got all segments, therefore, it discards further chunks. > Result is inconsistent cluster, and after further rebalances completely lost data. > This ought to be rare, but was repeatedly observed when gracefully stopping coordinator on a 32-node cluster full of data. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4301) Handle storeMetadata=false in JpaStore.process and JpaStore.purge methods

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4301?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4301: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1099156|https://bugzilla.redhat.com/show_bug.cgi?id=1099156] from NEW to MODIFIED > Handle storeMetadata=false in JpaStore.process and JpaStore.purge methods > ------------------------------------------------------------------------- > > Key: ISPN-4301 > URL: https://issues.jboss.org/browse/ISPN-4301 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Loaders and Stores > Affects Versions: 7.0.0.Alpha4 > Reporter: Radim Vansa > Assignee: Dan Berindei > Labels: 63gablocker > > Even when storing metadata is disabled, JpaStore tries to fetch them in process (when ran with fetchMetadata=true) and in purge, the code enumerating and removing the metadata is executed even when there can't be any metadata. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

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

by Emmanuel Bernard (JIRA)

[ https://issues.jboss.org/browse/ISPN-2240?page=com.atlassian.jira.plugin.... ] Emmanuel Bernard commented on ISPN-2240: ---------------------------------------- This issue is also affecting the LEADS project. [~mircea.markus] can you talk to Marcelo Pasin to help him / give him some visibility or workaround. > 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 > Security Level: Public(Everyone can see) > Components: Transactions > Affects Versions: 4.0.0.ALPHA1, 5.1.6.FINAL > Reporter: Robert Stupp > Assignee: Mircea Markus > Priority: Critical > Fix For: 7.0.0.Beta1, 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 was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2014