March 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPRK-2) Management of cache lifecycles

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPRK-2?page=com.atlassian.jira.plugin.sy... ] Work on ISPRK-2 stopped by Gustavo Fernandes. --------------------------------------------- > Management of cache lifecycles > ------------------------------ > > Key: ISPRK-2 > URL: https://issues.jboss.org/browse/ISPRK-2 > Project: Infinispan Spark > Issue Type: Feature Request > Reporter: RJ Nowling > Assignee: Gustavo Fernandes > Fix For: 0.7 > > > For analytics use cases, the caches will rarely be known ahead of time -- they are dependent on the particular jobs being run. As such, jobs should have the ability to manage the lifecycle of caches, in particular: > * Checking if a cache exists > * Creating a cache > * Deleting a cache > * Clearing a cache -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPRK-2) Management of cache lifecycles

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPRK-2?page=com.atlassian.jira.plugin.sy... ] Work on ISPRK-2 started by Gustavo Fernandes. --------------------------------------------- > Management of cache lifecycles > ------------------------------ > > Key: ISPRK-2 > URL: https://issues.jboss.org/browse/ISPRK-2 > Project: Infinispan Spark > Issue Type: Feature Request > Reporter: RJ Nowling > Assignee: Gustavo Fernandes > Fix For: 0.7 > > > For analytics use cases, the caches will rarely be known ahead of time -- they are dependent on the particular jobs being run. As such, jobs should have the ability to manage the lifecycle of caches, in particular: > * Checking if a cache exists > * Creating a cache > * Deleting a cache > * Clearing a cache -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8881) Upgrade JGroups kubernetes to 1.0.6.Final

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-8881?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-8881: ------------------------------------ Fix Version/s: 9.2.1.Final (was: 9.3.0.Final) > Upgrade JGroups kubernetes to 1.0.6.Final > ----------------------------------------- > > Key: ISPN-8881 > URL: https://issues.jboss.org/browse/ISPN-8881 > Project: Infinispan > Issue Type: Component Upgrade > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.2.1.Final > > > This removes the oauth dependency -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8881) Upgrade JGroups kubernetes to 1.0.6.Final

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-8881?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-8881: ------------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Upgrade JGroups kubernetes to 1.0.6.Final > ----------------------------------------- > > Key: ISPN-8881 > URL: https://issues.jboss.org/browse/ISPN-8881 > Project: Infinispan > Issue Type: Component Upgrade > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.3.0.Final > > > This removes the oauth dependency -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8910) CompatModeClusteredCacheTest.testMerge test failure

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-8910?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-8910: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.2.1.Final Resolution: Done Integrated in master. Thanks [~gustavonalle]! > CompatModeClusteredCacheTest.testMerge test failure > --------------------------------------------------- > > Key: ISPN-8910 > URL: https://issues.jboss.org/browse/ISPN-8910 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Query > Affects Versions: 9.2.0.Final > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 9.2.1.Final > > > {noformat} > Caused by: org.infinispan.util.UserRaisedFunctionalException: java.lang.ClassCastException: [B cannot be cast to org.infinispan.query.test.Person > at org.infinispan.commands.functional.functions.MergeFunction.apply(MergeFunction.java:44) > at org.infinispan.commands.functional.functions.MergeFunction.apply(MergeFunction.java:19) > at org.infinispan.commands.functional.ReadWriteKeyCommand.perform(ReadWriteKeyCommand.java:100) > at org.infinispan.interceptors.impl.CallInterceptor.visitCommand(CallInterceptor.java:29) > at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:56) > at org.infinispan.interceptors.distribution.BaseDistributionInterceptor.handleNonTxWriteCommand(BaseDistributionInterceptor.java:260) > at org.infinispan.interceptors.distribution.NonTxDistributionInterceptor.visitReadWriteKeyCommand(NonTxDistributionInterceptor.java:137) > at org.infinispan.commands.functional.ReadWriteKeyCommand.acceptVisitor(ReadWriteKeyCommand.java:110) > at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenAccept(BaseAsyncInterceptor.java:98) > at org.infinispan.query.backend.QueryInterceptor.handleDataWriteCommand(QueryInterceptor.java:177) > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8896) HTTP/2 support is broken

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-8896?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-8896: ------------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.2.1.Final Resolution: Done > HTTP/2 support is broken > ------------------------ > > Key: ISPN-8896 > URL: https://issues.jboss.org/browse/ISPN-8896 > Project: Infinispan > Issue Type: Bug > Components: REST > Affects Versions: 9.2.0.Final > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > Fix For: 9.2.1.Final > > > CURL reports that HTTP Settings frame is broken: > On Terminal 1: > {code} > docker run -e "APP_USER=test" -e "APP_PASS=test" jboss/infinispan-server:9.2.0.Final ../../docs/examples/configs/standalone-rest-ssl.xml > {code} > On Terminal 2: > {code} > curl "Accept: text/plain" -k -v --http2 -u test:test https://172.17.0.2:8443/rest/default/test > * Illegal port number > * Closing connection -1 > curl: (3) Illegal port number > * Trying 172.17.0.2... > * TCP_NODELAY set > * Connected to 172.17.0.2 (172.17.0.2) port 8443 (#0) > * Initializing NSS with certpath: sql:/etc/pki/nssdb > * skipping SSL peer certificate verification > * ALPN, server accepted to use h2 > * SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > * Server certificate: > * subject: CN=localhost > * start date: Mar 01 12:02:32 2018 GMT > * expire date: Feb 27 12:02:32 2028 GMT > * common name: localhost > * issuer: CN=localhost > * Using HTTP2, server supports multi-use > * Connection state changed (HTTP/2 confirmed) > * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 > * Server auth using Basic with user 'test' > * Using Stream ID: 1 (easy handle 0x55972b0700d0) > > GET /rest/default/test HTTP/2 > > Host: 172.17.0.2:8443 > > Authorization: Basic dGVzdDp0ZXN0 > > User-Agent: curl/7.53.1 > > Accept: */* > > > * http2 error: Remote peer returned unexpected data while we expected SETTINGS frame. Perhaps, peer does not support HTTP/2 properly. > * Closing connection 0 > curl: (16) Illegal port number > {code} > The same with 9.1.5.Final: > {code} > curl -d test -H "Accept: text/plain" -k -v --http2 -u test:test https://172.17.0.2:8443/rest/default/test > * Trying 172.17.0.2... > * TCP_NODELAY set > * Connected to 172.17.0.2 (172.17.0.2) port 8443 (#0) > * Initializing NSS with certpath: sql:/etc/pki/nssdb > * skipping SSL peer certificate verification > * ALPN, server accepted to use h2 > * SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > * Server certificate: > * subject: CN=localhost > * start date: Mar 01 12:04:47 2018 GMT > * expire date: Feb 27 12:04:47 2028 GMT > * common name: localhost > * issuer: CN=localhost > * Using HTTP2, server supports multi-use > * Connection state changed (HTTP/2 confirmed) > * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 > * Server auth using Basic with user 'test' > * Using Stream ID: 1 (easy handle 0x555cd62630d0) > > POST /rest/default/test HTTP/2 > > Host: 172.17.0.2:8443 > > Authorization: Basic dGVzdDp0ZXN0 > > User-Agent: curl/7.53.1 > > Accept: text/plain > > Content-Length: 4 > > Content-Type: application/x-www-form-urlencoded > > > * We are completely uploaded and fine > * Connection state changed (MAX_CONCURRENT_STREAMS updated)! > < HTTP/2 200 > < etag: application/x-www-form-urlencoded-235262424 > < content-type: text/plain > < content-length: 0 > < > * Connection #0 to host 172.17.0.2 left intact > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8923) PersistenceManagerCloseableSupplier can timeout if store produces entries too fast

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8923?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8923: -------------------------------- Status: Open (was: New) > PersistenceManagerCloseableSupplier can timeout if store produces entries too fast > ---------------------------------------------------------------------------------- > > Key: ISPN-8923 > URL: https://issues.jboss.org/browse/ISPN-8923 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 9.2.0.Final > Reporter: William Burns > Fix For: 9.3.0.Final, 9.2.1.Final, 9.1.7.Final > > > PersistenceManagerCloseableSupplier get method polls the queue then locks the lock. It doesn't recheck the queue inside the lock. Thus if a loader fills up the entire queue before the get method can acquire the lock, this will cause the get method to timeout. Instead we should change the check inside the lock to always poll the queue. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8923) PersistenceManagerCloseableSupplier can timeout if store produces entries too fast

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8923?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8923: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5824 > PersistenceManagerCloseableSupplier can timeout if store produces entries too fast > ---------------------------------------------------------------------------------- > > Key: ISPN-8923 > URL: https://issues.jboss.org/browse/ISPN-8923 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 9.2.0.Final > Reporter: William Burns > Fix For: 9.3.0.Final, 9.2.1.Final, 9.1.7.Final > > > PersistenceManagerCloseableSupplier get method polls the queue then locks the lock. It doesn't recheck the queue inside the lock. Thus if a loader fills up the entire queue before the get method can acquire the lock, this will cause the get method to timeout. Instead we should change the check inside the lock to always poll the queue. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8924) SingleFileStore can run process method substantially faster when it doesn't require values or metadata

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8924?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8924: -------------------------------- Status: Open (was: New) > SingleFileStore can run process method substantially faster when it doesn't require values or metadata > ------------------------------------------------------------------------------------------------------ > > Key: ISPN-8924 > URL: https://issues.jboss.org/browse/ISPN-8924 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: William Burns > Assignee: William Burns > Fix For: 9.2.1.Final, 9.3.0.Alpha1 > > > The SingleFileStore always reads from the file. However if value and metadata are both not needed, there is no reason to go to the file. Instead we can just check the expiration on the file entry and return the keys immediately. > This along with ISPN-8923 will provide a SUBSTANTIAL boost for keySet iteration methods when using SingleFileStore. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8924) SingleFileStore can run process method substantially faster when it doesn't require values or metadata

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8924?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8924: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5824 > SingleFileStore can run process method substantially faster when it doesn't require values or metadata > ------------------------------------------------------------------------------------------------------ > > Key: ISPN-8924 > URL: https://issues.jboss.org/browse/ISPN-8924 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: William Burns > Assignee: William Burns > Fix For: 9.2.1.Final, 9.3.0.Alpha1 > > > The SingleFileStore always reads from the file. However if value and metadata are both not needed, there is no reason to go to the file. Instead we can just check the expiration on the file entry and return the keys immediately. > This along with ISPN-8923 will provide a SUBSTANTIAL boost for keySet iteration methods when using SingleFileStore. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2018