October 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2999) getCacheEntry not working when distribution gets go remote

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2999?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-2999: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1024923 > getCacheEntry not working when distribution gets go remote > ---------------------------------------------------------- > > Key: ISPN-2999 > URL: https://issues.jboss.org/browse/ISPN-2999 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.5.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Labels: jdg620_dm, jdg62GAblocker > > Assuming the cache contains byte[], you get this exception when calling getCacheEntry(K) for a key not available locally: > {code}org.infinispan.server.hotrod.HotRodException: java.lang.ClassCastException: [B cannot be cast to org.infinispan.container.entries.CacheEntry > at org.infinispan.server.hotrod.HotRodDecoder.createServerException(HotRodDecoder.scala:216) > at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:79) > at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:49) > at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:500) > at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:435) > at org.infinispan.server.core.AbstractProtocolDecoder.messageReceived(AbstractProtocolDecoder.scala:393) > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) > at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88) > at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:107) > at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:313) > at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:88) > at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) > at java.lang.Thread.run(Thread.java:680) > Caused by: java.lang.ClassCastException: [B cannot be cast to org.infinispan.container.entries.CacheEntry > at org.infinispan.CacheImpl.getCacheEntry(CacheImpl.java:299) > at org.infinispan.CacheImpl.getCacheEntry(CacheImpl.java:304) > at org.infinispan.server.core.AbstractProtocolDecoder.get(AbstractProtocolDecoder.scala:287) > at org.infinispan.server.core.AbstractProtocolDecoder.decodeKey(AbstractProtocolDecoder.scala:117) > at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:73) > ... 14 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

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3287) Possible inconsistency with concurrent transactions during state transfer

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3287?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3287: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1024918 > Possible inconsistency with concurrent transactions during state transfer > ------------------------------------------------------------------------- > > Key: ISPN-3287 > URL: https://issues.jboss.org/browse/ISPN-3287 > Project: Infinispan > Issue Type: Bug > Components: Locking and Concurrency, State transfer > Affects Versions: 5.3.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: jdg620_dm, jdg62GAblocker > > It looks like there is a data race between the state transfer thread and a concurrent transaction in EntryWrappingInterceptor.commitEntryIfNeeded: > tx: commitContextEntry() > ST: stateConsumer.isKeyUpdated(k)? false > tx: stateConsumer.addUpdatedKey(k) > ST: commitContextEntry() > We probably need some synchronization here, maybe using EquivalentConcurrentHashMapV8.computeIfAbsent(). -- 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

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3617) Inconsistent L1 in non-tx distributed cache

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3617?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3617: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Inconsistent L1 in non-tx distributed cache > ------------------------------------------- > > Key: ISPN-3617 > URL: https://issues.jboss.org/browse/ISPN-3617 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.2.7.Final > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > Labels: jdg62blocker > Fix For: 6.0.0.CR2, 6.0.0.Final > > > When the change is replicated to backup owner, it sends the InvalidateL1Command to backup owners before committing the entry in EntryWrappingInterceptor (it performs the WriteCommand in parallel with sending the invalidation commmand, but then it waits until the invalidation request gets acked. If a GET is executed between the invalidation and committing the entry, the response contains outdated result and the L1 will not be invalidated until next write operation. -- 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

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3184) The DELTA_WRITE flag should force a remote get during state transfer

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3184?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3184: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1024920 > The DELTA_WRITE flag should force a remote get during state transfer > -------------------------------------------------------------------- > > Key: ISPN-3184 > URL: https://issues.jboss.org/browse/ISPN-3184 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.3.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: jdg620_dm, jdg62GAblocker > > AtomicHashMap and FineGrainedAtomicHashMap, as well as custom DeltaAware implementations, use PutKeyValueCommands with the DELTA_WRITE flag to execute incremental updates. These commands need the previous value of the entry in order to work. > If a node is joining and it receives a PutKeyValueCommand with the DELTA_WRITE flag before it has received the value of the affected key, it should do a remote get to retrieve the previous value and apply the change on top of that value, just like we do for conditional commands. Not doing so leads to data loss. -- 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

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3315) Retry remote get after topology change if all the targets are no longer owners

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3315?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3315: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1024917 > Retry remote get after topology change if all the targets are no longer owners > ------------------------------------------------------------------------------ > > Key: ISPN-3315 > URL: https://issues.jboss.org/browse/ISPN-3315 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.3.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: jdg620_dm, jdg62GAblocker > > It's possible for a remote get to reach its intended targets only after they are no longer owners, and they don't have the key anymore. If that happens, instead of returning a {{null}} value, the originator should retry on the new owners (possibly in a loop). > Note that this is different from all the owners leaving the cluster at the same time: in that case retrying on the new owners wouldn't make a difference, because data would be lost anyway. -- 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

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3335) JMX statistics for Queries partially doesn't work

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3335?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3335: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1024914 > JMX statistics for Queries partially doesn't work > ------------------------------------------------- > > Key: ISPN-3335 > URL: https://issues.jboss.org/browse/ISPN-3335 > Project: Infinispan > Issue Type: Bug > Components: Querying > Affects Versions: 6.0.0.Alpha1 > Reporter: Anna Manukyan > Assignee: Sanne Grinovero > Labels: jdg620_dm, jdg62GAblocker > Attachments: QueryMBeanTest.java > > > I was playing around with Query JMX statistics, and found out that there are several attributes like SearchQueryTotalTime are always 0 (this attr. represents the duration of query in nano-seconds), even though I'm running the infinispan query. > The only attribute which is updated and returns proper value is StatisticsEnabled. Also the following operations work as expected: > getNumberOfIndexedEntities(String entity) > clear() > I've tried also to retrieve the statistics using the following method: > {code} > Search.getSearchManager(cacheManager.getCache(CACHE_NAME)).getSearchFactory().getStatistics().getSearchQueryTotalTime() > {code} > and it returns the same results as if getting via JMX. > You can find the whole running test attached. > Best regards, > Anna. -- 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

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3615) Add user documentation for the remote query modules

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3615?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-3615: ------------------------------------- Please add a paragraph describing the following setup as well: - user stores a Person in the cluster over hotrod(java client) as protobuf object - an CPP client can read the same Person objects and deserialize it with the cpp protobuf library > Add user documentation for the remote query modules > --------------------------------------------------- > > Key: ISPN-3615 > URL: https://issues.jboss.org/browse/ISPN-3615 > Project: Infinispan > Issue Type: Task > Reporter: Mircea Markus > Assignee: Adrian Nistor > Fix For: 6.0.0.Final > > -- 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

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3633) InvalidateL1Command during ST should not cancel writing the entry by ST

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3633?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3633: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2183 > InvalidateL1Command during ST should not cancel writing the entry by ST > ----------------------------------------------------------------------- > > Key: ISPN-3633 > URL: https://issues.jboss.org/browse/ISPN-3633 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.3.0.Final > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > Labels: jdg620_dm, jdg62GAblocker > Fix For: 6.0.0.Final > > > When a node which is about to receive the entries for some segment receives InvalidateL1Command, this puts the key into StateConsumer.updatedKeys. After the entries for ST are received, the entry which was invalidated is not updated -> this result in losing the entry. > Btw., in EntryWrappingInterceptor.visitInvalidateL1Command the trace logs all looked up entries for each entry - this causes some performance problems when tracing is on and there are many invalidated entries. Please, do this only once. -- 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

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2548) JDBCCacheStore doesn't work propertly with MSSql

