September 2018 - infinispan-issues

[JBoss JIRA] (ISPN-9127) Remote commands can access components before they are started

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9127?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9127: ---------------------------------- Sprint: Sprint 9.4.0.Beta1, Sprint 9.4.0.CR1, Sprint 9.4.0.CR3, Sprint 9.4.0.Final (was: Sprint 9.4.0.Beta1, Sprint 9.4.0.CR1, Sprint 9.4.0.CR3) > Remote commands can access components before they are started > ------------------------------------------------------------- > > Key: ISPN-9127 > URL: https://issues.jboss.org/browse/ISPN-9127 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.2.2.Final, 9.3.0.Alpha1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: testsuite_stability > > {{PerCacheInboundInvocationHandler.handle()}} may be called before the component was started, because {{GlobalInboundInvocationHandler}} fetches it from the component registry without any checks. {{CommandsFactoryImpl.initializeReplicableCommand()}} doesn't wait for the components that it injects into remote commands to be started, either. > This started causing random test failures in {{ConcurrentStartForkChannelTest}} after ISPN-8515, which moved most initialization work from {{init()}} methods to {{start()}} methods. Because {{StateProviderImpl}} starts after {{StateTransferManagerImpl}}, it's possible for a node to receive a {{StateRequestCommand}} before {{StateProviderImpl}} has initialized: > {noformat} > 16:15:09,549 TRACE (remote-thread-Test-NodeB-p51957-t2:[org.infinispan.CONFIG]) [StateProviderImpl] Starting outbound transfer to node Test-NodeA for cache null, topology id 2, segments {0-255} > 16:15:09,551 WARN (remote-thread-Test-NodeB-p51957-t2:[]) [NonTotalOrderPerCacheInboundInvocationHandler] ISPN000071: Caught exception when handling command StateRequestCommand{cache=org.infinispan.CONFIG, origin=Test-NodeA, type=START_STATE_TRANSFER, topologyId=2, segments={0-255}} > java.lang.IllegalArgumentException: chunkSize must be greater than 0 > at org.infinispan.statetransfer.OutboundTransferTask.<init>(OutboundTransferTask.java:114) ~[classes/:?] > at org.infinispan.statetransfer.StateProviderImpl.startOutboundTransfer(StateProviderImpl.java:273) ~[classes/:?] > at org.infinispan.statetransfer.StateRequestCommand.invokeAsync(StateRequestCommand.java:101) ~[classes/:?] > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokeCommand(BasePerCacheInboundInvocationHandler.java:94) ~[classes/:?] > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8234) Add support for @Spatial, @Latitude, @Longitude annotations in protobuf schema

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-8234?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8234: ---------------------------------- Sprint: Sprint 9.3.0.Beta1, Sprint 9.3.0.CR1, Sprint 9.4.0.Beta1, Sprint 9.4.0.CR1, Sprint 9.4.0.CR3, Sprint 9.4.0.Final (was: Sprint 9.3.0.Beta1, Sprint 9.3.0.CR1, Sprint 9.4.0.Beta1, Sprint 9.4.0.CR1, Sprint 9.4.0.CR3) > Add support for @Spatial, @Latitude, @Longitude annotations in protobuf schema > ------------------------------------------------------------------------------ > > Key: ISPN-8234 > URL: https://issues.jboss.org/browse/ISPN-8234 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.4.0.Final > > > These annotations must behave identically to their Hibernate Search counterparts defined in org.hibernate.search.annotations package. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5997) JMX operation ClusterCacheStats.resetStatistics() not working

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5997?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5997: ---------------------------------- Sprint: Sprint 9.4.0.Beta1, Sprint 9.4.0.CR1, Sprint 9.4.0.CR3, Sprint 9.4.0.Final (was: Sprint 9.4.0.Beta1, Sprint 9.4.0.CR1, Sprint 9.4.0.CR3) > JMX operation ClusterCacheStats.resetStatistics() not working > ------------------------------------------------------------- > > Key: ISPN-5997 > URL: https://issues.jboss.org/browse/ISPN-5997 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 8.1.0.CR1 > Reporter: Jiří Holuša > Assignee: Vladimir Blagojevic > > Environment: 2 servers started in domain mode (ISPN 8.1.0.CR1). > Having some clustered cache, inserted/read some entries (just to create some statistics). > When connected via JMX (e.g. through JConsole, see https://issues.jboss.org/browse/ISPN-5983 ) to one of the servers, I execute resetStatistics() operation on ClusterCacheStats MBean (object name: jboss.datagrid-infinispan:type=Cache,name="<cache-name>",manager="<cache-container-name>",component=ClusterCacheStats) and nothing happens, the cluster statistics are not reset. > To actually reset the statistics, I have to connect to each of the servers in domain individually and call resetStatistics() on Statistics MBean, which deletes "a portion" of statistics of that particular server to the cluster stats. > I would expect ClusterCacheStats.resetStatistics() to do exactly the same: call Statistics.resetStatistics() on each server. -- 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: ---------------------------------- Sprint: Sprint 9.4.0.CR1, Sprint 9.4.0.CR3, Sprint 9.4.0.Final (was: Sprint 9.4.0.CR1, Sprint 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

