November 2018 - infinispan-issues

[JBoss JIRA] (ISPN-9745) Release fails because compatibility bundle modules don't have source jars

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9745?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9745: ---------------------------------- Fix Version/s: 9.4.4.Final (was: 9.4.3.Final) > Release fails because compatibility bundle modules don't have source jars > ------------------------------------------------------------------------- > > Key: ISPN-9745 > URL: https://issues.jboss.org/browse/ISPN-9745 > Project: Infinispan > Issue Type: Bug > Components: Build > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Alpha2, 9.4.4.Final > > > Modules {{client/marshaller/protostuff/protostuff-marshaller-compatibility-bundle}} and {{client/marshaller/protostuff/protostuff-marshaller-compatibility-bundle}} are uber-jars and don't have any sources. > Prior to the ISPN-9697 changes, a {{DEPENDENCIES.txt}} and {{LICENSES.txt}} was generated in the source directory, and a test-sources jar was created. But after those files were removed, a test-sources jar is no longer generated, and Nexus rejects the artifacts: > {noformat} > 11:19:37.492 [ERROR] > 11:19:37.492 [ERROR] Nexus Staging Rules Failure Report > 11:19:37.492 [ERROR] ================================== > 11:19:37.492 [ERROR] > 11:19:37.493 [ERROR] Repository "jboss_releases_staging_profile-14551" failures > 11:19:37.493 [ERROR] Rule "sources-staging" failures > 11:19:37.493 [ERROR] * Missing: no sources jar found in folder '/org/infinispan/infinispan-marshaller-kryo-bundle/9.4.2.Final' > 11:19:37.493 [ERROR] * Missing: no sources jar found in folder '/org/infinispan/infinispan-marshaller-protostuff-bundle/9.4.2.Final' > {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9727) Ickle query ignores an IN clause if there is only one value

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9727?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9727: ---------------------------------- Fix Version/s: 9.4.4.Final (was: 9.4.3.Final) > Ickle query ignores an IN clause if there is only one value > ----------------------------------------------------------- > > Key: ISPN-9727 > URL: https://issues.jboss.org/browse/ISPN-9727 > Project: Infinispan > Issue Type: Bug > Reporter: Wolf-Dieter Fink > Assignee: Adrian Nistor > Priority: Critical > Fix For: 9.3.4.Final, 10.0.0.Alpha2, 9.4.4.Final > > > If an Ickl query has an IN clause in combination with another condition the IN clause seems completely ignored if it has only one value. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9726) Document max clause property on boolean query

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9726?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9726: ---------------------------------- Fix Version/s: 9.4.4.Final (was: 9.4.3.Final) > Document max clause property on boolean query > --------------------------------------------- > > Key: ISPN-9726 > URL: https://issues.jboss.org/browse/ISPN-9726 > Project: Infinispan > Issue Type: Task > Components: Embedded Querying, Remote Querying > Affects Versions: 10.0.0.Alpha1 > Reporter: Katia Aresti > Assignee: Adrian Nistor > Priority: Major > Fix For: 10.0.0.Alpha2, 9.4.4.Final > > > Document the ability to override org.apache.lucene.search.BooleanQuery.maxClauseCount using infinispan.query.lucene.max-boolean-clauses JVM system property. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9699) Cluster member owning no data

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9699?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9699: ---------------------------------- Fix Version/s: 9.4.4.Final (was: 9.4.3.Final) > Cluster member owning no data > ----------------------------- > > Key: ISPN-9699 > URL: https://issues.jboss.org/browse/ISPN-9699 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 9.4.1.Final > Reporter: Thomas Segismont > Assignee: Katia Aresti > Priority: Major > Fix For: 10.0.0.Alpha2, 9.4.4.Final > > > Currently, you can set {{capacity-factor}} to zero on a cache if you don't want a node to own any segment. > If you want a node to own no data at all, you could set this property on all declared caches. But this wouldn't work for internal caches anyway (locks, counters). > It would be nice to have a global switch. > This would be useful when your app needs to be a cluster member for discovery/membership but is deployed mostly for processing. Indeed, when such nodes are added/removed from the cluster: > * there would be no data loss > * the cluster would be back in healthy state faster as no data would be moved around. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9677) Non-transactional queries don't update the query cache

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9677?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9677: ---------------------------------- Fix Version/s: 9.4.4.Final (was: 9.4.3.Final) > Non-transactional queries don't update the query cache > ------------------------------------------------------ > > Key: ISPN-9677 > URL: https://issues.jboss.org/browse/ISPN-9677 > Project: Infinispan > Issue Type: Bug > Components: Hibernate Cache > Affects Versions: 9.4.1.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Major > Fix For: 10.0.0.Alpha1, 9.4.4.Final > > > This is affecting the Hibernate second-level cache simple tutorials where queries are executed outside transactions. > The problem is that the new integration for the query results (result of ISPN-9075) does not verify if there's an on-going transaction before registering a transaction completed synchronization where the query cache is updated. > As a result, when a non-transactional query happens, the transaction synchronization callback does not happen and the query cache is not updated. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9657) Multimap jar is not OSGi compliant

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9657?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9657: ---------------------------------- Fix Version/s: 9.4.4.Final (was: 9.4.3.Final) > Multimap jar is not OSGi compliant > ---------------------------------- > > Key: ISPN-9657 > URL: https://issues.jboss.org/browse/ISPN-9657 > Project: Infinispan > Issue Type: Bug > Components: Multimap > Affects Versions: 9.4.0.Final > Reporter: Alain Picard > Assignee: Katia Aresti > Priority: Major > Fix For: 10.0.0.Alpha2, 9.4.4.Final > > > Due to issues related to using the embedded jar (see [here|https://developer.jboss.org/message/986042#986042], when switching to individual jars, the multimap jar (infinispan-multimap-9.4.0.Final.jar) doesn't provide a valid OSGi manifest. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9610) Expose PersistenceManager availability via JMX

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9610?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9610: ---------------------------------- Fix Version/s: 9.4.4.Final (was: 9.4.3.Final) > Expose PersistenceManager availability via JMX > ---------------------------------------------- > > Key: ISPN-9610 > URL: https://issues.jboss.org/browse/ISPN-9610 > Project: Infinispan > Issue Type: Enhancement > Components: JMX, reporting and management > Affects Versions: 9.4.0.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 9.4.4.Final > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9646) Docs: Merge Details on Protocol Interoperability

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9646?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9646: ---------------------------------- Fix Version/s: 9.4.4.Final (was: 9.4.3.Final) > Docs: Merge Details on Protocol Interoperability > ------------------------------------------------ > > Key: ISPN-9646 > URL: https://issues.jboss.org/browse/ISPN-9646 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation-Core, Marshalling, Remote Protocols > Affects Versions: 9.4.0.Final > Reporter: Don Naro > Assignee: Don Naro > Priority: Major > Fix For: 10.0.0.Alpha2, 9.4.4.Final > > > The purpose of this task is to merge doc changes for protocol interoperability and compatibility mode into upstream docs from JDG. These changes should go into RHDG 7.3. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9764) Server should utilise the Persistence element

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9764?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9764: ---------------------------------- Fix Version/s: 9.4.4.Final (was: 9.4.3.Final) > Server should utilise the Persistence element > --------------------------------------------- > > Key: ISPN-9764 > URL: https://issues.jboss.org/browse/ISPN-9764 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 9.4.2.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.0.0.Alpha2, 9.4.4.Final > > > Currently the <persistence> element is not required to configure stores in the server. We need to add this, so that we can configure PersistenceManager characteristics such as store-availability etc. Furthermore, with the current config it's possible for two store configs to cancel out each other's passivation behaviour if one has passivation=true and passivation=false. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9778) XidImpl implementations can optimize some byte[] allocations

