[JBoss JIRA] (ISPN-6594) NumericVersionGenerator should not use SecurityActions
by Dan Berindei (JIRA)
Dan Berindei created ISPN-6594:
----------------------------------
Summary: NumericVersionGenerator should not use SecurityActions
Key: ISPN-6594
URL: https://issues.jboss.org/browse/ISPN-6594
Project: Infinispan
Issue Type: Enhancement
Components: Core
Affects Versions: 9.0.0.Alpha1
Reporter: Dan Berindei
The {{Cache}} instance injected into internal components is never secured, so {{NumericVersionGenerator}} can call {{cache.getCacheConfiguration()}} or {{cache.getCacheManager().addListener()}} directlly.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (ISPN-6533) not possible to change JDBC store configuration in console
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-6533?page=com.atlassian.jira.plugin.... ]
Ryan Emerson reassigned ISPN-6533:
----------------------------------
Assignee: Ryan Emerson (was: Vladimir Blagojevic)
> not possible to change JDBC store configuration in console
> ----------------------------------------------------------
>
> Key: ISPN-6533
> URL: https://issues.jboss.org/browse/ISPN-6533
> Project: Infinispan
> Issue Type: Bug
> Components: Console
> Affects Versions: 8.2.0.Final
> Reporter: Martin Vrabel
> Assignee: Ryan Emerson
>
> cache container -> cache -> configuration -> JDCB Store
> after changing a configuration the "undo" button doesn't show up at the right side and after clicking apply changes a dialog shows up asking if I want to create new configuration template instead of asking for updating the current configuration
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (ISPN-3702) Too many threads for cleaning up infinispan transactions
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3702?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3702:
------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/4308, https://github.com/infinispan/infinispan/pull/4310 (was: https://github.com/infinispan/infinispan/pull/4308)
> Too many threads for cleaning up infinispan transactions
> --------------------------------------------------------
>
> Key: ISPN-3702
> URL: https://issues.jboss.org/browse/ISPN-3702
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Transactions
> Affects Versions: 5.3.0.Final
> Environment: Mac and Linux
> Reporter: Prasanth Pallamreddy
> Assignee: Pedro Ruivo
> Fix For: 9.0.0.Alpha2, 8.2.2.Final
>
>
> When using multiple transactional caches, we are seeing that each cache has a dedicated cleanup thread. While this is not an issue for small number of caches, when the number of caches is high as in our case (~100), we see around a 100 threads dedicated for cleanup like the following.
> "TxCleanupService,{default}_{XXX},user-mac-54275" daemon prio=5 tid=0x00007fa0f50d3800 nid=0x10f03 waiting on condition [0x00000001a5a5d000]
> "TxCleanupService,{default}_{XXX},user-mac-54275" daemon prio=5 tid=0x00007fa0f507e800 nid=0x10e03 waiting on condition [0x00000001a595a000]
> "TxCleanupService,{default}_{XXX},user-mac-54275" daemon prio=5 tid=0x00007fa0f507e000 nid=0x10d03 waiting on condition [0x00000001a5857000]
> "TxCleanupService,{default}_{XXX},user-mac-54275" daemon prio=5 tid=0x00007fa0f5817800 nid=0x10c03 waiting on condition [0x00000001a5754000]
> ...
> Looking at the source code for
> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o...
> if (!totalOrder) {
> // Periodically run a task to cleanup the transaction table from completed transactions.
> ThreadFactory tf = new ThreadFactory() {
> @Override
> public Thread newThread(Runnable r) {
> String address = rpcManager != null ? rpcManager.getTransport().getAddress().toString() : "local";
> Thread th = new Thread(r, "TxCleanupService," + cacheName + "," + address);
> th.setDaemon(true);
> return th;
> }
> };
> executorService = Executors.newSingleThreadScheduledExecutor(tf);
> This code can benefit from drawing the threads from a dedicated pool which is bounded.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (ISPN-3702) Too many threads for cleaning up infinispan transactions
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3702?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3702:
------------------------------
Fix Version/s: 8.2.2.Final
> Too many threads for cleaning up infinispan transactions
> --------------------------------------------------------
>
> Key: ISPN-3702
> URL: https://issues.jboss.org/browse/ISPN-3702
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Transactions
> Affects Versions: 5.3.0.Final
> Environment: Mac and Linux
> Reporter: Prasanth Pallamreddy
> Assignee: Pedro Ruivo
> Fix For: 9.0.0.Alpha2, 8.2.2.Final
>
>
> When using multiple transactional caches, we are seeing that each cache has a dedicated cleanup thread. While this is not an issue for small number of caches, when the number of caches is high as in our case (~100), we see around a 100 threads dedicated for cleanup like the following.
> "TxCleanupService,{default}_{XXX},user-mac-54275" daemon prio=5 tid=0x00007fa0f50d3800 nid=0x10f03 waiting on condition [0x00000001a5a5d000]
> "TxCleanupService,{default}_{XXX},user-mac-54275" daemon prio=5 tid=0x00007fa0f507e800 nid=0x10e03 waiting on condition [0x00000001a595a000]
> "TxCleanupService,{default}_{XXX},user-mac-54275" daemon prio=5 tid=0x00007fa0f507e000 nid=0x10d03 waiting on condition [0x00000001a5857000]
> "TxCleanupService,{default}_{XXX},user-mac-54275" daemon prio=5 tid=0x00007fa0f5817800 nid=0x10c03 waiting on condition [0x00000001a5754000]
> ...
> Looking at the source code for
> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o...
> if (!totalOrder) {
> // Periodically run a task to cleanup the transaction table from completed transactions.
> ThreadFactory tf = new ThreadFactory() {
> @Override
> public Thread newThread(Runnable r) {
> String address = rpcManager != null ? rpcManager.getTransport().getAddress().toString() : "local";
> Thread th = new Thread(r, "TxCleanupService," + cacheName + "," + address);
> th.setDaemon(true);
> return th;
> }
> };
> executorService = Executors.newSingleThreadScheduledExecutor(tf);
> This code can benefit from drawing the threads from a dedicated pool which is bounded.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (ISPRK-22) InfinispanRDD is not fault tolerant
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPRK-22?page=com.atlassian.jira.plugin.s... ]
Gustavo Fernandes commented on ISPRK-22:
----------------------------------------
[~vjuranek] Thanks for the updated tests. They seems to pass for me, if run against the fix I'm working on
> InfinispanRDD is not fault tolerant
> -----------------------------------
>
> Key: ISPRK-22
> URL: https://issues.jboss.org/browse/ISPRK-22
> Project: Infinispan Spark
> Issue Type: Bug
> Components: RDD
> Affects Versions: 0.3
> Reporter: Vojtech Juranek
> Assignee: Gustavo Fernandes
> Fix For: 0.4
>
>
> When primary ISPN server fails during processing InfinispanRDD, Spark is not able to overcome this failure.
> This is caused by re-creating {{RemoteCachManager}} with pre-configured ISPN server address (for read [here|https://github.com/infinispan/infinispan-spark/blob/master/src/main/...], for writes [here|https://github.com/infinispan/infinispan-spark/blob/master/src/main/...]), so when this server fails during RDD processing and Spark calls some function, which under the hood creates {{RemoteCacheManager}}, it will fail with connection refused exception.
> [Here|https://github.com/vjuranek/infinispan-spark/commit/fa56b5f072ce24e0...] are some basic tests and example of exception thrown by HR client:
> {noformat}
> org.infinispan.client.hotrod.exceptions.TransportException:: Could not fetch transport
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.borrowTransportFromPool(TcpTransportFactory.java:395)
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.getTransport(TcpTransportFactory.java:241)
> at org.infinispan.client.hotrod.impl.operations.FaultTolerantPingOperation.getTransport(FaultTolerantPingOperation.java:26)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:53)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.ping(RemoteCacheImpl.java:490)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.resolveCompatibility(RemoteCacheImpl.java:551)
> at org.infinispan.client.hotrod.RemoteCacheManager.createRemoteCache(RemoteCacheManager.java:341)
> at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:222)
> at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:217)
> at org.infinispan.spark.rdd.InfinispanRDD$$anonfun$1.apply(InfinispanRDD.scala:52)
> at org.infinispan.spark.rdd.InfinispanRDD$$anonfun$1.apply(InfinispanRDD.scala:52)
> at scala.Option.map(Option.scala:146)
> at org.infinispan.spark.rdd.InfinispanRDD.compute(InfinispanRDD.scala:52)
> at org.infinispan.spark.rdd.InfinispanRDD.compute(InfinispanRDD.scala:66)
> at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:306)
> at org.apache.spark.rdd.RDD.iterator(RDD.scala:270)
> at org.apache.spark.scheduler.ResultTask.runTask(ResultTask.scala:66)
> at org.apache.spark.scheduler.Task.run(Task.scala:89)
> at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:213)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.infinispan.client.hotrod.exceptions.TransportException:: Could not connect to server: /127.0.0.1:11222
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.<init>(TcpTransport.java:78)
> at org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory.makeObject(TransportObjectFactory.java:35)
> at org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory.makeObject(TransportObjectFactory.java:16)
> at org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1220)
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.borrowTransportFromPool(TcpTransportFactory.java:390)
> ... 21 more
> Caused by: java.net.ConnectException: Connection refused
> at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
> at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
> at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:111)
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.<init>(TcpTransport.java:68)
> ... 25 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (ISPRK-22) InfinispanRDD is not fault tolerant
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPRK-22?page=com.atlassian.jira.plugin.s... ]
Work on ISPRK-22 started by Gustavo Fernandes.
----------------------------------------------
> InfinispanRDD is not fault tolerant
> -----------------------------------
>
> Key: ISPRK-22
> URL: https://issues.jboss.org/browse/ISPRK-22
> Project: Infinispan Spark
> Issue Type: Bug
> Components: RDD
> Affects Versions: 0.3
> Reporter: Vojtech Juranek
> Assignee: Gustavo Fernandes
> Fix For: 0.4
>
>
> When primary ISPN server fails during processing InfinispanRDD, Spark is not able to overcome this failure.
> This is caused by re-creating {{RemoteCachManager}} with pre-configured ISPN server address (for read [here|https://github.com/infinispan/infinispan-spark/blob/master/src/main/...], for writes [here|https://github.com/infinispan/infinispan-spark/blob/master/src/main/...]), so when this server fails during RDD processing and Spark calls some function, which under the hood creates {{RemoteCacheManager}}, it will fail with connection refused exception.
> [Here|https://github.com/vjuranek/infinispan-spark/commit/fa56b5f072ce24e0...] are some basic tests and example of exception thrown by HR client:
> {noformat}
> org.infinispan.client.hotrod.exceptions.TransportException:: Could not fetch transport
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.borrowTransportFromPool(TcpTransportFactory.java:395)
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.getTransport(TcpTransportFactory.java:241)
> at org.infinispan.client.hotrod.impl.operations.FaultTolerantPingOperation.getTransport(FaultTolerantPingOperation.java:26)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:53)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.ping(RemoteCacheImpl.java:490)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.resolveCompatibility(RemoteCacheImpl.java:551)
> at org.infinispan.client.hotrod.RemoteCacheManager.createRemoteCache(RemoteCacheManager.java:341)
> at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:222)
> at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:217)
> at org.infinispan.spark.rdd.InfinispanRDD$$anonfun$1.apply(InfinispanRDD.scala:52)
> at org.infinispan.spark.rdd.InfinispanRDD$$anonfun$1.apply(InfinispanRDD.scala:52)
> at scala.Option.map(Option.scala:146)
> at org.infinispan.spark.rdd.InfinispanRDD.compute(InfinispanRDD.scala:52)
> at org.infinispan.spark.rdd.InfinispanRDD.compute(InfinispanRDD.scala:66)
> at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:306)
> at org.apache.spark.rdd.RDD.iterator(RDD.scala:270)
> at org.apache.spark.scheduler.ResultTask.runTask(ResultTask.scala:66)
> at org.apache.spark.scheduler.Task.run(Task.scala:89)
> at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:213)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.infinispan.client.hotrod.exceptions.TransportException:: Could not connect to server: /127.0.0.1:11222
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.<init>(TcpTransport.java:78)
> at org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory.makeObject(TransportObjectFactory.java:35)
> at org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory.makeObject(TransportObjectFactory.java:16)
> at org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1220)
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.borrowTransportFromPool(TcpTransportFactory.java:390)
> ... 21 more
> Caused by: java.net.ConnectException: Connection refused
> at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
> at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
> at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:111)
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.<init>(TcpTransport.java:68)
> ... 25 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (ISPN-6593) LevelDB tests fail on Windows
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-6593?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec updated ISPN-6593:
--------------------------------------
Status: Open (was: New)
> LevelDB tests fail on Windows
> -----------------------------
>
> Key: ISPN-6593
> URL: https://issues.jboss.org/browse/ISPN-6593
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Environment: Apache Maven 3.3.9
> Java version: 1.8.0_91, vendor: Oracle Corporation
> Default locale: pl_PL, platform encoding: Cp1250
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos"
> Reporter: Sebastian Łaskawiec
> Assignee: Sebastian Łaskawiec
> Labels: windows
>
> LevelDB JNI implementation has some problems with the way that Windows manages files.
> Here are 2 major problems there:
> # JDK doesn't always clean up files: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4715154
> # A cleared DB object has {{null}} references inside and this results in throwing {{DBException}}s
> Some stacktraces for investigation:
> {noformat}
> org.iq80.leveldb.DBException: Closed
> at org.fusesource.leveldbjni.internal.JniDB.iterator(JniDB.java:100)
> at org.infinispan.persistence.leveldb.LevelDBStore.clear(LevelDBStore.java:227)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.clearAllStores(PersistenceManagerImpl.java:399)
> at org.infinispan.test.TestingUtil.clearCacheLoader(TestingUtil.java:733)
> at org.infinispan.test.TestingUtil.clearContent(TestingUtil.java:680)
> at org.infinispan.persistence.BaseStoreFunctionalTest.teardown(BaseStoreFunctionalTest.java:55)
> at org.infinispan.test.SingleCacheManagerTest.destroyAfterMethod(SingleCacheManagerTest.java:74)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:564)
> at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:786)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> 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:348)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:38)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> {noformat}
> org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.preload() on object of type PersistenceManagerImpl
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:864)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:633)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:622)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:547)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:238)
> at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:890)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:635)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:585)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:451)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:437)
> at org.infinispan.persistence.leveldb.config.ConfigurationTest.testXmlConfig(ConfigurationTest.java:71)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> 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:348)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:38)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.infinispan.persistence.spi.PersistenceException: java.lang.RuntimeException: org.fusesource.leveldbjni.internal.NativeDB$DBException: Invalid argument: not an sstable (bad magic number)
> at org.infinispan.persistence.leveldb.LevelDBStore.process(LevelDBStore.java:315)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.preload(PersistenceManagerImpl.java:236)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> ... 31 more
> Caused by: java.lang.RuntimeException: org.fusesource.leveldbjni.internal.NativeDB$DBException: Invalid argument: not an sstable (bad magic number)
> at org.fusesource.leveldbjni.internal.JniDBIterator.peekNext(JniDBIterator.java:89)
> at org.fusesource.leveldbjni.internal.JniDBIterator.next(JniDBIterator.java:98)
> at org.fusesource.leveldbjni.internal.JniDBIterator.next(JniDBIterator.java:45)
> at org.infinispan.persistence.leveldb.LevelDBStore.process(LevelDBStore.java:298)
> ... 37 more
> Caused by: org.fusesource.leveldbjni.internal.NativeDB$DBException: Invalid argument: not an sstable (bad magic number)
> at org.fusesource.leveldbjni.internal.NativeDB.checkStatus(NativeDB.java:200)
> at org.fusesource.leveldbjni.internal.NativeIterator.checkStatus(NativeIterator.java:121)
> at org.fusesource.leveldbjni.internal.NativeIterator.key(NativeIterator.java:169)
> at org.fusesource.leveldbjni.internal.JniDBIterator.peekNext(JniDBIterator.java:87)
> ... 40 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months