January 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-8726) Implement the binary memcached protocol

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-8726: ------------------------------------- Summary: Implement the binary memcached protocol Key: ISPN-8726 URL: https://issues.jboss.org/browse/ISPN-8726 Project: Infinispan Issue Type: Enhancement Components: Memcached, Server Reporter: Tristan Tarrant In order to symmetrically provide security features to all the endpoints, the memcached endpoint needs to support the binary protocol as that is the only one that allows TLS encryption and SASL authn. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8725) Document REST server changes

by Gustavo Fernandes (JIRA)

Gustavo Fernandes created ISPN-8725: --------------------------------------- Summary: Document REST server changes Key: ISPN-8725 URL: https://issues.jboss.org/browse/ISPN-8725 Project: Infinispan Issue Type: Task Components: Documentation-Servers Reporter: Gustavo Fernandes Including: * MediaType config * MediaType negotiation * Standard formats supported: text, octet-stream, form-encoded, object * Transcoders: JSON, XML, Protostream * Query over REST * Different key types with extra headers -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8725) Document REST server changes

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-8725?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-8725: ------------------------------------ Fix Version/s: 9.2.0.Final > Document REST server changes > ---------------------------- > > Key: ISPN-8725 > URL: https://issues.jboss.org/browse/ISPN-8725 > Project: Infinispan > Issue Type: Task > Components: Documentation-Servers > Reporter: Gustavo Fernandes > Fix For: 9.2.0.Final > > > Including: > * MediaType config > * MediaType negotiation > * Standard formats supported: text, octet-stream, form-encoded, object > * Transcoders: JSON, XML, Protostream > * Query over REST > * Different key types with extra headers -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3421) Transaction is sometimes not applied on all owners if originator dies during commit

by Alon Greenland (JIRA)