by William Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-9778?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-9778: -------------------------------- Description: The EmbeddedXid and XidImpl classes show up on profiler for allocating byte[] in a local environment. 1. We should be able to remove the branch byte[] completely as well as its accompanying AtomicInteger and just return an empty byte[] that is cached (ie. Util.EMPTY_BYTE_ARRAY). 2. We can use the byte[] that is provided from the create method directly in XidImpl, which would reduce our allocation to just the 1 byte\[24\] for embedded or byte\[32\] for remote. -3. We can return the byte[] directly for getGlobalTransactionId without copying.- was: The EmbeddedXid and XidImpl classes show up on profiler for allocating byte[] in a local environment. 1. We should be able to remove the branch byte[] completely as well as its accompanying AtomicInteger and just return an empty byte[] that is cached (ie. Util.EMPTY_BYTE_ARRAY). 2. We can use the byte[] that is provided from the create method directly in XidImpl, which would reduce our allocation to just the 1 byte[24] for embedded or byte[32] for remote. 3. We can return the byte[] directly for getGlobalTransactionId without copying. > XidImpl implementations can optimize some byte[] allocations > ------------------------------------------------------------ > > Key: ISPN-9778 > URL: https://issues.jboss.org/browse/ISPN-9778 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Reporter: William Burns > Priority: Major > Fix For: 10.0.0.Alpha2 > > > The EmbeddedXid and XidImpl classes show up on profiler for allocating byte[] in a local environment. > 1. We should be able to remove the branch byte[] completely as well as its accompanying AtomicInteger and just return an empty byte[] that is cached (ie. Util.EMPTY_BYTE_ARRAY). > 2. We can use the byte[] that is provided from the create method directly in XidImpl, which would reduce our allocation to just the 1 byte\[24\] for embedded or byte\[32\] for remote. > -3. We can return the byte[] directly for getGlobalTransactionId without copying.- -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 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 November 2018