[JBoss JIRA] (ISPN-3557) Key set not empty after transactional CACHE_MODE_LOCAL flagged clear
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3557?page=com.atlassian.jira.plugin.... ]
William Burns reassigned ISPN-3557:
-----------------------------------
Assignee: William Burns (was: Mircea Markus)
> Key set not empty after transactional CACHE_MODE_LOCAL flagged clear
> ---------------------------------------------------------------------
>
> Key: ISPN-3557
> URL: https://issues.jboss.org/browse/ISPN-3557
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.3.0.Final, 6.0.0.Beta1
> Reporter: Galder Zamarreño
> Assignee: William Burns
> Priority: Blocker
> Fix For: 6.0.0.CR1, 6.0.0.Final
>
>
> The following test fails (added to AbstractLocalTest):
> {code}
> public void testKeySetAfterClear() throws Exception {
> cache.put(1, "v1");
> tm().begin();
> try {
> cache.getAdvancedCache().withFlags(Flag.CACHE_MODE_LOCAL).clear();
> assertTrue(cache.keySet().isEmpty());
> } finally {
> tm().commit();
> }
> }
> {code}
> If the flag is removed, it works fine.
--
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
10 years, 6 months
[JBoss JIRA] (ISPN-3557) Key set not empty after transactional CACHE_MODE_LOCAL flagged clear
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3557?page=com.atlassian.jira.plugin.... ]
Work on ISPN-3557 started by William Burns.
> Key set not empty after transactional CACHE_MODE_LOCAL flagged clear
> ---------------------------------------------------------------------
>
> Key: ISPN-3557
> URL: https://issues.jboss.org/browse/ISPN-3557
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.3.0.Final, 6.0.0.Beta1
> Reporter: Galder Zamarreño
> Assignee: William Burns
> Priority: Blocker
> Fix For: 6.0.0.CR1, 6.0.0.Final
>
>
> The following test fails (added to AbstractLocalTest):
> {code}
> public void testKeySetAfterClear() throws Exception {
> cache.put(1, "v1");
> tm().begin();
> try {
> cache.getAdvancedCache().withFlags(Flag.CACHE_MODE_LOCAL).clear();
> assertTrue(cache.keySet().isEmpty());
> } finally {
> tm().commit();
> }
> }
> {code}
> If the flag is removed, it works fine.
--
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
10 years, 6 months
[JBoss JIRA] (ISPN-1089) NullPointerException when using an AtomicMap without a TransactionManagerLookup setup
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-1089?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-1089:
------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2126
> NullPointerException when using an AtomicMap without a TransactionManagerLookup setup
> -------------------------------------------------------------------------------------
>
> Key: ISPN-1089
> URL: https://issues.jboss.org/browse/ISPN-1089
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.0.0.CR1
> Reporter: Emmanuel Bernard
> Assignee: Pedro Ruivo
> Fix For: 6.0.0.CR1
>
>
> {code}
> org.infinispan.CacheException: Unable to start batch
> at org.infinispan.batch.BatchContainer.startBatch(BatchContainer.java:84)
> at org.infinispan.batch.AutoBatchSupport.startAtomic(AutoBatchSupport.java:44)
> at org.infinispan.atomic.AtomicHashMapProxy.put(AtomicHashMapProxy.java:160)
> at org.hibernate.ogm.type.descriptor.PassThroughGridTypeDescriptor$1.doBind(PassThroughGridTypeDescriptor.java:41)
> at org.hibernate.ogm.type.descriptor.BasicGridBinder.bind(BasicGridBinder.java:73)
> at org.hibernate.ogm.type.AbstractGenericBasicType.nullSafeSet(AbstractGenericBasicType.java:275)
> at org.hibernate.ogm.type.AbstractGenericBasicType.nullSafeSet(AbstractGenericBasicType.java:270)
> at org.hibernate.ogm.persister.OgmEntityPersister.createNewResultSetIfNull(OgmEntityPersister.java:875)
> at org.hibernate.ogm.persister.OgmEntityPersister.insert(OgmEntityPersister.java:859)
> at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:79)
> at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:273)
> at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:265)
> at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:184)
> at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321)
> at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:51)
> at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1216)
> at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:383)
> at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:133)
> at org.hibernate.ogm.test.embeddable.EmbeddableTest.testEmbeddable(EmbeddableTest.java:48)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at org.hibernate.testing.junit.functional.annotations.HibernateTestCase.runTest(HibernateTestCase.java:97)
> at org.hibernate.testing.junit.functional.annotations.HibernateTestCase.runBare(HibernateTestCase.java:85)
> at com.intellij.junit3.JUnit3IdeaTestRunner.doRun(JUnit3IdeaTestRunner.java:109)
> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:60)
> Caused by: java.lang.NullPointerException
> at org.infinispan.batch.BatchContainer.startBatch(BatchContainer.java:65)
> ... 37 more
> {code}
> A more descriptive exception would be nice. I did not have any NPE until I started to use AtomicMaps in Hibernate OGM. I now set a TransactionManagerLookup and it works.
--
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
10 years, 6 months
[JBoss JIRA] (ISPN-3321) NPE in MapReduceTask reduce phase
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3321?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-3321:
------------------------------------
[~afield] I think the problem here is that the default intermediary cache configuration has a {{lifespan}} and {{maxIdle}} of 120 seconds. The error appeared almost 3 minutes after the map/reduce task started, so it's very likely that the entry inserted by the mapper in the intermediary cache expired just as the reducer was trying to read it.
I don't think there is any reason to have expiry in the intermediary cache, so I'll change the default configuration in CreateCacheCommand.
If a cache {{\_\_tmpMapReduce}} is defined, its configuration will be used instead of the default configuration in CreateCacheCommand. So defining a cache {{\_\_tmpMapReduce}} without any special settings is a good workaround in the meantime.
> NPE in MapReduceTask reduce phase
> ---------------------------------
>
> Key: ISPN-3321
> URL: https://issues.jboss.org/browse/ISPN-3321
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Execution and Map/Reduce
> Affects Versions: 5.3.0.Final
> Reporter: Alan Field
> Assignee: Dan Berindei
> Priority: Critical
> Labels: jdg62GAblocker
> Fix For: 6.0.0.CR1
>
>
> During the execution of a MapReduce word count job with 6 nodes, the following NPE is thrown:
> 11:19:37,870 ERROR [org.infinispan.remoting.InboundInvocationHandlerImpl] (remote-thread-2) Exception executing command
> java.lang.NullPointerException
> at org.infinispan.distexec.mapreduce.MapReduceManagerImpl.reduce(MapReduceManagerImpl.java:153)
> at org.infinispan.commands.read.ReduceCommand.perform(ReduceCommand.java:88)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:122)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.access$000(InboundInvocationHandlerImpl.java:68)
> at org.infinispan.remoting.InboundInvocationHandlerImpl$2.run(InboundInvocationHandlerImpl.java:194)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> The full log is here - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/user/afield@REDHAT.COM/m...'s%20jobs/job/jdg-radargun-mapreduce-test/181/console-edg-perf06/
> Looking at the code to see if I can figure out what happened.
--
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
10 years, 6 months
[JBoss JIRA] (ISPN-3497) getCountRowsSql() has wrong SQL syntax
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3497?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3497:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1007415|https://bugzilla.redhat.com/show_bug.cgi?id=1007415] from NEW to MODIFIED
> getCountRowsSql() has wrong SQL syntax
> --------------------------------------
>
> Key: ISPN-3497
> URL: https://issues.jboss.org/browse/ISPN-3497
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.Alpha4
> Reporter: Vitalii Chepeliuk
> Assignee: Mircea Markus
> Labels: jdg62blocker
> Fix For: 6.0.0.Beta2
>
>
> When I run tests with mysql database following exception is thrown
> Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '*) FROM `mix_str____defaultcache`' at line 1
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> at com.mysql.jdbc.Util.handleNewInstance(Util.java:411)
> at com.mysql.jdbc.Util.getInstance(Util.java:386)
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1053)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4120)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4052)
> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2503)
> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2664)
> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2794)
> at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2155)
> at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:2322)
> at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:462)
> at org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedStore.size(JdbcStringBasedStore.java:358)
> {code:title=TableManipulation.java|borderStyle=solid}
> public String getCountRowsSql() {
> if (countRowsSql == null) {
> countRowsSql = "SELECT COUNT (*) FROM " + getTableName(); <<< here should be COUNT(*) without space
> }
> return countRowsSql;
> }
> {code}
> MySQL is complaining when there is SPACE between COUNT and (*)
> >[Error] Script lines: 5-6 --------------------------
> You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '*) FROM `edg_string____defaultcache`' at line 1
--
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
10 years, 6 months
[JBoss JIRA] (ISPN-3504) LevelDB Cache store in server doesn't keep data between restarts
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3504?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3504:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1007756|https://bugzilla.redhat.com/show_bug.cgi?id=1007756] from NEW to MODIFIED
> LevelDB Cache store in server doesn't keep data between restarts
> ----------------------------------------------------------------
>
> Key: ISPN-3504
> URL: https://issues.jboss.org/browse/ISPN-3504
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.Alpha4
> Reporter: Michal Linhard
> Assignee: Tristan Tarrant
> Labels: jdg62blocker
> Fix For: 6.0.0.Beta2
>
>
> I have config with passivation="false" purge="false"
> and expect data to survive restarts which doesn't happen.
> {code}
> <cache-container name="default" default-cache="default"
> listener-executor="infinispan-listener">
> <local-cache name="default" start="EAGER" batching="false">
> <locking isolation="REPEATABLE_READ" acquire-timeout="20000"
> concurrency-level="500" striping="false" />
> <transaction mode="NONE" />
> <leveldb-store path="temp-leveldb" block-size="1024"
> cache-size="50000" clear-threshold="100000" passivation="false"
> purge="false" >
> <expiration path="temp-leveldb-expired" queue-size="2000" />
> <compression type="SNAPPY" />
> <implementation type="JAVA" />
> </leveldb-store>
> </local-cache>
> <local-cache name="memcachedCache" start="EAGER" batching="false">
> <locking isolation="REPEATABLE_READ" acquire-timeout="20000"
> concurrency-level="500" striping="false" />
> <transaction mode="NONE" />
> </local-cache>
> </cache-container>
> {code}
> failing test:
> https://code.engineering.redhat.com/gerrit/gitweb?p=jdg-functional-tests....;
> hb=8e1b8a10fed5de5bf3bb9ec6fbc46857e1666798
> for JDG 6.2.0.DR4
--
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
10 years, 6 months
[JBoss JIRA] (ISPN-3398) Unmarshall problem in compatibility mode
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3398?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3398:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 993738|https://bugzilla.redhat.com/show_bug.cgi?id=993738] from POST to MODIFIED
> Unmarshall problem in compatibility mode
> ----------------------------------------
>
> Key: ISPN-3398
> URL: https://issues.jboss.org/browse/ISPN-3398
> Project: Infinispan
> Issue Type: Bug
> Components: Marshalling, Remote protocols, Server
> Affects Versions: 5.3.0.Final, 6.0.0.Alpha2
> Reporter: Michal Linhard
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: jdg62blocker
> Fix For: 6.0.0.Beta2, 6.0.0.Final
>
>
> JDG 6.2.0.DR2 client/server tests using hotrod and cache in compatibility mode:
> throw this:
> {code}
> 04:48:28,445 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (remote-thread-0) ISPN000136: Execution error: java.io.IOException: Unsupported protocol version 9
> at org.jboss.marshalling.river.RiverUnmarshaller.start(RiverUnmarshaller.java:1243)
> at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.startObjectInput(AbstractJBossMarshaller.java:138) [infinispan-commons-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1]
> at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromByteBuffer(AbstractJBossMarshaller.java:119) [infinispan-commons-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1]
> at org.infinispan.commons.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:83) [infinispan-commons-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1]
> at org.infinispan.server.hotrod.HotRodTypeConverter.unmarshall(HotRodTypeConverter.scala:36) [infinispan-server-hotrod-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1]
> at org.infinispan.server.hotrod.HotRodTypeConverter.boxValue(HotRodTypeConverter.scala:22) [infinispan-server-hotrod-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1]
> at org.infinispan.interceptors.compat.TypeConverterInterceptor.visitPutKeyValueCommand(TypeConverterInterceptor.java:72) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1]
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1]
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1]
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1]
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1]
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1]
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1]
> at org.infinispan.commands.remote.BaseRpcInvokingCommand.processVisitableCommand(BaseRpcInvokingCommand.java:39) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1]
> at org.infinispan.commands.remote.SingleRpcCommand.perform(SingleRpcCommand.java:48) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1]
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:97) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1]
> at org.infinispan.remoting.InboundInvocationHandlerImpl.access$000(InboundInvocationHandlerImpl.java:46) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1]
> at org.infinispan.remoting.InboundInvocationHandlerImpl$2.run(InboundInvocationHandlerImpl.java:169) [infinispan-core-6.0.0.Alpha2-redhat-1.jar:6.0.0.Alpha2-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> {code}
> the exception appears for each request, the form is always
> "Unsupported protocol version X" where X differs
> see
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/PERF-CS/jo...
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/PERF-CS/jo...
--
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
10 years, 6 months