[ https://issues.jboss.org/browse/ISPN-3421?page=com.atlassian.jira.plugin.... ] Alon Greenland commented on ISPN-3421: -------------------------------------- Is this bug still present in the current version (9.1) or is fixed in 6.0.0 as indicated by: "Fix Version/s 6.0.0.Final" but somehow forgotten to be closed? > Transaction is sometimes not applied on all owners if originator dies during commit > ----------------------------------------------------------------------------------- > > Key: ISPN-3421 > URL: https://issues.jboss.org/browse/ISPN-3421 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Affects Versions: 5.2.7.Final > Reporter: Erik Salter > Assignee: Dan Berindei > Priority: Critical > > There's a hole in state transfer mechanism that can occur when a node is leaving the cluster, but it was creating the entries and was only able to replicate the data to some of the nodes. > The problem occurs when the segment ownership of the node doesn't change after the rebalance. Since state transfer does not request state for keys in which it is already an owner, the cache could be left in a state where a key is resident < numOwners nodes. In addition, this could be any subset of the primary OR backup nodes. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8708) Remote iteration with limited batch sends finished segments too early

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8708?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-8708: ------------------------------------- Instead this needs to be changed to have [1] instead have a KeyWatchingCompletionListener for each publisher and complete the segments when the iterator finds a given key. This way we don't have to store all keys and remove them as they are iterated upon. [1] https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o... > Remote iteration with limited batch sends finished segments too early > --------------------------------------------------------------------- > > Key: ISPN-8708 > URL: https://issues.jboss.org/browse/ISPN-8708 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 9.2.0.Beta2 > Reporter: Radim Vansa > Assignee: William Burns > Fix For: 9.2.0.Final > > Attachments: infinispan-infinispan-client-hotrod.log.zip > > > When a remote cache is iterated and we limit maximum number of entries in one response, we might get the list of finished segments before the entry is actually sent to the client. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8708) Remote iteration with limited batch sends finished segments too early

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8708?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-8708: ------------------------------------- This is caused by the fact that we no longer pull entries from a single queue any longer. Instead they are pulled via priority [1] and when multiple returns come in this means that segments may get completed early no accident. [1] https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o... > Remote iteration with limited batch sends finished segments too early > --------------------------------------------------------------------- > > Key: ISPN-8708 > URL: https://issues.jboss.org/browse/ISPN-8708 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 9.2.0.Beta2 > Reporter: Radim Vansa > Assignee: William Burns > Fix For: 9.2.0.Final > > Attachments: infinispan-infinispan-client-hotrod.log.zip > > > When a remote cache is iterated and we limit maximum number of entries in one response, we might get the list of finished segments before the entry is actually sent to the client. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8102) Add HOSA to the Infinispan templates

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-8102?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic commented on ISPN-8102: ------------------------------------------- [~sebastian.laskawiec] this is great! For the uninitiated and some background see http://www.hawkular.org/blog/2017/01/17/obst-hosa.html We could add all the metrics related to cache performance (everything that is on cache page in admin console i.e. hit ratios, read/write performance, activations, evictions and so on) > Add HOSA to the Infinispan templates > ------------------------------------ > > Key: ISPN-8102 > URL: https://issues.jboss.org/browse/ISPN-8102 > Project: Infinispan > Issue Type: Enhancement > Components: Cloud > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > Priority: Minor > > aka Hawkular OpenShift Agent -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7765) Allow HotRodDecoder to be shared between Netty pipelines

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-7765?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-7765: ----------------------------------- I think that we could make the server more effective if we tightly bind the decoder to channel/currently processed request. That way we don't have to re-allocate some data structures (e.g. CacheDecodeContext) for each request. The number of open channels should be small (limited) compared to number of requests executed on these. > Allow HotRodDecoder to be shared between Netty pipelines > -------------------------------------------------------- > > Key: ISPN-7765 > URL: https://issues.jboss.org/browse/ISPN-7765 > Project: Infinispan > Issue Type: Enhancement > Reporter: Sebastian Łaskawiec > Assignee: William Burns > > Currently {{HotRodDecoder}} instance can not be shared between Netty pipelines as {{HotRodEncoder}}. Currently each pipeline creates its own instance by calling: > {code} > server.getDecoder() > {code} > in {{NettyChannelInitializer#initializeChannel}}. We could probably make it a bit more efficient (or limit allocation rate at least) if we allow sharing single instance between pipelines. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8721) Clustered 2nd level cache sometimes throws NullPointerException when new node starts up

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-8721?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-8721: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5698 > Clustered 2nd level cache sometimes throws NullPointerException when new node starts up > --------------------------------------------------------------------------------------- > > Key: ISPN-8721 > URL: https://issues.jboss.org/browse/ISPN-8721 > Project: Infinispan > Issue Type: Bug > Components: Hibernate Cache > Affects Versions: 9.1.4.Final > Environment: jvm 1.8 > Reporter: Tom Dearman > Assignee: Tom Dearman > Fix For: 9.2.0.Final, 9.2.0.CR2 > > Attachments: sample-app.cache.tar.gz > > > There is a race condition in PutFromLoadValidator as it registers itself in the component registry before it is fully initialised. You can reproduce this by running the contained app against h2 server db. First start this app with default port. Then start the app on port '8080' and make a few requests to '/add' to create data. After that send continuous requests to '/update' in order change data and trigger the cache: > for i in > {code} > {1..1000} > ; do sleep 0.01; curl http://localhost:8080/update -X POST; done > {code} > Then start another instance of the app on port 8090: > {code} > java -jar test-app-0.0.1-SNAPSHOT.jar --server.port=8090 > {code} > Most of the time one of the updates will fail and the logs will show the following: > {code} > 2018-01-23 15:36:46 [main] DEBUG o.h.c.i.access.PutFromLoadValidator - Interceptor chain was: [org.infinispan.interceptors.InvocationContextInterceptor@407a7f2a, org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor@4ea5b703, org.infinispan.interceptors.EntryWrappingInterceptor@2a7ed1f, org.infinispan.interceptors.InvalidationInterceptor@3fa247d1, org.infinispan.interceptors.CallInterceptor@2cb2fc20] > 2018-01-23 15:36:46 [main] DEBUG o.h.c.i.access.PutFromLoadValidator - New interceptor chain is: [org.infinispan.interceptors.InvocationContextInterceptor@407a7f2a, org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor@4ea5b703, org.hibernate.cache.infinispan.access.NonTxPutFromLoadInterceptor@495ee280, org.infinispan.interceptors.EntryWrappingInterceptor@2a7ed1f, org.hibernate.cache.infinispan.access.NonTxInvalidationInterceptor@4fa1c212, org.infinispan.interceptors.CallInterceptor@2cb2fc20] > 2018-01-23 15:36:46 [main] TRACE o.i.manager.DefaultCacheManager - About to wire and start cache test.app.data.User-pending-puts > 2018-01-23 15:36:46 [remote-thread--p2-t1] ERROR o.i.i.InvocationContextInterceptor - ISPN000136: Error executing command BeginInvalidationCommand, writing keys test.app.data.User#2 > java.lang.NullPointerException: null > at org.hibernate.cache.infinispan.access.PutFromLoadValidator.beginInvalidatingWithPFER(PutFromLoadValidator.java:561) > at org.hibernate.cache.infinispan.access.PutFromLoadValidator.beginInvalidatingKey(PutFromLoadValidator.java:555) > at org.hibernate.cache.infinispan.access.NonTxPutFromLoadInterceptor.visitInvalidateCommand(NonTxPutFromLoadInterceptor.java:70) > at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:114) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99) > at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitInvalidateCommand(AbstractLockingInterceptor.java:112) > at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:114) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99) > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110) > at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:79) > at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:127) > at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:114) > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:335) > at org.infinispan.commands.remote.BaseRpcInvokingCommand.processVisitableCommand(BaseRpcInvokingCommand.java:43) > at org.infinispan.commands.remote.SingleRpcCommand.perform(SingleRpcCommand.java:51) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokePerform(BasePerCacheInboundInvocationHandler.java:92) > at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:34) > 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) > 2018-01-23 15:36:47 [main] TRACE o.i.manager.DefaultCacheManager - Closing latch for cache test.app.data.User-pending-puts > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8721) Clustered 2nd level cache sometimes throws NullPointerException when new node starts up

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-8721?page=com.atlassian.jira.plugin.... ] Galder Zamarreño reassigned ISPN-8721: -------------------------------------- Assignee: Tom Dearman > Clustered 2nd level cache sometimes throws NullPointerException when new node starts up > --------------------------------------------------------------------------------------- > > Key: ISPN-8721 > URL: https://issues.jboss.org/browse/ISPN-8721 > Project: Infinispan > Issue Type: Bug > Components: Hibernate Cache > Affects Versions: 9.1.4.Final > Environment: jvm 1.8 > Reporter: Tom Dearman > Assignee: Tom Dearman > Fix For: 9.2.0.Final, 9.2.0.CR2 > > Attachments: sample-app.cache.tar.gz > > > There is a race condition in PutFromLoadValidator as it registers itself in the component registry before it is fully initialised. You can reproduce this by running the contained app against h2 server db. First start this app with default port. Then start the app on port '8080' and make a few requests to '/add' to create data. After that send continuous requests to '/update' in order change data and trigger the cache: > for i in > {1..1000} > ; do sleep 0.01; curl http://localhost:8080/update -X POST; done > Then start another instance of the app on port 8090: > java -jar test-app-0.0.1-SNAPSHOT.jar --server.port=8090 > Most of the time one of the updates will fail and the logs will show the following: > 2018-01-23 15:36:46 [main] DEBUG o.h.c.i.access.PutFromLoadValidator - Interceptor chain was: [org.infinispan.interceptors.InvocationContextInterceptor@407a7f2a, org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor@4ea5b703, org.infinispan.interceptors.EntryWrappingInterceptor@2a7ed1f, org.infinispan.interceptors.InvalidationInterceptor@3fa247d1, org.infinispan.interceptors.CallInterceptor@2cb2fc20] > 2018-01-23 15:36:46 [main] DEBUG o.h.c.i.access.PutFromLoadValidator - New interceptor chain is: [org.infinispan.interceptors.InvocationContextInterceptor@407a7f2a, org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor@4ea5b703, org.hibernate.cache.infinispan.access.NonTxPutFromLoadInterceptor@495ee280, org.infinispan.interceptors.EntryWrappingInterceptor@2a7ed1f, org.hibernate.cache.infinispan.access.NonTxInvalidationInterceptor@4fa1c212, org.infinispan.interceptors.CallInterceptor@2cb2fc20] > 2018-01-23 15:36:46 [main] TRACE o.i.manager.DefaultCacheManager - About to wire and start cache test.app.data.User-pending-puts > 2018-01-23 15:36:46 [remote-thread--p2-t1] ERROR o.i.i.InvocationContextInterceptor - ISPN000136: Error executing command BeginInvalidationCommand, writing keys test.app.data.User#2 > java.lang.NullPointerException: null > at org.hibernate.cache.infinispan.access.PutFromLoadValidator.beginInvalidatingWithPFER(PutFromLoadValidator.java:561) > at org.hibernate.cache.infinispan.access.PutFromLoadValidator.beginInvalidatingKey(PutFromLoadValidator.java:555) > at org.hibernate.cache.infinispan.access.NonTxPutFromLoadInterceptor.visitInvalidateCommand(NonTxPutFromLoadInterceptor.java:70) > at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:114) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99) > at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitInvalidateCommand(AbstractLockingInterceptor.java:112) > at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:114) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99) > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110) > at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:79) > at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:127) > at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:114) > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:335) > at org.infinispan.commands.remote.BaseRpcInvokingCommand.processVisitableCommand(BaseRpcInvokingCommand.java:43) > at org.infinispan.commands.remote.SingleRpcCommand.perform(SingleRpcCommand.java:51) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokePerform(BasePerCacheInboundInvocationHandler.java:92) > at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:34) > 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) > 2018-01-23 15:36:47 [main] TRACE o.i.manager.DefaultCacheManager - Closing latch for cache test.app.data.User-pending-puts -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2018