May 2012 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2053) Memcached server occasionally does not consume CR/LF after data block

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-2053: ------------------------------------- Summary: Memcached server occasionally does not consume CR/LF after data block Key: ISPN-2053 URL: https://issues.jboss.org/browse/ISPN-2053 Project: Infinispan Issue Type: Bug Components: Cache Server Affects Versions: 5.1.5.CR1 Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 5.1.5.FINAL The memcached server sometimes "forgets" to read the ending CR/LF after value payloads. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

3
14
0 / 0

[JBoss JIRA] (ISPN-1995) Uneven request balancing after node restore

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-1995: ------------------------------------- Summary: Uneven request balancing after node restore Key: ISPN-1995 URL: https://issues.jboss.org/browse/ISPN-1995 Project: Infinispan Issue Type: Bug Components: Cache Server Affects Versions: 5.1.4.CR1 Reporter: Tristan Tarrant Assignee: Galder Zamarreño After a node crashes and rejoins the cluster, it does not receive client load at the same level as the other nodes. This issue does not affect data integrity and distribution in the cluster. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

4
54
0 / 0

[JBoss JIRA] (ISPN-2083) Configuration adaptor is ignoring properties for CacheLoaders

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-2083: ------------------------------------- Summary: Configuration adaptor is ignoring properties for CacheLoaders Key: ISPN-2083 URL: https://issues.jboss.org/browse/ISPN-2083 Project: Infinispan Issue Type: Bug Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 5.2.0.ALPHA1 When a _CacheLoaderConfig_ is used which is not also a _CacheStoreConfig_, the LegacyConfigurationAdaptor is not setting the configured properties on the CacheLoader -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

2
2
0 / 0

[JBoss JIRA] (ISPN-2084) Use an existing Lucene index directly as a CacheLoader source

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-2084: ------------------------------------- Summary: Use an existing Lucene index directly as a CacheLoader source Key: ISPN-2084 URL: https://issues.jboss.org/browse/ISPN-2084 Project: Infinispan Issue Type: Enhancement Components: Lucene Directory Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 5.2.0.ALPHA1 It's pretty easy to _copy_ a Lucene index into Infinispan, but it would be much nicer to just have it point to an existing index on a filesystem and use Infinispan as a thin layer on top of it; this would also allow for easy replication of changes. This is initially going to be a _CacheLoader_ only, so meant for a read-only index. Shouldn't be hard to adapt the logic to allow for write-through in the future. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

2
2
0 / 0

[JBoss JIRA] (ISPN-2040) Workaround for transactional misbehaviour of JDBC store with ManagedConnectionPool

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-2040: ------------------------------------- Summary: Workaround for transactional misbehaviour of JDBC store with ManagedConnectionPool Key: ISPN-2040 URL: https://issues.jboss.org/browse/ISPN-2040 Project: Infinispan Issue Type: Bug Affects Versions: 5.1.4.FINAL Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 5.1.x JTA transactions should be suspended when interacting with the JDBC store configured against a transactional ManagedConnectionPool -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

3
7
0 / 0

[JBoss JIRA] Created: (ISPN-586) ManagedConnectionPool doesn't work in a transactional context

by Manik Surtani (JIRA)

