September 2018 - infinispan-issues

[JBoss JIRA] (ISPN-8491) Add streaming variant of off heap to not create byte[] instances

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-8491?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8491: ---------------------------------- Fix Version/s: 9.4.0.Final (was: 9.4.0.CR3) > Add streaming variant of off heap to not create byte[] instances > ---------------------------------------------------------------- > > Key: ISPN-8491 > URL: https://issues.jboss.org/browse/ISPN-8491 > Project: Infinispan > Issue Type: Sub-task > Components: Off Heap > Reporter: William Burns > Fix For: 9.4.0.Final > > > Currently off heap has to create a byte[] to copy memory from off heap. This is a waste of CPU and memory to do so. Instead we should have a streaming variant Output that the GlobalMarshaller can use that doesn't need all of this unnecessary copying. Unfortunately GlobalMarshaller is currently internally hard coded to require the usage of byte[] so we would have to tweak some code there as well to allow this. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8487) Global MBean registration happens too soon

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-8487?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8487: ---------------------------------- Fix Version/s: 9.4.0.Final (was: 9.4.0.CR3) > Global MBean registration happens too soon > ------------------------------------------ > > Key: ISPN-8487 > URL: https://issues.jboss.org/browse/ISPN-8487 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.2.0.Alpha2 > Reporter: Dan Berindei > Fix For: 9.4.0.Final > > > Currently {{DefaultCacheManager}} explicitly starts {{CacheManagerJmxRegistration}} before calling {{ModuleLifecycle#cacheManagerStarting}}, which means MBeans in other modules are not registered in JMX. > We should start {{CacheManagerJmxRegistration}} only during global component registry start, after the modules have registered their components. If we want to make the cache manager available in JMX before {{DefaultCacheManager.start()}}, we should only register that particular MBean. Conversely, on shutdown, components other than the cache manager should be removed from JMX on {{DefaultCacheManager.stop()}} (as per ISPN-118). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8486) Make file store work with home relative paths

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-8486?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8486: ---------------------------------- Fix Version/s: 9.4.0.Final (was: 9.4.0.CR3) > Make file store work with home relative paths > --------------------------------------------- > > Key: ISPN-8486 > URL: https://issues.jboss.org/browse/ISPN-8486 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 9.4.0.Final > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8482) Projection of enum field returns number instead of constant

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-8482?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8482: ---------------------------------- Fix Version/s: 9.4.0.Final (was: 9.4.0.CR3) > Projection of enum field returns number instead of constant > ----------------------------------------------------------- > > Key: ISPN-8482 > URL: https://issues.jboss.org/browse/ISPN-8482 > Project: Infinispan > Issue Type: Bug > Components: Remote Querying > Affects Versions: 9.2.0.Alpha2 > Reporter: Gustavo Fernandes > Assignee: Adrian Nistor > Fix For: 9.4.0.Final > > > Consider the query below where Gender is mapped in protobuf as an {{enum}}: > {code:sql} > select p.gender, count(p.name) from Person p group by p.gender > {code} > The returned projection is numeric rather than MALE/FEMALE. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8453) Commit should fail if cache is in degraded mode

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-8453?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8453: ---------------------------------- Fix Version/s: 9.4.0.Final (was: 9.4.0.CR3) > Commit should fail if cache is in degraded mode > ----------------------------------------------- > > Key: ISPN-8453 > URL: https://issues.jboss.org/browse/ISPN-8453 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.1.9.Final, 8.2.8.Final, 9.1.2.Final, 9.2.0.Alpha2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.4.0.Final > > > When the originator receives a {{CacheNotFoundResponse}} and the cache is in degraded mode, the transaction is marked as partially completed, but the commit completes successfully. > I believe that is not correct, because the originator could crash after the commit but before the merge, and in that case the transaction will not be applied on all the owners. The transaction manager will ignore any commit exception in {{NON_XA}}/{{useSynchronization}} mode, but at least in {{FULL_XA}}/{{NON_DURABLE_XA}} mode we can signal to the user that the transaction may be lost. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8451) Attributes in AttributeSets should state whether they apply globally or per-node

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-8451?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8451: ---------------------------------- Fix Version/s: 9.4.0.Final (was: 9.4.0.CR3) > Attributes in AttributeSets should state whether they apply globally or per-node > -------------------------------------------------------------------------------- > > Key: ISPN-8451 > URL: https://issues.jboss.org/browse/ISPN-8451 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.4.0.Final > > > Add an additional boolean to AttributeDefinition that defines whether the attribute is global or local. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8441) The module spec used by server config of indexed-entities/indexed-entity and modules/module accepts only deployments

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-8441?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8441: ---------------------------------- Fix Version/s: 9.4.0.Final (was: 9.4.0.CR3) > The module spec used by server config of indexed-entities/indexed-entity and modules/module accepts only deployments > -------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-8441 > URL: https://issues.jboss.org/browse/ISPN-8441 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 9.1.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.4.0.Final > > > The module name must start with "deployment." due to the use ServiceModuleLoader.moduleServiceName() method to resolve a service name from a module name. This only knows to handle deployments from 'deployment' dir, regular modules from the 'modules' dir are not handled. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8772) Update Server Licenses

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-8772?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8772: ---------------------------------- Fix Version/s: 9.4.0.Final (was: 9.4.0.CR3) > Update Server Licenses > ---------------------- > > Key: ISPN-8772 > URL: https://issues.jboss.org/browse/ISPN-8772 > Project: Infinispan > Issue Type: Task > Components: Build > Affects Versions: 9.2.0.CR2 > Reporter: Ryan Emerson > Fix For: 9.4.0.Final > > > After upgrading the server to wildfly 11, the server license files have become outdated and should be updated. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8721) Clustered 2nd level cache sometimes throws NullPointerException when new node starts up

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-8721?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8721: ---------------------------------- Fix Version/s: 9.4.0.Final (was: 9.4.0.CR3) > Clustered 2nd level cache sometimes throws NullPointerException when new node starts up > --------------------------------------------------------------------------------------- > > Key: ISPN-8721 > URL: https://issues.jboss.org/browse/ISPN-8721 > Project: Infinispan > Issue Type: Bug > Components: Hibernate Cache > Affects Versions: 9.1.4.Final > Environment: jvm 1.8 > Reporter: Tom Dearman > Assignee: Tom Dearman > Fix For: 9.4.0.Final > > Attachments: sample-app.cache.tar.gz > > > There is a race condition in PutFromLoadValidator as it registers itself in the component registry before it is fully initialised. You can reproduce this by running the contained app against h2 server db. First start this app with default port. Then start the app on port '8080' and make a few requests to '/add' to create data. After that send continuous requests to '/update' in order change data and trigger the cache: > for i in > {code} > {1..1000} > ; do sleep 0.01; curl http://localhost:8080/update -X POST; done > {code} > Then start another instance of the app on port 8090: > {code} > java -jar test-app-0.0.1-SNAPSHOT.jar --server.port=8090 > {code} > Most of the time one of the updates will fail and the logs will show the following: > {code} > 2018-01-23 15:36:46 [main] DEBUG o.h.c.i.access.PutFromLoadValidator - Interceptor chain was: [org.infinispan.interceptors.InvocationContextInterceptor@407a7f2a, org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor@4ea5b703, org.infinispan.interceptors.EntryWrappingInterceptor@2a7ed1f, org.infinispan.interceptors.InvalidationInterceptor@3fa247d1, org.infinispan.interceptors.CallInterceptor@2cb2fc20] > 2018-01-23 15:36:46 [main] DEBUG o.h.c.i.access.PutFromLoadValidator - New interceptor chain is: [org.infinispan.interceptors.InvocationContextInterceptor@407a7f2a, org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor@4ea5b703, org.hibernate.cache.infinispan.access.NonTxPutFromLoadInterceptor@495ee280, org.infinispan.interceptors.EntryWrappingInterceptor@2a7ed1f, org.hibernate.cache.infinispan.access.NonTxInvalidationInterceptor@4fa1c212, org.infinispan.interceptors.CallInterceptor@2cb2fc20] > 2018-01-23 15:36:46 [main] TRACE o.i.manager.DefaultCacheManager - About to wire and start cache test.app.data.User-pending-puts > 2018-01-23 15:36:46 [remote-thread--p2-t1] ERROR o.i.i.InvocationContextInterceptor - ISPN000136: Error executing command BeginInvalidationCommand, writing keys test.app.data.User#2 > java.lang.NullPointerException: null > at org.hibernate.cache.infinispan.access.PutFromLoadValidator.beginInvalidatingWithPFER(PutFromLoadValidator.java:561) > at org.hibernate.cache.infinispan.access.PutFromLoadValidator.beginInvalidatingKey(PutFromLoadValidator.java:555) > at org.hibernate.cache.infinispan.access.NonTxPutFromLoadInterceptor.visitInvalidateCommand(NonTxPutFromLoadInterceptor.java:70) > at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:114) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99) > at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitInvalidateCommand(AbstractLockingInterceptor.java:112) > at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:114) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99) > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110) > at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:79) > at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:127) > at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:114) > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:335) > at org.infinispan.commands.remote.BaseRpcInvokingCommand.processVisitableCommand(BaseRpcInvokingCommand.java:43) > at org.infinispan.commands.remote.SingleRpcCommand.perform(SingleRpcCommand.java:51) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokePerform(BasePerCacheInboundInvocationHandler.java:92) > at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:34) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > 2018-01-23 15:36:47 [main] TRACE o.i.manager.DefaultCacheManager - Closing latch for cache test.app.data.User-pending-puts > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8691) Infinispan rejects to read cache file bigger than 2147483647 (Integer.MAX_VALUE)

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-8691?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8691: ---------------------------------- Fix Version/s: 9.4.0.Final (was: 9.4.0.CR3) > Infinispan rejects to read cache file bigger than 2147483647 (Integer.MAX_VALUE) > -------------------------------------------------------------------------------- > > Key: ISPN-8691 > URL: https://issues.jboss.org/browse/ISPN-8691 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 9.1.1.Final > Reporter: Dmitry Katsubo > Assignee: Ryan Emerson > Priority: Minor > Fix For: 9.4.0.Final > > > In my scenario the cache file size created by {{SingleFileStore}} is 3.054.196.342 bytes. When this file is tried to be loaded, it fails with the following exception: > {code} > Caused by: org.infinispan.persistence.spi.PersistenceException: ISPN000279: Failed to read stored entries from file. Error in file /work/search-service-layer_data/infinispan/cache_test_dk83146/markupCache.dat at offset 4 > at org.infinispan.persistence.file.SingleFileStore.rebuildIndex(SingleFileStore.java:182) > at org.infinispan.persistence.file.SingleFileStore.start(SingleFileStore.java:127) > ... 155 more > {code} > Cache file content: > {code} > 0000000000: 46 43 53 31 80 B1 89 47 │ 00 00 00 00 00 00 00 00 FCS1?+%G > 0000000010: 00 00 00 00 FF FF FF FF │ FF FF FF FF 02 15 4E 06 yyyyyyyy☻§N♠ > 0000000020: 05 03 04 09 00 00 00 2F │ 6F 72 67 2E 73 70 72 69 ♣♥♦○ /org.spri > 0000000030: 6E 67 66 72 61 6D 65 77 │ 6F 72 6B 2E 63 61 63 68 ngframework.cach > 0000000040: 65 2E 69 6E 74 65 72 63 │ 65 70 74 6F 72 2E 53 69 e.interceptor.Si > 0000000050: 6D 70 6C 65 4B 65 79 4C │ 0A 57 03 6B 6D 93 D8 00 mpleKeyL◙W♥km"O > 0000000060: 00 00 02 00 00 00 08 68 │ 61 73 68 43 6F 64 65 23 ☻ ◘hashCode# > 0000000070: 00 00 00 00 06 70 61 72 │ 61 6D 73 16 00 16 15 E6 ♠params▬ ▬§? > {code} > The problem is that integer value 0x80B18947 is treated as signed integer in line {{SingleFileStore:181}}, hence in expression > {code} > if (fe.size < KEY_POS + fe.keyLen + fe.dataLen + fe.metadataLen) { > throw log.errorReadingFileStore(file.getPath(), filePos); > } > {code} > {{fe.size}} is negative and equal to -2135848633. > I have tried to configure the persistence storage so that it gets purged on start: > {code} > <persistence passivation="true"> > <file-store path="/var/cache/infinispan" purge="true"> > <write-behind thread-pool-size="5" /> > </file-store> > </persistence> > {code} > however this does not help as storage is first read and then purged (see also ISPN-7186). > It is expected that {{SingleFileStore}} either does not allow to write such big entries to the cache, or handles them correctly. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2018