by Nicolas Filotto (JIRA)

[ https://issues.jboss.org/browse/ISPN-2548?page=com.atlassian.jira.plugin.... ] Nicolas Filotto commented on ISPN-2548: --------------------------------------- This is so disappointing to revert this change just because of one query, this feature brought a lot of simplicity to the end user, as we did not have to deal with any db complexity such as the schema name. So now, we need again this kind of change https://github.com/infinispan/infinispan/commit/8a6363ebb2ac26bdbfa9de965..., so if we intend to have several instances on the same database server, we need to define the schema name as prefix of all the tables which is just a real mess to configure when we have to deal with several different instances which is unfortunately my case, too bad for me :-( FYI, the right query was actually {{query = "SELECT count(*) from (SELECT TOP (1) 1 as C FROM " + tableName + ") T";}}, only the alias was missing which seems to be required in case of MS SQL. > JDBCCacheStore doesn't work propertly with MSSql > ------------------------------------------------- > > Key: ISPN-2548 > URL: https://issues.jboss.org/browse/ISPN-2548 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 5.2.0.Beta4 > Reporter: Anna Manukyan > Assignee: Mircea Markus > Fix For: 5.2.0.Beta5, 5.2.0.Final > > > The functional tests for JDBCCacheStore using MSSQL2008 R2 as a store, are failing. > In case if the configuration is set with properties: > .addProperty("dropTableOnExit", "false") > .addProperty("createTableOnStart", "true") > The following exception arrise: > {code} > org.infinispan.loaders.CacheLoaderException: com.microsoft.sqlserver.jdbc.SQLServerException: There is already an object named 'edg_bin____defaultcache' in the database. > at org.infinispan.loaders.jdbc.TableManipulation.executeUpdateSql(TableManipulation.java:187) > at org.infinispan.loaders.jdbc.TableManipulation.createTable(TableManipulation.java:160) > at org.infinispan.loaders.jdbc.TableManipulation.start(TableManipulation.java:262) > at org.infinispan.loaders.jdbc.binary.JdbcBinaryCacheStore.doConnectionFactoryInitialization(JdbcBinaryCacheStore.java:514) > at org.infinispan.loaders.jdbc.binary.JdbcBinaryCacheStore.start(JdbcBinaryCacheStore.java:102) > at org.infinispan.loaders.CacheLoaderManagerImpl.start(CacheLoaderManagerImpl.java:159) > ... 104 more > {code} > Please note, that MSSql database is clean before the test run, this means that the table is not there. But the exception is in place anyway. -- 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

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3671) Evaluate replacement of Mockito usage of spy with Forwarding mocks instead

by William Burns (JIRA)

William Burns created ISPN-3671: ----------------------------------- Summary: Evaluate replacement of Mockito usage of spy with Forwarding mocks instead Key: ISPN-3671 URL: https://issues.jboss.org/browse/ISPN-3671 Project: Infinispan Issue Type: Bug Components: Test Suite Affects Versions: 6.0.0.CR1 Reporter: William Burns Assignee: Mircea Markus Usage of Mockito spy actually creates a new instance (with current state) of the provided delegate. This can cause issues if there are already threads created that modify the provided delegate state as it won't affect the new object. It would be safer to first use a forwarding mock instead that doesn't create another instance as this has caused issues with some tests regarding state transfer. Here is an example of how the forwarding mock can be used. {code} StateConsumer sc = TestingUtil.extractComponent(cache, StateConsumer.class); final Answer<Object> forwardedAnswer = AdditionalAnswers.delegatesTo(sc); StateConsumer mockConsumer = mock(StateConsumer.class, withSettings().defaultAnswer(forwardedAnswer)); TestingUtil.replaceComponent(cache, StateConsumer.class, mockConsumer, true); doAnswer(new Answer() { @Override public Object answer(InvocationOnMock invocation) throws Throwable { // Do something return forwardedAnswer.answer(invocation); } }).when(mockConsumer).applyState(any(Address.class), anyInt(), anyCollection()); {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

11 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2013