ManagedConnectionPool doesn't work in a transactional context ------------------------------------------------------------- Key: ISPN-586 URL: https://jira.jboss.org/browse/ISPN-586 Project: Infinispan Issue Type: Bug Components: Loaders and Stores, Transactions Affects Versions: 4.1.0.CR2 Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.CR3 >From the reporter: "Anyways, what seems to be the real problem is that all the things that need to be persisted are saved in memory and then when the transaction is completing (either in prepare or commit phase) the loader attempts to get a connection from the datasource. Apparently this is illegal and throws an exception which is what causes the HeuristicMixedException further up the chain. This only fails when using a ManagedConnectionFactory. If I swap out a PooledConnectionFactory it works fine. I presume the managed version fails because it returns the same connection that is part of the active transaction for that thread and you can't perform new operations on that connection once the transaction is already in prepare or commit. This feels like a bit of a design flaw to me... I didn't see an obvious fix." This possibly has to do with the AbstractCacheStore doing the following in prepare(): " public void prepare(List<? extends Modification> mods, GlobalTransaction tx, boolean isOnePhase) throws CacheLoaderException { if (isOnePhase) { applyModifications(mods); } else { transactions.put(tx, mods); } } " and later during commit actually writing the changes to the store. This generic, "abstract" behaviour is intended for non-transactional data stores (such as a filesystem). Behaviour should be different when it comes to transactional data stores. -- 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

11 years, 10 months

8
25
0 / 0

[JBoss JIRA] (ISPN-1610) Timeouts waiting for StateTransferLock

by Tristan Tarrant (Created) (JIRA)

Timeouts waiting for StateTransferLock -------------------------------------- Key: ISPN-1610 URL: https://issues.jboss.org/browse/ISPN-1610 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 5.1.0.CR1 Reporter: Tristan Tarrant Assignee: Dan Berindei In a four node performance tests we're seeing these exceptions during cluster startup: org.infinispan.distribution.StateTransferInProgressException: Timed out waiting for the state transfer lock, state transfer in progress for view X The timeout is set to the default 1min. It's quite suspicious that a state transfer takes that long ( > 1min) since caches are empty. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

6
29
0 / 0

[JBoss JIRA] (ISPN-1799) We should avoid using exceptions for flow control when acquiring state transfer lock

by Dan Berindei (JIRA)

Dan Berindei created ISPN-1799: ---------------------------------- Summary: We should avoid using exceptions for flow control when acquiring state transfer lock Key: ISPN-1799 URL: https://issues.jboss.org/browse/ISPN-1799 Project: Infinispan Issue Type: Task Components: State transfer Affects Versions: 5.1.0.FINAL Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 5.2.0.FINAL We currently use `StateTransferInProgressException` as a marker that a write command failed to acquire the state transfer lock and it should be retried. With ISPN-1704 I added another exception, StateTransferLockReacquisitionException, to signal that a write command failed to re-acquire the state transfer lock after it had already acquired it. These exceptions often appear in the logs and confuse users (see ISPN-1610), so it would be best to use special return values. We may also need a flag in the InvocationContext for StateTransferLockReacquisitionException. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

7
28
0 / 0

[JBoss JIRA] (ISPN-1876) clustered query is not executed on the right cache

by Mathieu Lachance (JIRA)

Mathieu Lachance created ISPN-1876: -------------------------------------- Summary: clustered query is not executed on the right cache Key: ISPN-1876 URL: https://issues.jboss.org/browse/ISPN-1876 Project: Infinispan Issue Type: Bug Components: Querying, RPC Affects Versions: 5.1.1.FINAL Reporter: Mathieu Lachance Assignee: Sanne Grinovero when using clustered query, command is not executed on the right cache. when debuging, in CommandAwareRpcDispatcher::executeCommand() cmd = ClusteredQuery{cache="the-good-cache-name"} cmd.cache = "the-bad-cache-name" cmd.cacheName = "the-good-cache-name" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

3
2
0 / 0

[JBoss JIRA] (ISPN-2070) Upgrade to a Netty version that fixes a problem with cumulable buffer

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-2070: -------------------------------------- Summary: Upgrade to a Netty version that fixes a problem with cumulable buffer Key: ISPN-2070 URL: https://issues.jboss.org/browse/ISPN-2070 Project: Infinispan Issue Type: Component Upgrade Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.2.0.FINAL To be precise: https://gist.github.com/2818147 That should be fixed with: https://github.com/netty/netty/commit/80df72843bae169a2c1a4362ebdd05466d7... (https://github.com/netty/netty/issues/364) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

3
9
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2012