[JBoss JIRA] (ISPN-8416) Error executing MassIndexer using off-heap
by Lucas Ponce (JIRA)
Lucas Ponce created ISPN-8416:
---------------------------------
Summary: Error executing MassIndexer using off-heap
Key: ISPN-8416
URL: https://issues.jboss.org/browse/ISPN-8416
Project: Infinispan
Issue Type: Bug
Affects Versions: 9.2.0.Alpha1
Reporter: Lucas Ponce
Invoking a re-index operation on startup from the API
{code}
SearchManager searchResourceManager = Search.getSearchManager(resource);
CompletableFuture<Void> reindexResource = searchResourceManager.getMassIndexer().startAsync();
SearchManager searchResourceTypeManager = Search.getSearchManager(resourceType);
CompletableFuture<Void> reindexResourceType = searchResourceTypeManager.getMassIndexer().startAsync();
CompletableFuture.allOf(reindexResource, reindexResourceType).get();
{code}
Throws the following Exception
{code}
14:01:23,537 ERROR [org.hawkular.inventory.service.InventoryConfig] (ServerService Thread Pool -- 62) HAWKINV100005: Error reindexing caches: java.util.concurrent.ExecutionException: org.infinispan.commons.CacheException: ISPN014018: Error executing MassIndexer
at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357)
at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1895)
at org.hawkular.inventory.service.InventoryConfig.init(InventoryConfig.java:111)
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.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:96)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doLifecycleInterception(Jsr299BindingsInterceptor.java:114)
at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:103)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:53)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:349)
at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:68)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.singleton.StartupCountDownInterceptor.processInvocation(StartupCountDownInterceptor.java:25)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:138)
at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
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)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: org.infinispan.commons.CacheException: ISPN014018: Error executing MassIndexer
at org.infinispan.query.impl.massindex.DistributedExecutorMassIndexer.lambda$null$0(DistributedExecutorMassIndexer.java:73)
at java.util.concurrent.CompletableFuture.uniExceptionally(CompletableFuture.java:870)
at java.util.concurrent.CompletableFuture$UniExceptionally.tryFire(CompletableFuture.java:852)
at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
at java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:1977)
at org.infinispan.distexec.DefaultExecutorService$LocalDistributedTaskPart.lambda$execute$1(DefaultExecutorService.java:1086)
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: java.lang.IllegalArgumentException: Indexing only works with entries keyed on Strings, primitives and classes that have the @Transformable annotation - you passed in a class org.infinispan.commons.marshall.WrappedByteArray. Alternatively, see org.infinispan.query.SearchManager#registerKeyTransformer
at org.infinispan.query.backend.KeyTransformationHandler.keyToString(KeyTransformationHandler.java:154)
at org.infinispan.query.impl.massindex.IndexUpdater.updateIndex(IndexUpdater.java:67)
at org.infinispan.query.impl.massindex.IndexWorker.call(IndexWorker.java:101)
at org.infinispan.query.impl.massindex.IndexWorker.call(IndexWorker.java:34)
at org.infinispan.commands.read.DistributedExecuteCommand.invokeAsync(DistributedExecuteCommand.java:99)
at org.infinispan.distexec.DefaultExecutorService$LocalDistributedTaskPart.lambda$execute$1(DefaultExecutorService.java:1074)
... 3 more
{code}
Infinispan 9.2.0.Alpha1 is running in library mode embedded in a .war application with the following configuration:
{code}
<cache-container name="hawkular-inventory">
<jmx duplicate-domains="true" />
<local-cache name="resource" statistics="true">
<transaction mode="NON_XA"/>
<persistence>
<file-store preload="true" fetch-state="true" read-only="false" purge="false" path="${jboss.server.data.dir}/hawkular-inventory">
<write-behind thread-pool-size="5" modification-queue-size="10000" />
</file-store>
</persistence>
<memory>
<!--
<binary eviction="COUNT" size="10000" />
-->
<!--
<object size="5000" />
-->
<off-heap eviction="COUNT" size="100000" />
<!--
<off-heap eviction="COUNT" size="100000" />
-->
</memory>
<indexing index="LOCAL">
<indexed-entities>
<indexed-entity>org.hawkular.inventory.service.ispn.IspnResource</indexed-entity>
</indexed-entities>
<property name="default.indexmanager">near-real-time</property>
<property name="default.directory_provider">infinispan</property>
<property name="default.chunk_size">128000</property>
<property name="default.locking_cachename">resource_indexes_locking</property>
<property name="default.data_cachename">resource_indexes_data</property>
<property name="default.metadata_cachename">resource_indexes_metadata</property>
<!-- The default is 10, but we don't want to waste many cycles in merging
(tune for writes at cost of reader fragmentation) -->
<property name="default.indexwriter.merge_factor">30</property>
<!-- Never create segments larger than 1GB -->
<property name="default.indexwriter.merge_max_size">1024</property>
<!-- IndexWriter flush buffer size in MB -->
<property name="default.indexwriter.ram_buffer_size">64</property>
<!-- Enable sharding on writers -->
<property name="default.sharding_strategy.nbr_of_shards">6</property>
<property name="lucene_version">LUCENE_CURRENT</property>
</indexing>
</local-cache>
<local-cache name="resource_indexes_metadata">
<persistence passivation="false">
<file-store preload="true" fetch-state="true" read-only="false" purge="false" path="${jboss.server.data.dir}/hawkular-inventory">
<write-behind thread-pool-size="5" />
</file-store>
</persistence>
<indexing index="NONE"/>
</local-cache>
<local-cache name="resource_indexes_data">
<persistence passivation="false">
<file-store preload="true" fetch-state="true" read-only="false" purge="false" path="${jboss.server.data.dir}/hawkular-inventory">
<write-behind thread-pool-size="5" />
</file-store>
</persistence>
<indexing index="NONE" />
</local-cache>
<local-cache name="resource_indexes_locking">
<persistence passivation="false">
<file-store preload="true" fetch-state="true" read-only="false" purge="false" path="${jboss.server.data.dir}/hawkular-inventory">
<write-behind thread-pool-size="5" />
</file-store>
</persistence>
<indexing index="NONE" />
</local-cache>
<local-cache name="resource_type" statistics="true">
<transaction mode="NON_XA"/>
<persistence>
<file-store preload="true" fetch-state="true" read-only="false" purge="false" path="${jboss.server.data.dir}/hawkular-inventory">
<write-behind thread-pool-size="5" modification-queue-size="10000" />
</file-store>
</persistence>
<indexing index="LOCAL">
<indexed-entities>
<indexed-entity>org.hawkular.inventory.service.ispn.IspnResourceType</indexed-entity>
</indexed-entities>
<property name="default.indexmanager">near-real-time</property>
<property name="default.directory_provider">infinispan</property>
<property name="default.chunk_size">128000</property>
<property name="default.locking_cachename">resource_type_indexes_locking</property>
<property name="default.data_cachename">resource_type_indexes_data</property>
<property name="default.metadata_cachename">resource_type_indexes_metadata</property>
<!-- The default is 10, but we don't want to waste many cycles in merging
(tune for writes at cost of reader fragmentation) -->
<property name="default.indexwriter.merge_factor">30</property>
<!-- Never create segments larger than 1GB -->
<property name="default.indexwriter.merge_max_size">1024</property>
<!-- IndexWriter flush buffer size in MB -->
<property name="default.indexwriter.ram_buffer_size">64</property>
<!-- Enable sharding on writers -->
<property name="default.sharding_strategy.nbr_of_shards">6</property>
<property name="lucene_version">LUCENE_CURRENT</property>
</indexing>
</local-cache>
<local-cache name="resource_type_indexes_metadata">
<persistence passivation="false">
<file-store preload="true" fetch-state="true" read-only="false" purge="false" path="${jboss.server.data.dir}/hawkular-inventory">
<write-behind thread-pool-size="5" />
</file-store>
</persistence>
<indexing index="NONE"/>
</local-cache>
<local-cache name="resource_type_indexes_data">
<persistence passivation="false">
<file-store preload="true" fetch-state="true" read-only="false" purge="false" path="${jboss.server.data.dir}/hawkular-inventory">
<write-behind thread-pool-size="5" />
</file-store>
</persistence>
<indexing index="NONE" />
</local-cache>
<local-cache name="resource_type_indexes_locking">
<persistence passivation="false">
<file-store preload="true" fetch-state="true" read-only="false" purge="false" path="${jboss.server.data.dir}/hawkular-inventory">
<write-behind thread-pool-size="5" />
</file-store>
</persistence>
<indexing index="NONE" />
</local-cache>
</cache-container>
{code}
At initialization, it tries to re-index existing resources*.dat files for data and lucene indexes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (ISPN-8411) Add support for efficient removeAll
by Emond Papegaaij (JIRA)
[ https://issues.jboss.org/browse/ISPN-8411?page=com.atlassian.jira.plugin.... ]
Emond Papegaaij commented on ISPN-8411:
---------------------------------------
I've put my test application on Github: https://github.com/topicusonderwijs/cachetest
It contains instructions on how to set it up. You'll need a database (like postgresql) and the driver in WildFly.
An failing example is:
* Insert 10 records on node1
* Refresh the page on node2, and press update on one of the records
* Read the value on node1 for that particular record
It will show '0' in the input field, but a random int in the table (which is read directly from the database).
I'm currently building your hibernate branch and integrate that version of hibernate in WildFly 11.0.0.CR1 and report back with the results.
> Add support for efficient removeAll
> -----------------------------------
>
> Key: ISPN-8411
> URL: https://issues.jboss.org/browse/ISPN-8411
> Project: Infinispan
> Issue Type: Feature Request
> Components: Hibernate Cache
> Affects Versions: 8.2.8.Final, 9.1.1.Final
> Environment: WildFly 10.1.0, WildFly 11.0.0.CR1, WildFly master, Hibernate 2LC
> Reporter: Emond Papegaaij
> Assignee: Galder Zamarreño
>
> Infinispan currently does not seem to implement an efficient way to clear an entire cache cluster-wide. This forces Hibernate to remove all entries one by one when a cache region needs to be cleared, for example when a buld CriteriaUpdate or CriteriaDelete is used.
> The behavior we are observing is:
> # All nodes in the cluster are queried for the keyset in a region
> # A lock seems to be in place for this region for the duration of the commit
> # The initiating node constructs a message with {{InvalidateCommands}} for all keys
> # This large message (230MB for 200k entries) is sent to all nodes in the cluster
> For large caches this can take very long. We had to increase the remote-timeout to 60 seconds to prevent timeouts. During this time, the entire cluster is locked an busy processing the cache invalidations. As you can understand, this is not a workable solution for us. On some places we can prevent the cache clear by updating the records one by one, but in other places this is not an option.
> The corresponding report at Hibernate can be found here: https://hibernate.atlassian.net/browse/HHH-12036
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (ISPN-8411) Add support for efficient removeAll
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-8411?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-8411:
-----------------------------------
Uh, seems I got it wrong: the BulkOperationCleanupAction seems to call {{RegionAccessStrategy.removeAll()}}, not {{evictAll()}} - that explains the behaviour you're seeing.
It should be possible to replace this with the clear() call for non-transactional caches, I've implemented the fix here and it seems to pass the testsuite: https://github.com/rvansa/hibernate-orm/tree/HHH-12036
> Add support for efficient removeAll
> -----------------------------------
>
> Key: ISPN-8411
> URL: https://issues.jboss.org/browse/ISPN-8411
> Project: Infinispan
> Issue Type: Feature Request
> Components: Hibernate Cache
> Affects Versions: 8.2.8.Final, 9.1.1.Final
> Environment: WildFly 10.1.0, WildFly 11.0.0.CR1, WildFly master, Hibernate 2LC
> Reporter: Emond Papegaaij
> Assignee: Galder Zamarreño
>
> Infinispan currently does not seem to implement an efficient way to clear an entire cache cluster-wide. This forces Hibernate to remove all entries one by one when a cache region needs to be cleared, for example when a buld CriteriaUpdate or CriteriaDelete is used.
> The behavior we are observing is:
> # All nodes in the cluster are queried for the keyset in a region
> # A lock seems to be in place for this region for the duration of the commit
> # The initiating node constructs a message with {{InvalidateCommands}} for all keys
> # This large message (230MB for 200k entries) is sent to all nodes in the cluster
> For large caches this can take very long. We had to increase the remote-timeout to 60 seconds to prevent timeouts. During this time, the entire cluster is locked an busy processing the cache invalidations. As you can understand, this is not a workable solution for us. On some places we can prevent the cache clear by updating the records one by one, but in other places this is not an option.
> The corresponding report at Hibernate can be found here: https://hibernate.atlassian.net/browse/HHH-12036
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (ISPN-8411) Add support for efficient removeAll
by Emond Papegaaij (JIRA)
[ https://issues.jboss.org/browse/ISPN-8411?page=com.atlassian.jira.plugin.... ]
Emond Papegaaij commented on ISPN-8411:
---------------------------------------
I've done some testing using a very simple application, and it seems invalidation (transactional or non-transactional) is broken for bulk updates. I do see differences in the messages sent, but the outcome is the same: only the keys on the node performing the update are invalidated in the cluster. When using a transactional cache, one large message is sent, containing all invalidations, whereas a non-transactional cache invalidates all entries one-by-one, with a message per entry. Either way entries in the cluster are invalidated one-by-one and only those entries on the initiating node are invalidated.
I'll make the demo application available on Github with instructions on how to set it up.
> Add support for efficient removeAll
> -----------------------------------
>
> Key: ISPN-8411
> URL: https://issues.jboss.org/browse/ISPN-8411
> Project: Infinispan
> Issue Type: Feature Request
> Components: Hibernate Cache
> Affects Versions: 8.2.8.Final, 9.1.1.Final
> Environment: WildFly 10.1.0, WildFly 11.0.0.CR1, WildFly master, Hibernate 2LC
> Reporter: Emond Papegaaij
> Assignee: Galder Zamarreño
>
> Infinispan currently does not seem to implement an efficient way to clear an entire cache cluster-wide. This forces Hibernate to remove all entries one by one when a cache region needs to be cleared, for example when a buld CriteriaUpdate or CriteriaDelete is used.
> The behavior we are observing is:
> # All nodes in the cluster are queried for the keyset in a region
> # A lock seems to be in place for this region for the duration of the commit
> # The initiating node constructs a message with {{InvalidateCommands}} for all keys
> # This large message (230MB for 200k entries) is sent to all nodes in the cluster
> For large caches this can take very long. We had to increase the remote-timeout to 60 seconds to prevent timeouts. During this time, the entire cluster is locked an busy processing the cache invalidations. As you can understand, this is not a workable solution for us. On some places we can prevent the cache clear by updating the records one by one, but in other places this is not an option.
> The corresponding report at Hibernate can be found here: https://hibernate.atlassian.net/browse/HHH-12036
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (ISPN-8415) Func eval: pass arbitrary value
by Radim Vansa (JIRA)
Radim Vansa created ISPN-8415:
---------------------------------
Summary: Func eval: pass arbitrary value
Key: ISPN-8415
URL: https://issues.jboss.org/browse/ISPN-8415
Project: Infinispan
Issue Type: Enhancement
Reporter: Radim Vansa
Assignee: Radim Vansa
The current API for eval methods and commands with values are limited to passing an argument of the same type as the stored value. This is limiting, sometimes we'd prefer to pass just a delta (of different type).
We'll keep a limitation that the delta needs to be encoded/decoded by the value decoder.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (ISPN-8180) Enhance functional API
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-8180?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-8180:
------------------------------
Summary: Enhance functional API (was: Add key to WriteEntryView)
> Enhance functional API
> ----------------------
>
> Key: ISPN-8180
> URL: https://issues.jboss.org/browse/ISPN-8180
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Reporter: Radim Vansa
> Assignee: Radim Vansa
> Fix For: 9.2.0.Final
>
>
> WriteOnlyKeyCommand should be able to simulate ComputeIfAbsentCommand without the conditional part (dropping the condition during when this is added to modifications list) and the signature for that command's remapping function is {{Function<K, V>}}. Therefore, we need to add key() to the WriteEntryView. This comes with no performance costs as the key is always at hand, no need to load it from anywhere.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (ISPN-8180) Add key to WriteEntryView
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-8180?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-8180:
------------------------------
Summary: Add key to WriteEntryView (was: Enhance functional API)
> Add key to WriteEntryView
> -------------------------
>
> Key: ISPN-8180
> URL: https://issues.jboss.org/browse/ISPN-8180
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Reporter: Radim Vansa
> Assignee: Radim Vansa
> Fix For: 9.2.0.Final
>
>
> WriteOnlyKeyCommand should be able to simulate ComputeIfAbsentCommand without the conditional part (dropping the condition during when this is added to modifications list) and the signature for that command's remapping function is {{Function<K, V>}}. Therefore, we need to add key() to the WriteEntryView. This comes with no performance costs as the key is always at hand, no need to load it from anywhere.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (ISPN-8410) BoundedOffHeapDataContainer can crash JVM
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-8410?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-8410:
-------------------------------
Status: Open (was: New)
> BoundedOffHeapDataContainer can crash JVM
> -----------------------------------------
>
> Key: ISPN-8410
> URL: https://issues.jboss.org/browse/ISPN-8410
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.1.1.Final, 9.2.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.2.0.Alpha2
>
>
> I have written a test that uses progressively larger values in order to test for fragmentation in the native heap, but it crashes the JVM:
> {noformat}
> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000008
> Stack: [0x00007f8456172000,0x00007f8456273000], sp=0x00007f84562709a0, free space=1018k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> J 3123 C1 org.infinispan.container.offheap.BoundedOffHeapDataContainer.entryRemoved(J)V (357 bytes) @ 0x00007f84b9673b23 [0x00007f84b96729a0+0x1183]
> J 3122 C1 org.infinispan.container.offheap.OffHeapDataContainer.performRemove(JLjava/lang/Object;)Lorg/infinispan/container/entries/InternalCacheEntry; (124 bytes) @ 0x00007f84b9780fb4 [0x00007f84b97807c0+0x7f4]
> J 3116 C1 org.infinispan.container.offheap.BoundedOffHeapDataContainer.ensureSize()V (401 bytes) @ 0x00007f84b97483bc [0x00007f84b9746a80+0x193c]
> J 3095 C1 org.infinispan.container.offheap.BoundedOffHeapDataContainer.put(Ljava/lang/Object;Ljava/lang/Object;Lorg/infinispan/metadata/Metadata;)V (14 bytes) @ 0x00007f84b9267f8c [0x00007f84b9267ca0+0x2ec]
> J 3091 C2 org.infinispan.statetransfer.CommitManager.commit(Lorg/infinispan/container/entries/CacheEntry;Lorg/infinispan/context/Flag;ZLorg/infinispan/context/InvocationContext;)V (146 bytes) @ 0x00007f84b9248aac [0x00007f84b9248260+0x84c]
> J 2655 C1 org.infinispan.interceptors.locking.ClusteringDependentLogic$LocalLogic.commitSingleEntry(Lorg/infinispan/container/entries/CacheEntry;Lorg/infinispan/commands/FlagAffectedCommand;Lorg/infinispan/context/InvocationContext;Lorg/infinispan/context/Flag;Z)V (129 bytes) @ 0x00007f84b9830d54 [0x00007f84b9830420+0x934]
> J 2628 C1 org.infinispan.interceptors.locking.ClusteringDependentLogic$AbstractClusteringDependentLogic.commitEntry(Lorg/infinispan/container/entries/CacheEntry;Lorg/infinispan/commands/FlagAffectedCommand;Lorg/infinispan/context/InvocationContext;Lorg/infinispan/context/Flag;Z)V (36 bytes) @ 0x00007f84b9821cfc [0x00007f84b98219a0+0x35c]
> J 2626 C1 org.infinispan.interceptors.impl.EntryWrappingInterceptor.commitEntryIfNeeded(Lorg/infinispan/context/InvocationContext;Lorg/infinispan/commands/FlagAffectedCommand;Lorg/infinispan/container/entries/CacheEntry;Lorg/infinispan/context/Flag;)Z (53 bytes) @ 0x00007f84b9822e64 [0x00007f84b9822580+0x8e4]
> J 3038 C1 org.infinispan.interceptors.impl.EntryWrappingInterceptor.commitContextEntries(Lorg/infinispan/context/InvocationContext;Lorg/infinispan/commands/FlagAffectedCommand;)V (167 bytes) @ 0x00007f84b91970ac [0x00007f84b9195d00+0x13ac]
> J 3033 C2 org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenAccept(Lorg/infinispan/context/InvocationContext;Lorg/infinispan/commands/VisitableCommand;Lorg/infinispan/interceptors/InvocationSuccessAction;)Ljava/lang/Object; (81 bytes) @ 0x00007f84b99a1cec [0x00007f84b99a17c0+0x52c]
> J 3084 C2 org.infinispan.interceptors.impl.EntryWrappingInterceptor.visitPutKeyValueCommand(Lorg/infinispan/context/InvocationContext;Lorg/infinispan/commands/write/PutKeyValueCommand;)Ljava/lang/Object; (13 bytes) @ 0x00007f84b9111c78 [0x00007f84b9111bc0+0xb8]
> J 2979 C2 org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitPutKeyValueCommand(Lorg/infinispan/context/InvocationContext;Lorg/infinispan/commands/write/PutKeyValueCommand;)Ljava/lang/Object; (24 bytes) @ 0x00007f84b99c06b4 [0x00007f84b99bf1a0+0x1514]
> J 3026 C2 org.infinispan.interceptors.impl.CacheMgmtInterceptor.visitPutKeyValueCommand(Lorg/infinispan/context/InvocationContext;Lorg/infinispan/commands/write/PutKeyValueCommand;)Ljava/lang/Object; (7 bytes) @ 0x00007f84b913567c [0x00007f84b9135620+0x5c]
> J 3064 C2 org.infinispan.cache.impl.EncoderCache.put(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; (27 bytes) @ 0x00007f84b9a3baf4 [0x00007f84b9a3b4a0+0x654]
> j org.infinispan.container.offheap.OffHeapBoundedSingleNodeStressTest.lambda$testLotsOfWrites$0(Ljava/util/Map;)Ljava/lang/Void;+21
> j org.infinispan.container.offheap.OffHeapBoundedSingleNodeStressTest$$Lambda$172.call()Ljava/lang/Object;+8
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (ISPN-8410) BoundedOffHeapDataContainer can crash JVM
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-8410?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-8410:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/5517
> BoundedOffHeapDataContainer can crash JVM
> -----------------------------------------
>
> Key: ISPN-8410
> URL: https://issues.jboss.org/browse/ISPN-8410
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.1.1.Final, 9.2.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.2.0.Alpha2
>
>
> I have written a test that uses progressively larger values in order to test for fragmentation in the native heap, but it crashes the JVM:
> {noformat}
> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000008
> Stack: [0x00007f8456172000,0x00007f8456273000], sp=0x00007f84562709a0, free space=1018k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> J 3123 C1 org.infinispan.container.offheap.BoundedOffHeapDataContainer.entryRemoved(J)V (357 bytes) @ 0x00007f84b9673b23 [0x00007f84b96729a0+0x1183]
> J 3122 C1 org.infinispan.container.offheap.OffHeapDataContainer.performRemove(JLjava/lang/Object;)Lorg/infinispan/container/entries/InternalCacheEntry; (124 bytes) @ 0x00007f84b9780fb4 [0x00007f84b97807c0+0x7f4]
> J 3116 C1 org.infinispan.container.offheap.BoundedOffHeapDataContainer.ensureSize()V (401 bytes) @ 0x00007f84b97483bc [0x00007f84b9746a80+0x193c]
> J 3095 C1 org.infinispan.container.offheap.BoundedOffHeapDataContainer.put(Ljava/lang/Object;Ljava/lang/Object;Lorg/infinispan/metadata/Metadata;)V (14 bytes) @ 0x00007f84b9267f8c [0x00007f84b9267ca0+0x2ec]
> J 3091 C2 org.infinispan.statetransfer.CommitManager.commit(Lorg/infinispan/container/entries/CacheEntry;Lorg/infinispan/context/Flag;ZLorg/infinispan/context/InvocationContext;)V (146 bytes) @ 0x00007f84b9248aac [0x00007f84b9248260+0x84c]
> J 2655 C1 org.infinispan.interceptors.locking.ClusteringDependentLogic$LocalLogic.commitSingleEntry(Lorg/infinispan/container/entries/CacheEntry;Lorg/infinispan/commands/FlagAffectedCommand;Lorg/infinispan/context/InvocationContext;Lorg/infinispan/context/Flag;Z)V (129 bytes) @ 0x00007f84b9830d54 [0x00007f84b9830420+0x934]
> J 2628 C1 org.infinispan.interceptors.locking.ClusteringDependentLogic$AbstractClusteringDependentLogic.commitEntry(Lorg/infinispan/container/entries/CacheEntry;Lorg/infinispan/commands/FlagAffectedCommand;Lorg/infinispan/context/InvocationContext;Lorg/infinispan/context/Flag;Z)V (36 bytes) @ 0x00007f84b9821cfc [0x00007f84b98219a0+0x35c]
> J 2626 C1 org.infinispan.interceptors.impl.EntryWrappingInterceptor.commitEntryIfNeeded(Lorg/infinispan/context/InvocationContext;Lorg/infinispan/commands/FlagAffectedCommand;Lorg/infinispan/container/entries/CacheEntry;Lorg/infinispan/context/Flag;)Z (53 bytes) @ 0x00007f84b9822e64 [0x00007f84b9822580+0x8e4]
> J 3038 C1 org.infinispan.interceptors.impl.EntryWrappingInterceptor.commitContextEntries(Lorg/infinispan/context/InvocationContext;Lorg/infinispan/commands/FlagAffectedCommand;)V (167 bytes) @ 0x00007f84b91970ac [0x00007f84b9195d00+0x13ac]
> J 3033 C2 org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenAccept(Lorg/infinispan/context/InvocationContext;Lorg/infinispan/commands/VisitableCommand;Lorg/infinispan/interceptors/InvocationSuccessAction;)Ljava/lang/Object; (81 bytes) @ 0x00007f84b99a1cec [0x00007f84b99a17c0+0x52c]
> J 3084 C2 org.infinispan.interceptors.impl.EntryWrappingInterceptor.visitPutKeyValueCommand(Lorg/infinispan/context/InvocationContext;Lorg/infinispan/commands/write/PutKeyValueCommand;)Ljava/lang/Object; (13 bytes) @ 0x00007f84b9111c78 [0x00007f84b9111bc0+0xb8]
> J 2979 C2 org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitPutKeyValueCommand(Lorg/infinispan/context/InvocationContext;Lorg/infinispan/commands/write/PutKeyValueCommand;)Ljava/lang/Object; (24 bytes) @ 0x00007f84b99c06b4 [0x00007f84b99bf1a0+0x1514]
> J 3026 C2 org.infinispan.interceptors.impl.CacheMgmtInterceptor.visitPutKeyValueCommand(Lorg/infinispan/context/InvocationContext;Lorg/infinispan/commands/write/PutKeyValueCommand;)Ljava/lang/Object; (7 bytes) @ 0x00007f84b913567c [0x00007f84b9135620+0x5c]
> J 3064 C2 org.infinispan.cache.impl.EncoderCache.put(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; (27 bytes) @ 0x00007f84b9a3baf4 [0x00007f84b9a3b4a0+0x654]
> j org.infinispan.container.offheap.OffHeapBoundedSingleNodeStressTest.lambda$testLotsOfWrites$0(Ljava/util/Map;)Ljava/lang/Void;+21
> j org.infinispan.container.offheap.OffHeapBoundedSingleNodeStressTest$$Lambda$172.call()Ljava/lang/Object;+8
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (ISPN-8414) Use ANSI colors in the testsuite progress reporter
by Tristan Tarrant (JIRA)
Tristan Tarrant created ISPN-8414:
-------------------------------------
Summary: Use ANSI colors in the testsuite progress reporter
Key: ISPN-8414
URL: https://issues.jboss.org/browse/ISPN-8414
Project: Infinispan
Issue Type: Bug
Components: Test Suite - Core
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
We can make the testsuite progress reporter much more readable if we use colors to distinguish sucessful/failed tests
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months