June 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPRK-54) Update to Apache Spark 2.3.1

by Gustavo Fernandes (JIRA)

Gustavo Fernandes created ISPRK-54: -------------------------------------- Summary: Update to Apache Spark 2.3.1 Key: ISPRK-54 URL: https://issues.jboss.org/browse/ISPRK-54 Project: Infinispan Spark Issue Type: Component Upgrade Affects Versions: 0.7 Reporter: Gustavo Fernandes Fix For: 0.8 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPRK-55) Update to Infinispan 9.3.0.Final

by Gustavo Fernandes (JIRA)

Gustavo Fernandes created ISPRK-55: -------------------------------------- Summary: Update to Infinispan 9.3.0.Final Key: ISPRK-55 URL: https://issues.jboss.org/browse/ISPRK-55 Project: Infinispan Spark Issue Type: Component Upgrade Reporter: Gustavo Fernandes Fix For: 0.8 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9214) JBossStandaloneJTAManagerLookup is using deprecated integration names

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-9214?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-9214: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.3.0.Final Resolution: Done > JBossStandaloneJTAManagerLookup is using deprecated integration names > --------------------------------------------------------------------- > > Key: ISPN-9214 > URL: https://issues.jboss.org/browse/ISPN-9214 > Project: Infinispan > Issue Type: Task > Components: Core, Integration > Reporter: Sanne Grinovero > Assignee: Scott Marlow > Priority: Minor > Fix For: 9.3.0.Final > > > Scott changed the Hibernate ORM {{JBossStandaloneJTAManagerLookup}}, as on WildFly 13+, JTA client code that directly references the {{com.arjuna.ats.jta.TransactionManager}}, needs to instead use the WildFly Transaction Client, or it may see incorrect TX status. > I assume the Infinispan standalone client will need to be updated as well. > See: > - https://hibernate.atlassian.net/browse/HHH-12640 > - https://hibernate.atlassian.net/browse/HHH-12620 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9180) Remove compat mode from Remote Query

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-9180?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes reassigned ISPN-9180: --------------------------------------- Assignee: Gustavo Fernandes > Remove compat mode from Remote Query > ------------------------------------ > > Key: ISPN-9180 > URL: https://issues.jboss.org/browse/ISPN-9180 > Project: Infinispan > Issue Type: Sub-task > Components: Remote Querying > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > > The ProtobufMetadataManager is configured internally using compat mode plus the CompatibilityProtostreamMarshaller as a marshaller. This requires that HR clients use the protostream marshaller to register .proto files, since otheriwse the server cannot unmarshall it. > The ProtobufMetadataManager cache should rely instead on the MediaType sent by the HR client and convert the incoming content to java object (String) on the fly, as long as the server supports conversion between the content produced by marshaller and java object. > Apart from that, there are multiple places in the code that registers/instantiates/configures objects based on the compat mode marshaller, and assume all content will be unmarshalled by this marshaller. It should instead rely on the MediaType information sent by the HR client and do the conversion on the fly, this would allow indexing and querying in multiple formats as long as the storage format is supported and the conversion between the input/storage is supported by the server. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7940) Deprecate Compatibility Mode

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-7940?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-7940: ------------------------------------ Description: Compatibility Mode should be marked for removal and internally all the remaining usages should be removed (was: Compatibility Mode should be marked for removal and internally all the remaining usages should be routed to the related encoder) > Deprecate Compatibility Mode > ---------------------------- > > Key: ISPN-7940 > URL: https://issues.jboss.org/browse/ISPN-7940 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying, Remote Querying > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 9.4.0.Final > > > Compatibility Mode should be marked for removal and internally all the remaining usages should be removed -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9286) WriteBehindFaultToleranceTest Failures

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-9286?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-9286: ------------------------------------ New failure: https://ci.infinispan.org/job/Infinispan/job/PR-6066/13/testReport/junit/... {noformat} java.lang.AssertionError: expected:<10> but was:<1> at org.infinispan.persistence.WriteBehindFaultToleranceTest.testBlockingOnStoreAvailabilityChange(WriteBehindFaultToleranceTest.java:88) {noformat} > WriteBehindFaultToleranceTest Failures > -------------------------------------- > > Key: ISPN-9286 > URL: https://issues.jboss.org/browse/ISPN-9286 > Project: Infinispan > Issue Type: Bug > Components: Core, Loaders and Stores > Affects Versions: 9.3.0.CR1 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Fix For: 9.3.0.Final > > > #testBlockingOnStoreAvailabilityChange failure due to the async write not completing before store.size is called. > {code:java} > java.lang.AssertionError: expected:<1> but was:<0> > at org.infinispan.persistence.WriteBehindFaultToleranceTest.testBlockingOnStoreAvailabilityChange(WriteBehindFaultToleranceTest.java:55) > at org.infinispan.commons.test.TestNGLongTestsHook.run(TestNGLongTestsHook.java:24) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > 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) > ... Removed 23 stack frames > {code} > #testWritesFailSilentlyWhenConfigured failure due to the async write not being executed on the store before the entry is loaded from the store. > {code:java} > java.lang.NullPointerException > at org.infinispan.persistence.WriteBehindFaultToleranceTest.testWritesFailSilentlyWhenConfigured(WriteBehindFaultToleranceTest.java:110) > at org.infinispan.commons.test.TestNGLongTestsHook.run(TestNGLongTestsHook.java:24) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > 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) > ... Removed 18 stack frames > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9142) PreferConsistencyStrategy does not initiate CR when previously independent nodes merge

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-9142?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-9142: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > PreferConsistencyStrategy does not initiate CR when previously independent nodes merge > -------------------------------------------------------------------------------------- > > Key: ISPN-9142 > URL: https://issues.jboss.org/browse/ISPN-9142 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.3.0.Alpha1 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Fix For: 9.3.0.Final > > > Two nodes start operating independently and don't know about each other due to a network issue. Both nodes put one record with same key but different value. When the network recovers, CR is not initiated. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8852) StackOverflowError when requesting data in case cache is in degraded mode

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-8852?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-8852: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > StackOverflowError when requesting data in case cache is in degraded mode > ------------------------------------------------------------------------- > > Key: ISPN-8852 > URL: https://issues.jboss.org/browse/ISPN-8852 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.1.4.Final > Reporter: Michal Stehlik > Assignee: Ryan Emerson > Fix For: 9.3.0.Final > > Attachments: stackowerflow.log > > > Found StackOverflowError in logs when network was disconnected, caches are in degraded mode and system attempt to operate with cache Read & Update. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8976) 2 subclusters failed to merge to 1 cluster - IllegalLifecycleStateException

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-8976?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-8976: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > 2 subclusters failed to merge to 1 cluster - IllegalLifecycleStateException > --------------------------------------------------------------------------- > > Key: ISPN-8976 > URL: https://issues.jboss.org/browse/ISPN-8976 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.1.4.Final > Reporter: Robert Cernak > Assignee: Ryan Emerson > Fix For: 9.3.0.Final > > Attachments: logs.zip > > > At the beginning I have main cluster consisted of 8 nodes. > Then I disconnected main switch on which these nodes were connected. > This leaded to separating main cluster to 2 subclusters - first with 2 nodes and second with 6 nodes. This was expected. > After that I rebooted the nodes. After reboot, nodes again correctly formed 2 subclusters with 2 and 6 members. > After a long time when all nodes were stable with low cpu load, I connected the main switch back which should lead to recreation of main cluster with 8 controllers. > However main cluster did not recovered: > subcluster2 did not change - still had 6 nodes connected - no new members > subcluster1 - nodes did not connect with subcluster2 and after cca 30min they left the cluster. > When I checked infinispan logs of node1 from 1st subcluster I had IllegalLifecycleStateException for every created cache (see included logs.zip): > [transport-thread-744a974a-2811-4f79-ac63-f32daf005d7f-p4-t6] (ClusterCacheStatus.java:599) - ISPN000228: Failed to recover cache XXX state after the current node became the coordinator > org.infinispan.IllegalLifecycleStateException: Cache container has been stopped and cannot be reused. Recreate the cache container. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9247) Upgrade to Wildfly 13

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-9247?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-9247: ------------------------------- Sprint: Sprint 9.3.0.Final > Upgrade to Wildfly 13 > --------------------- > > Key: ISPN-9247 > URL: https://issues.jboss.org/browse/ISPN-9247 > Project: Infinispan > Issue Type: Component Upgrade > Components: Server > Affects Versions: 9.3.0.Beta1 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Fix For: 9.3.0.Final > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 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 June 2018