November 2011 - infinispan-issues

[JBoss JIRA] (ISPN-1515) A Weld upgrade is needed

by Kevin Pollet (Created) (JIRA)

A Weld upgrade is needed ------------------------ Key: ISPN-1515 URL: https://issues.jboss.org/browse/ISPN-1515 Project: Infinispan Issue Type: Component Upgrade Components: CDI integration Reporter: Kevin Pollet Assignee: Kevin Pollet Because of new class hierarchy and co-variant return (see BasicCacheContainer and CacheContainer) the Infinispan CDI support won't work until WELD-1006 is fixed. -- 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

13 years, 10 months

3
3
0 / 0

[JBoss JIRA] (ISPN-1510) The memcached cache state transfer fails in EDG domain mode

by Dan Berindei (Created) (JIRA)

The memcached cache state transfer fails in EDG domain mode ----------------------------------------------------------- Key: ISPN-1510 URL: https://issues.jboss.org/browse/ISPN-1510 Project: Infinispan Issue Type: Bug Components: State transfer Reporter: Dan Berindei Assignee: Galder Zamarreño Priority: Critical Start EDG with the default bin/domain.sh. You will get this error on the console: {noformat} [Server:server-one] 08:20:53,204 ERROR [org.infinispan.cacheviews.CacheViewsManagerImpl] (CacheViewInstaller-1,server-one/default) ISPN000166: View installation failed for cache memcachedCache: java.lang.NullPointerException [Server:server-one] at org.infinispan.util.hash.MurmurHash3.hash(MurmurHash3.java:291) [infinispan-core-5.1.0-SNAPSHOT.jar:5.1.0-SNAPSHOT] [Server:server-one] at org.infinispan.distribution.ch.AbstractWheelConsistentHash.getNormalizedHash(AbstractWheelConsistentHash.java:240) [infinispan-core-5.1.0-SNAPSHOT.jar:5.1.0-SNAPSHOT] [Server:server-one] at org.infinispan.distribution.ch.AbstractWheelConsistentHash.setCaches(AbstractWheelConsistentHash.java:117) [infinispan-core-5.1.0-SNAPSHOT.jar:5.1.0-SNAPSHOT] [Server:server-one] at org.infinispan.distribution.ch.ConsistentHashHelper.createConsistentHash(ConsistentHashHelper.java:117) [infinispan-core-5.1.0-SNAPSHOT.jar:5.1.0-SNAPSHOT] [Server:server-one] at org.infinispan.statetransfer.DistributedStateTransferManagerImpl.createConsistentHash(DistributedStateTransferManagerImpl.java:75) [infinispan-core-5.1.0-SNAPSHOT.jar:5.1.0-SNAPSHOT] [Server:server-one] at org.infinispan.statetransfer.BaseStateTransferManagerImpl.prepareView(BaseStateTransferManagerImpl.java:288) [infinispan-core-5.1.0-SNAPSHOT.jar:5.1.0-SNAPSHOT] [Server:server-one] at org.infinispan.cacheviews.CacheViewsManagerImpl.handlePrepareView(CacheViewsManagerImpl.java:440) [infinispan-core-5.1.0-SNAPSHOT.jar:5.1.0-SNAPSHOT] [Server:server-one] at org.infinispan.cacheviews.CacheViewsManagerImpl.clusterPrepareView(CacheViewsManagerImpl.java:288) [infinispan-core-5.1.0-SNAPSHOT.jar:5.1.0-SNAPSHOT] [Server:server-one] at org.infinispan.cacheviews.CacheViewsManagerImpl.clusterInstallView(CacheViewsManagerImpl.java:242) [infinispan-core-5.1.0-SNAPSHOT.jar:5.1.0-SNAPSHOT] [Server:server-one] at org.infinispan.cacheviews.CacheViewsManagerImpl$ViewInstallationTask.call(CacheViewsManagerImpl.java:802) [infinispan-core-5.1.0-SNAPSHOT.jar:5.1.0-SNAPSHOT] [Server:server-one] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [:1.6.0_23] [Server:server-one] at java.util.concurrent.FutureTask.run(FutureTask.java:166) [:1.6.0_23] [Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [:1.6.0_23] [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [:1.6.0_23] [Server:server-one] at java.lang.Thread.run(Thread.java:679) [:1.6.0_23] {noformat} Looks like the HashSeed implementation returns null for some addresses. -- 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

13 years, 10 months

4
5
0 / 0

[JBoss JIRA] Created: (ISPN-689) Read past EOF caused in Lucene Directory when Lucene flushes but doesn't close the segment

