June 2018 - infinispan-issues - Jboss List Archives

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

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-7035?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec reassigned ISPN-7035: ----------------------------------------- Assignee: Katia Aresti (was: Sebastian Łaskawiec) > 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)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7268) Refactor Healthcheck API to use new REST management interface

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-7268?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec reassigned ISPN-7268: ----------------------------------------- Assignee: Tristan Tarrant (was: Sebastian Łaskawiec) > Refactor Healthcheck API to use new REST management interface > ------------------------------------------------------------- > > Key: ISPN-7268 > URL: https://issues.jboss.org/browse/ISPN-7268 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Reporter: Sebastian Łaskawiec > Assignee: Tristan Tarrant > Priority: Critical > > Refactor Healthcheck API to look similar to this: https://github.com/wildfly/wildfly-core/pull/1990/files > Additionally use new Management API: https://issues.jboss.org/browse/WFCORE-1742 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7515) RestStore initialized connection pool only on startup

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-7515?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec reassigned ISPN-7515: ----------------------------------------- Assignee: Ryan Emerson (was: Sebastian Łaskawiec) > RestStore initialized connection pool only on startup > ----------------------------------------------------- > > Key: ISPN-7515 > URL: https://issues.jboss.org/browse/ISPN-7515 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 9.0.0.CR1 > Reporter: Sebastian Łaskawiec > Assignee: Ryan Emerson > Priority: Critical > > RestStore seems to initialize the connection pool only on startup. After that fails (e.g. OpenShift services are not ready) it stays with empty pool. This results in empty responses in "new" cluster during Rolling Upgrade procedure. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7694) Provide JDK SSLContext/Netty OpenSSLContext bridge and allow using OpenSSL

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-7694?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec reassigned ISPN-7694: ----------------------------------------- Assignee: Tristan Tarrant (was: Sebastian Łaskawiec) > Provide JDK SSLContext/Netty OpenSSLContext bridge and allow using OpenSSL > -------------------------------------------------------------------------- > > Key: ISPN-7694 > URL: https://issues.jboss.org/browse/ISPN-7694 > Project: Infinispan > Issue Type: Feature Request > Reporter: Sebastian Łaskawiec > Assignee: Tristan Tarrant > Priority: Critical > > In order to use OpenSSL with Netty (which is much faster than JDK implementation), and stick with WildFly SSL initialization, we need to provide a bridge from JDK SSLContext into OpenSSLContext. > The next step is to use this bridge here: https://github.com/infinispan/infinispan/blob/fd3061a684c13aa7c22d215f439... > Finally, we need to put {{netty-tcnative}} into the server's classpath. > More information: http://netty.io/wiki/requirements-for-4.x.html#tls-with-openssl -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 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 rely in the transcoding mechanism (was: Compatibility Mode should be marked for removal and internally all the remaining usages should be removed) > 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 rely in the transcoding mechanism -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 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.... ] Work on ISPN-9180 started by 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 otherwise 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)

6 years, 6 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 updated ISPN-9180: ------------------------------------ Description: 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 otherwise 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. was: 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. > 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 otherwise 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)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9299) Server trim-modules.txt is not applied to the "fat" server distribution

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-9299?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-9299: ------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/6084, https://github.com/infinispan/infinispan/pull/6092 (was: https://github.com/infinispan/infinispan/pull/6084) > Server trim-modules.txt is not applied to the "fat" server distribution > ----------------------------------------------------------------------- > > Key: ISPN-9299 > URL: https://issues.jboss.org/browse/ISPN-9299 > Project: Infinispan > Issue Type: Bug > Components: Build, Server > Affects Versions: 9.3.0.CR1 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Fix For: 9.3.0.Final > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8533) Deadlock in pessimistic transaction

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-8533?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-8533: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Deadlock in pessimistic transaction > ----------------------------------- > > Key: ISPN-8533 > URL: https://issues.jboss.org/browse/ISPN-8533 > Project: Infinispan > Issue Type: Bug > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 9.3.0.Final > > > Deadlock can happen (not sure how) during a topology change and pessimistic transaction. > 2 transaction can end up in the pending lock manager and they will wait for each other to finish. > {noformat} > Caused by: org.infinispan.util.concurrent.TimeoutException: Could not acquire lock on xxxx in behalf of transaction GlobalTx:node-a:3746. Current owner GlobalTx:node-b:3629. > at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.timeout(DefaultPendingLockManager.java:262) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final] > at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.awaitOn(DefaultPendingLockManager.java:345) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final] > at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.awaitPendingTransactionsForAllKeys(DefaultPendingLockManager.java:147) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final] > at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockAllKeys(AbstractTxLockingInterceptor.java:166) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final] > at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAllOrRegisterBackupLock(AbstractTxLockingInterceptor.java:134) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final] > at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.localLockCommandWork(PessimisticLockingInterceptor.java:234) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final] > at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.lambda$new$0(PessimisticLockingInterceptor.java:41) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final] > {noformat} > {noformat} > Caused by: org.infinispan.util.concurrent.TimeoutException: Could not acquire lock on xxxx in behalf of transaction GlobalTx:node-b:3629. Current > owner GlobalTx:node-a:3746. > at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.timeout(DefaultPendingLockManager.java:262) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final] > at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.awaitOn(DefaultPendingLockManager.java:345) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final] > at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.awaitPendingTransactionsForAllKeys(DefaultPendingLockManager.java:147) ~[infinispan-embedded-9.1.2.Final. > jar:9.1.2.Final] > at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockAllKeys(AbstractTxLockingInterceptor.java:166) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final] > at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAllOrRegisterBackupLock(AbstractTxLockingInterceptor.java:134) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final] > at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.localLockCommandWork(PessimisticLockingInterceptor.java:234) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final] > at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.lambda$new$0(PessimisticLockingInterceptor.java:41) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final] > {noformat} > notes: confirm the pending lock manager is cleanup! -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9286) WriteBehindFaultToleranceTest Failures

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-9286?page=com.atlassian.jira.plugin.... ] Ryan Emerson resolved ISPN-9286. -------------------------------- Resolution: Done > 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)

6 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2018