[JBoss JIRA] (ISPN-3498) Cannot construct org.infinispan.util.KeyValuePair as it does not have a no-args constructor
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3498?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3498:
--------------------------------
Fix Version/s: 6.0.0.Beta2
(was: 6.0.0.Beta1)
> Cannot construct org.infinispan.util.KeyValuePair as it does not have a no-args constructor
> -------------------------------------------------------------------------------------------
>
> Key: ISPN-3498
> URL: https://issues.jboss.org/browse/ISPN-3498
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Affects Versions: 6.0.0.Alpha4
> Environment: Azul JDK
> Reporter: Vitalii Chepeliuk
> Assignee: Mircea Markus
> Labels: testsuite_stability
> Fix For: 6.0.0.Beta2
>
>
> When infinispan testsuite(Alpha3) is running with Azul JDK
> java.runtime.version = 1.6.0_33-b5
> java.runtime.name =Java(TM) SE Runtime Environment
> java.vm.version = 1.6.0_33-ZVM_5.5.3.0-b5-product-azlinuxM-X86_64
> java.vm.vendor = Azul Systems, Inc.
> os.name = Linux
> os.version = 2.6.32-358.11.1.el6.x86_64
> sun.arch.data.model = 64
> sun.cpu.endian = little
> Wollowing redundant Exception occurs
> Error Message
> Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor : Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor ---- Debugging information ---- message : Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor cause-exception : com.thoughtworks.xstream.converters.reflection.ObjectAccessException cause-message : Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor class : org.infinispan.container.entries.ImmortalCacheValue required-type : org.infinispan.container.entries.ImmortalCacheValue converter-type : com.thoughtworks.xstream.converters.reflection.ReflectionConverter path : /org.infinispan.container.entries.ImmortalCacheValue line number : 1 version : 1.4.1-redhat-2 -------------------------------
> Stacktrace
> com.thoughtworks.xstream.converters.ConversionException: Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor : Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor
> ---- Debugging information ----
> message : Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor
> cause-exception : com.thoughtworks.xstream.converters.reflection.ObjectAccessException
> cause-message : Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor
> class : org.infinispan.container.entries.ImmortalCacheValue
> required-type : org.infinispan.container.entries.ImmortalCacheValue
> converter-type : com.thoughtworks.xstream.converters.reflection.ReflectionConverter
> path : /org.infinispan.container.entries.ImmortalCacheValue
> line number : 1
> version : 1.4.1-redhat-2
> -------------------------------
> at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:79)
> at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:65)
> at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:66)
> at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:50)
> at com.thoughtworks.xstream.core.TreeUnmarshaller.start(TreeUnmarshaller.java:134)
> at com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.unmarshal(AbstractTreeMarshallingStrategy.java:32)
> at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:1035)
> at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:1019)
> at com.thoughtworks.xstream.XStream.fromXML(XStream.java:895)
> at com.thoughtworks.xstream.XStream.fromXML(XStream.java:886)
> at org.infinispan.marshall.TestObjectStreamMarshaller.objectFromObjectStream(TestObjectStreamMarshaller.java:65)
> at org.infinispan.marshall.TestObjectStreamMarshaller.objectFromByteBuffer(TestObjectStreamMarshaller.java:97)
> at org.infinispan.commons.marshall.AbstractMarshaller.objectFromInputStream(AbstractMarshaller.java:105)
> at org.infinispan.loaders.jdbc.JdbcUtil.unmarshall(JdbcUtil.java:66)
> at org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore.readStoredEntry(JdbcStringBasedCacheStore.java:391)
> at org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore.loadLockSafe(JdbcStringBasedCacheStore.java:328)
> at org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore.loadLockSafe(JdbcStringBasedCacheStore.java:67)
> at org.infinispan.loaders.spi.LockSupportCacheStore.load(LockSupportCacheStore.java:128)
> at org.infinispan.loaders.spi.AbstractCacheLoader.containsKey(AbstractCacheLoader.java:34)
> at org.infinispan.loaders.BaseCacheStoreTest.testCommitAndRollbackWithoutPrepare(BaseCacheStoreTest.java:427)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: com.thoughtworks.xstream.converters.reflection.ObjectAccessException: Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor
> at com.thoughtworks.xstream.converters.reflection.PureJavaReflectionProvider.newInstance(PureJavaReflectionProvider.java:71)
> at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.instantiateNewInstance(AbstractReflectionConverter.java:424)
> at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.unmarshal(AbstractReflectionConverter.java:229)
> at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:72)
> ... 40 more
> You can see it in jenkins http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-62-ispn-testsuite...
> After implementing or extending Serializable interface in BucketInternalCacheEntry, InternalCacheValue exception disappeared
> Second build was done with Alpha4 version and the same exception appers because of new classes and functionality added
> You can see it in jenkins http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-62-ispn-testsuite...
--
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
12 years, 6 months
[JBoss JIRA] (ISPN-3497) getCountRowsSql() has wrong SQL syntax
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3497?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3497:
--------------------------------
Fix Version/s: 6.0.0.Beta2
(was: 6.0.0.Beta1)
> 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
> 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
12 years, 6 months
[JBoss JIRA] (ISPN-3467) Remove support for strictPeerToPeer = true
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3467?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3467:
--------------------------------
Fix Version/s: 6.0.0.Beta2
(was: 6.0.0.Beta1)
> Remove support for strictPeerToPeer = true
> ------------------------------------------
>
> Key: ISPN-3467
> URL: https://issues.jboss.org/browse/ISPN-3467
> Project: Infinispan
> Issue Type: Task
> Components: Configuration, RPC, Server
> Affects Versions: 6.0.0.Alpha3
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 6.0.0.Beta2, 6.0.0.CR1
>
>
> Setting {{transport.strictPeerToPeer = true}} doesn't really do anything with dist caches with L1 disabled, as commands are replicated only to members of the cache. With L1 enabled, writes/txs may or may not fail, depending on if there are any L1 requestors for the modified keys and on the value of {{clustering.l1.invalidationThreshold}} - unpredictable, so more harmful than useful.
> With repl caches, the setting does work as advertised: even if the cache topology contains only the nodes with the cache running, the writes/txs are sent to all the nodes in the cluster, and they will fail if the cache is not running on one of them. On the other hand, in order to retry the operation, the users would have to wait for the cache's topology to contain all the nodes in the cluster - so if they need to ensure that a cache is present on all the nodes in the cluster, they could check that {{RpcManager.getMembers().equals(Transport.getMembers()}} directly.
> So we should remove the {{transport.strictPeerToPeer}} setting, although we could mark it as deprecated and log a warning for the time being.
--
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
12 years, 6 months
[JBoss JIRA] (ISPN-3449) ReplaceCommand with ignorePrevValue=true does not work on null entries
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3449?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3449:
--------------------------------
Fix Version/s: 6.0.0.Beta2
(was: 6.0.0.Beta1)
> ReplaceCommand with ignorePrevValue=true does not work on null entries
> ----------------------------------------------------------------------
>
> Key: ISPN-3449
> URL: https://issues.jboss.org/browse/ISPN-3449
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 6.0.0.Alpha3
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 6.0.0.Beta2
>
>
> If ReplaceCommand with ignorePrevValue=true is executed on a backup owner node which has not the entry in the container (for example because the state transfer was not completed yet), the EntryWrappingInterceptor/EntryFactoryImpl won't put it the command's context. Then, in the ReplaceCommand.perform() the entry is not replaced and the command fails.
> The command on primary owner succeeds as it does not check whether the responses are successful.
--
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
12 years, 6 months
[JBoss JIRA] (ISPN-3447) LevelDBCacheStore tests fail to compile with latest core snapshot
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3447?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3447:
--------------------------------
Fix Version/s: 6.0.0.Beta2
(was: 6.0.0.Beta1)
> LevelDBCacheStore tests fail to compile with latest core snapshot
> -----------------------------------------------------------------
>
> Key: ISPN-3447
> URL: https://issues.jboss.org/browse/ISPN-3447
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 6.0.0.Beta2
>
>
> Error:
> {code}[ERROR] COMPILATION ERROR :
> [INFO] -------------------------------------------------------------
> [ERROR] /Users/g/Go/code/cachestores/cachestore-leveldb.git/src/test/java/org/infinispan/loaders/leveldb/config/ConfigurationTest.java:[76,82] method cacheStore in class org.infinispan.configuration.cache.LegacyStoreConfigurationBuilder cannot be applied to given types;
> required: org.infinispan.loaders.CacheStore
> found: org.infinispan.loaders.leveldb.LevelDBCacheStore
> reason: actual argument org.infinispan.loaders.leveldb.LevelDBCacheStore cannot be converted to org.infinispan.loaders.CacheStore by method invocation conversion{code}
> [~rvansa], is this related to your changes?
--
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
12 years, 6 months
[JBoss JIRA] (ISPN-3443) WriteCommand may be ignored during state transfer
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3443?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3443:
--------------------------------
Fix Version/s: 6.0.0.Beta2
(was: 6.0.0.Beta1)
> WriteCommand may be ignored during state transfer
> -------------------------------------------------
>
> Key: ISPN-3443
> URL: https://issues.jboss.org/browse/ISPN-3443
> Project: Infinispan
> Issue Type: Bug
> Components: Locking and Concurrency, State transfer
> Affects Versions: 6.0.0.Alpha3
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 6.0.0.Beta2
>
>
> Distributed sync non-tx cache.
> Situation:
> 1) A node is joining the cluster, requesting some segment
> 2) RemoveCommand is sent to backup owner with ignorePreviousValue=true
> 3) It looks up the entry and finds null
> 4) State transfer invokes the PutKeyValueCommand and sets the value for removed entry (updateKeys has not the key yet)
> 5) RemoveCommand adds its key to updateKeys set, but it does not remove the value as it is already null (in its context)
> Result: the value is removed on primary but on backup this is still present
--
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
12 years, 6 months
[JBoss JIRA] (ISPN-3526) Inject dependecies into the marshaller used for compatibility mode
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3526?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3526:
--------------------------------
Fix Version/s: 6.0.0.Beta2
(was: 6.0.0.Beta1)
> Inject dependecies into the marshaller used for compatibility mode
> ------------------------------------------------------------------
>
> Key: ISPN-3526
> URL: https://issues.jboss.org/browse/ISPN-3526
> Project: Infinispan
> Issue Type: Feature Request
> Affects Versions: 6.0.0.Alpha4
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 6.0.0.Beta2
>
>
> Interoperability between remote query and embedded mode requires a special marshaller to be specified (CompatibilityProtoStreamMarshaller) which has a dependency on the CacheManager. It should not be the user's responsibility to inject this dependency because that could only work with programmatic configuration and would be impossible with xml config.
> Probably the best way to solve this is to automatically wire all user provided marshaller _instances_ if they are annotated for injection.
>
--
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
12 years, 6 months