by Sanne Grinovero (JIRA)

Read past EOF caused in Lucene Directory when Lucene flushes but doesn't close the segment ------------------------------------------------------------------------------------------ Key: ISPN-689 URL: https://jira.jboss.org/browse/ISPN-689 Project: Infinispan Issue Type: Bug Components: Lucene Directory Affects Versions: 4.2.0.ALPHA2, 4.1.0.Final Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 4.2.0.BETA1, 4.2.0.Final, 5.0.0.Final While this is not the default access scenario performed by Lucene it's possible in some branches to flush the segment and be able to read it before the close. I could reproduce the following stacktrace in high load / huge sized index but not in a unit test; disabling the batching started between .flush() and .close() seems to resolve the issue; also this batch seems totally useless as I couldn't find any chance in performance when disabling it. java.io.IOException: Read past EOF: Chunk value could not be found for key _ni.fdt|4|issues at org.infinispan.lucene.InfinispanIndexInput.setBufferToCurrentChunk(InfinispanIndexInput.java:138) at org.infinispan.lucene.InfinispanIndexInput.nextChunk(InfinispanIndexInput.java:131) at org.infinispan.lucene.InfinispanIndexInput.readBytes(InfinispanIndexInput.java:96) at org.apache.lucene.store.IndexInput.readBytes(IndexInput.java:61) at org.apache.lucene.index.CompoundFileWriter.copyFile(CompoundFileWriter.java:228) at org.apache.lucene.index.CompoundFileWriter.close(CompoundFileWriter.java:184) at org.apache.lucene.index.IndexWriter.flushDocStores(IndexWriter.java:2342) at org.apache.lucene.index.IndexWriter.doFlushInternal(IndexWriter.java:4359) at org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:4264) at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:4255) at org.apache.lucene.index.IndexWriter.prepareCommit(IndexWriter.java:4133) at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:4206) at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:4179) -- 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

13 years, 10 months

5
6
0 / 0

[JBoss JIRA] (ISPN-1520) IllegalAccessError when running Infinispan servers within AS7

by Galder Zamarreño (Created) (JIRA)

IllegalAccessError when running Infinispan servers within AS7 ------------------------------------------------------------- Key: ISPN-1520 URL: https://issues.jboss.org/browse/ISPN-1520 Project: Infinispan Issue Type: Bug Components: Cache Server Affects Versions: 5.1.0.BETA2 Reporter: Galder Zamarreño Assignee: Galder Zamarreño Priority: Blocker Fix For: 5.1.0.BETA5 Apparently package protected access does not work between classloaders, so Infinispan servers are not currently usable in EDG! 17:13:35,468 WARNING [org.jboss.netty.channel.DefaultChannelPipeline] (HotRodServerWorker-2-1) An exception was thrown by a user handler while handling an exception event ([id: 0x02916ab8, /127.0.0.1:58211 => /127.0.0.1:11222] EXCEPTION: java.lang.IllegalAccessError: tried to access class org.jboss.netty.handler.codec.replay.UnsafeDynamicChannelBuffer from class org.jboss.netty.handler.codec.replay.CustomReplayingDecoder): java.lang.NullPointerException at org.jboss.netty.handler.codec.replay.CustomReplayingDecoder.slimDownBuffer(CustomReplayingDecoder.java:178) [infinispan-server-core-5.1.0-SNAPSHOT.jar:5.1.0-SNAPSHOT] Forget about the NPE, the root cause is the IllegalAccessError. There're different avenues to get around the issue... I'm starting a dev thread on this. -- 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

13 years, 11 months

6
5
0 / 0

[JBoss JIRA] (ISPN-1518) Log the Infinispan version information once

by Randall Hauch (Created) (JIRA)

Log the Infinispan version information once ------------------------------------------- Key: ISPN-1518 URL: https://issues.jboss.org/browse/ISPN-1518 Project: Infinispan Issue Type: Feature Request Affects Versions: 5.1.0.BETA4 Reporter: Randall Hauch Assignee: Manik Surtani Priority: Minor When running unit tests for a system that uses Infinispan, the log is filled with the following messages: {code} INFO ISPN000128: Infinispan version: Infinispan 'Brahma' 5.1.0.BETA4 {code} It looks like this may be logged each time an Infinispan cache manager is instantiated, but it would be really nice if this were done only once, perhaps in a static initializer for one of the classes. This would likely mean little change for production systems. -- 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

13 years, 11 months

3
2
0 / 0

[JBoss JIRA] (ISPN-1498) DistributedStateTransferManagerImpl doesn't export it's JMX operations and attributes

by Michal Linhard (Created) (JIRA)