[JBoss JIRA] (ISPN-9382) Jenkins release pipeline should handle multiple branches and reversioning

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9382?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9382: ---------------------------------- Sprint: Sprint 9.4.0.Beta1, Sprint 9.4.0.CR1, Sprint 9.4.0.CR3, Sprint 9.4.0.Final (was: Sprint 9.4.0.Beta1, Sprint 9.4.0.CR1, Sprint 9.4.0.CR3) > Jenkins release pipeline should handle multiple branches and reversioning > ------------------------------------------------------------------------- > > Key: ISPN-9382 > URL: https://issues.jboss.org/browse/ISPN-9382 > Project: Infinispan > Issue Type: Enhancement > Components: Build > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > 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-9507) Upgrade Hibernate Search to 5.10.3

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9507?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9507: ---------------------------------- Sprint: Sprint 9.4.0.CR3, Sprint 9.4.0.Final (was: Sprint 9.4.0.CR3) > Upgrade Hibernate Search to 5.10.3 > ---------------------------------- > > Key: ISPN-9507 > URL: https://issues.jboss.org/browse/ISPN-9507 > Project: Infinispan > Issue Type: Component Upgrade > Components: Build, Embedded Querying > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.4.0.Final > > > Aligns with WF 14. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7979) Include all component licenses in distributions

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7979?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7979: ---------------------------------- Sprint: Sprint 9.3.0.Alpha1, Sprint 9.3.0.Beta1, Sprint 9.3.0.CR1, Sprint 9.3.0.Final, Sprint 9.4.0.Beta1, Sprint 9.4.0.CR1, Sprint 9.4.0.CR3, Sprint 9.4.0.Final (was: Sprint 9.3.0.Alpha1, Sprint 9.3.0.Beta1, Sprint 9.3.0.CR1, Sprint 9.3.0.Final, Sprint 9.4.0.Beta1, Sprint 9.4.0.CR1, Sprint 9.4.0.CR3) > Include all component licenses in distributions > ----------------------------------------------- > > Key: ISPN-7979 > URL: https://issues.jboss.org/browse/ISPN-7979 > Project: Infinispan > Issue Type: Task > Components: Build > Reporter: Tristan Tarrant > Assignee: Jakub Senko > Priority: Blocker > Fix For: 9.4.0.Final > > > The distributions should include licenses for all components -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7409) Replace external marshaller with user marshaller

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7409?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7409: ---------------------------------- Sprint: Sprint 9.4.0.Beta1, Sprint 9.4.0.CR1, Sprint 9.4.0.CR3, Sprint 9.4.0.Final (was: Sprint 9.4.0.Beta1, Sprint 9.4.0.CR1, Sprint 9.4.0.CR3) > Replace external marshaller with user marshaller > ------------------------------------------------ > > Key: ISPN-7409 > URL: https://issues.jboss.org/browse/ISPN-7409 > Project: Infinispan > Issue Type: Enhancement > Components: Core, Marshalling > Reporter: Galder Zamarreño > Assignee: Ryan Emerson > Fix For: 10.0.0.Final > > > ISPN-6906 brings much needed independence from JBoss Marshalling to our marshalling layer. One of the key aspects it brings it’s the separation between marshalling internal types we know about, e.g. String, byte[], CacheTopologyCommand...etc and external or unknown types, e.g. any types that extend Serializable. > Although this separation helps achieve objectives of ISPN-6906, it’s not an ideal solution: > * If user types map directly to primitive types supported by our internal marshaller, or types that depend on types that are marshalled by our internal marshaller, any changes made to the internal marshaller have a direct impact on the representation of the user types. > * In the ISPN-6906 implementation, Internal marshaller exposes its own externalizer table to the external marshaller so that it can lookup how to marshall internal types. This is done to support corner cases in Hibernate Search where some of the classes that Query module marshalls rely on the fact that some Hibernate Search classes are Serializable, but these classes reference Lucene query classes that are not for which there are externalizers defined. For query logic to work, externalizers have to be found while dealing with Serializable types are being traversed. Gustavo and Sane are aware of this issue and we should soon have externalizers for those Hibernate Search classes and avoid this issue altogether (see ISPN-7156). > So, rather than an external marshaller, a more suitable abstraction would be to have a user marshaller. The job of the user marshaller, which would be configurable, would be to marshall user types. The user marshaller should be independent of the internal marshaller, so it would not be able to piggyback on the internal externalizers. > Externalizers for user types could still be supported, by having a user externalizer table, purely used by the user marshaller. In fact, it would make sense that all externalizers that are configured in Infinispan (regardless of whether via xml, programmatic or via annotation) to be user externalizers. > User types are considered to be: > * Keys and values > * Metadata instances provided by the user via *withMetadata() calls > The benefits of the user marshaller are the following: > * Having the user marshaller configurable would make it easy to try out different marshallers when comparing how key/value types are marshalled, e.g. try out different ways to marshall Strings. > * An easier upgrade path for user types. Since user types no longer rely on internal marshaller details, Infinispan upgrades are easier to deal with. > For reference, custom commands that can be plugged via ModuleCommandFactory implementations would use the internal marshaller since these commands often marshall internal types, e.g. Address. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7624) Change CacheLoaderInterceptor to ignore in memory for certain operations when passivation is not enabled

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7624?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7624: ---------------------------------- Sprint: Sprint 9.4.0.CR1, Sprint 9.4.0.CR3, Sprint 9.4.0.Final (was: Sprint 9.4.0.CR1, Sprint 9.4.0.CR3) > Change CacheLoaderInterceptor to ignore in memory for certain operations when passivation is not enabled > -------------------------------------------------------------------------------------------------------- > > Key: ISPN-7624 > URL: https://issues.jboss.org/browse/ISPN-7624 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Reporter: William Burns > Assignee: William Burns > Fix For: 9.4.0.Final > > > CacheLoader currently reads all in memory entries and then the store for bulk operations. This can be changed to only load from the store when passivation is not used as it should contain all entries that aren't in memory. > The only issue is that if Flag.SKIP_CACHE_STORE was used on a write. In this case we could store a boolean in the interceptor so that if this Flag is ever used we always do both. Very few users use this Flag and it should improve performance a bit and entries should be seen more consistently. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7035) Move spring modules to proper packages

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7035?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7035: ---------------------------------- Sprint: Sprint 9.4.0.CR1, Sprint 9.4.0.CR3, Sprint 9.4.0.Final (was: Sprint 9.4.0.CR1, Sprint 9.4.0.CR3) > Move spring modules to proper packages > -------------------------------------- > > Key: ISPN-7035 > URL: https://issues.jboss.org/browse/ISPN-7035 > Project: Infinispan > Issue Type: Enhancement > Reporter: Sebastian Łaskawiec > Assignee: Katia Aresti > Priority: Critical > Fix For: 10.0.0.Final > > > Currently everything is placed in {{org.infinispan.spring}} package. We should provide exactly the same split as we did in CDI ({{org.infinispan.spring}} into {{org.infinispan.spring.remote}} and {{org.infinispan.spring.embedded}}) -- 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