DistributedStateTransferManagerImpl doesn't export it's JMX operations and attributes ------------------------------------------------------------------------------------- Key: ISPN-1498 URL: https://issues.jboss.org/browse/ISPN-1498 Project: Infinispan Issue Type: Bug Components: JMX, reporting and management Affects Versions: 5.1.0.BETA3 Reporter: Michal Linhard Assignee: Manik Surtani Priority: Critical methods like public boolean org.infinispan.statetransfer.BaseStateTransferManagerImpl.isJoinComplete() public boolean org.infinispan.statetransfer.BaseStateTransferManagerImpl.isStateTransferInProgress() are not exposed via JMX, the annotation @ManagedAttribute from StateTransferManager is not picked up when introspecting the object in ResourceDMBean. -- 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

13 years, 11 months

6
6
0 / 0

[JBoss JIRA] (ISPN-1512) Optimisation: reduce the number of RPCs when using pessimistic locking

by Mircea Markus (Created) (JIRA)

Optimisation: reduce the number of RPCs when using pessimistic locking ---------------------------------------------------------------------- Key: ISPN-1512 URL: https://issues.jboss.org/browse/ISPN-1512 Project: Infinispan Issue Type: Feature Request Affects Versions: 5.0.1.FINAL Reporter: Mircea Markus Assignee: Mircea Markus Fix For: 5.1.0.BETA4 Right now, with pessimistic locking: TransactionManager.begin() Object k = cache.put(k,v); //this performs two RPCs to same nodes: a ClusterGetCommand and an LockControlCommand. The two RPCs can be merged together. Whilst this is an optimisation, it is quite an important one as it has an major impact on performance on every put. -- 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

13 years, 11 months

4
4
0 / 0

[JBoss JIRA] Created: (ISPN-1132) Locking optimization: reorder lock acquisition to avoid deadlocks

by Mircea Markus (JIRA)

Locking optimization: reorder lock acquisition to avoid deadlocks ------------------------------------------------------------------- Key: ISPN-1132 URL: https://issues.jboss.org/browse/ISPN-1132 Project: Infinispan Issue Type: Feature Request Components: Transactions Reporter: Mircea Markus Assignee: Manik Surtani Fix For: 5.1.0.Final Detailed here, as the 3rd improvement: http://community.jboss.org/wiki/PossibleLockingImprovements -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

4
12
0 / 0

[JBoss JIRA] (ISPN-1516) GUI demo not working

by Galder Zamarreño (Created) (JIRA)

GUI demo not working -------------------- Key: ISPN-1516 URL: https://issues.jboss.org/browse/ISPN-1516 Project: Infinispan Issue Type: Bug Components: Demos and Tutorials Affects Versions: 5.1.0.BETA4 Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.1.0.BETA5 hey - I just downloaded this. I think there's a problem with the runGUI demo. Did it change recently? I had to change the launch script from add_classpath "${ISPN_HOME}/modules/gui" to add_classpath "${ISPN_HOME}/modules/demos/gui" -- 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

13 years, 11 months

4
4
0 / 0

[JBoss JIRA] (ISPN-61) Transaction 2-phase protocol optimizations

by Galder Zamarreño (Updated) (JIRA)

[ https://issues.jboss.org/browse/ISPN-61?page=com.atlassian.jira.plugin.sy... ] Galder Zamarreño updated ISPN-61: --------------------------------- Fix Version/s: 5.1.0.BETA5 (was: 5.1.0.BETA4) > Transaction 2-phase protocol optimizations > ------------------------------------------ > > Key: ISPN-61 > URL: https://issues.jboss.org/browse/ISPN-61 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 4.0.0.ALPHA4 > Reporter: Mircea Markus > Assignee: Mircea Markus > Priority: Critical > Fix For: 5.1.0.BETA5, 5.1.0.FINAL > > > Following 2 optimizations might be implemented with respect to transactions. > 1) From an email on infinispan-dev (horizon-dev actually): > if there are only two members int the cluster always use an 1PC. If the 1st phase fails remotely, then also rollback locally. This would reduce one network roundtrip. > While this is an interesting thought, it does raise the potential for race conditions - since this decision will have to be taken in the TxInterceptor in the beforeCompletion phase of a transaction, and by the time the call gets to the interceptor for replication, the topology may have changed such that you need to replicate to 2 instead of 1 other peer. Which would mean a 2PC again. So it does need some thought. > 2) when asked to prepare, a participant might return a value indicating that no changes were made (read-only participant), so this one won't need an commit message, so less roundtrip. -- 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

13 years, 11 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2011