August 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5067) CLI for server docs need updating to reflect WildFly base

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5067?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5067: -------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 9.0.0.Alpha4) > CLI for server docs need updating to reflect WildFly base > --------------------------------------------------------- > > Key: ISPN-5067 > URL: https://issues.jboss.org/browse/ISPN-5067 > Project: Infinispan > Issue Type: Bug > Components: Documentation-Servers > Affects Versions: 7.1.0.Alpha1 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5058) Document example configurations using a CacheStore to persist the Lucene index

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5058?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5058: -------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 9.0.0.Alpha4) > Document example configurations using a CacheStore to persist the Lucene index > ------------------------------------------------------------------------------ > > Key: ISPN-5058 > URL: https://issues.jboss.org/browse/ISPN-5058 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation-Query > Reporter: Sanne Grinovero > Assignee: Gustavo Fernandes > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4923) Server should allow toggling statistics at runtime

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4923?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4923: -------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 9.0.0.Alpha4) > Server should allow toggling statistics at runtime > -------------------------------------------------- > > Key: ISPN-4923 > URL: https://issues.jboss.org/browse/ISPN-4923 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 7.0.0.CR2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4903) ServerFailureRetrySingleOwnerTest doesn't actually test client retry

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4903?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4903: -------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 9.0.0.Alpha4) > ServerFailureRetrySingleOwnerTest doesn't actually test client retry > -------------------------------------------------------------------- > > Key: ISPN-4903 > URL: https://issues.jboss.org/browse/ISPN-4903 > Project: Infinispan > Issue Type: Bug > Components: Server, Test Suite - Server > Affects Versions: 7.0.0.CR2 > Reporter: Dan Berindei > Fix For: 9.0.0.Beta1 > > Attachments: ServerFailureRetrySingleOwnerTest.java > > > With {{useSynchronization = true}} (the default, before ISPN-4166 is integrated), the {{SuspectException}} thrown by the listener is swallowed by the transaction manager and the client doesn't retry. The test doesn't pick that up because the exception is thrown _after_ the entry was updated in the data container (a regular SuspectException would be thrown before). > I changed the configuration to {{useSynchronization = false}}, but it didn't work because the {{SuspectException}} is wrapped in a {{CacheListenerException}}, so the client throws an exception instead of retrying. I also changed the test to use an interceptor instead of a listener, but then I got a {{ClassCastException}}: > {noformat} > Caused by: java.lang.ClassCastException: [B cannot be cast to org.infinispan.container.entries.CacheEntry > at org.infinispan.cache.impl.CacheImpl.getCacheEntry(CacheImpl.java:424) > at org.infinispan.cache.impl.CacheImpl.getCacheEntry(CacheImpl.java:429) > at org.infinispan.server.hotrod.Decoder2x$.customReadKey(Decoder2x.scala:285) > at org.infinispan.server.hotrod.HotRodDecoder.customDecodeKey(HotRodDecoder.scala:156) > at org.infinispan.server.core.AbstractProtocolDecoder.org$infinispan$server$core$AbstractProtocolDecoder$$decodeKey(AbstractProtocolDecoder.scala:176) > at org.infinispan.server.core.AbstractProtocolDecoder.decodeDispatch(AbstractProtocolDecoder.scala:71) ... 14 more > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4899) Update user guide regarding protobuf schema definition API

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4899?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4899: -------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 9.0.0.Alpha4) > Update user guide regarding protobuf schema definition API > ---------------------------------------------------------- > > Key: ISPN-4899 > URL: https://issues.jboss.org/browse/ISPN-4899 > Project: Infinispan > Issue Type: Task > Components: Documentation-Query > Affects Versions: 7.0.0.CR2 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.0.0.Beta1 > > > Describe the usage of __protobuf_metadata cache -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5083) Hot Rod decoder should use async Cache operations

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5083?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5083: -------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 9.0.0.Alpha4) > Hot Rod decoder should use async Cache operations > ------------------------------------------------- > > Key: ISPN-5083 > URL: https://issues.jboss.org/browse/ISPN-5083 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Reporter: Galder Zamarreño > Assignee: Gustavo Fernandes > Fix For: 9.0.0.Beta1 > > > Hot Rod decoder is currently tying up Netty threads as a result of calling up to Infinispan sync operations. Instead, Hot Rod decoder should call up async operations, convert the Notifying Futures to Scala Futures, and write up the reply when it's received. This should increase performance specially under heavy load. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5077) Custom remote events can be slightly inefficient

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5077?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5077: -------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 9.0.0.Alpha4) > Custom remote events can be slightly inefficient > ------------------------------------------------ > > Key: ISPN-5077 > URL: https://issues.jboss.org/browse/ISPN-5077 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Affects Versions: 7.0.2.Final > Reporter: Galder Zamarreño > Fix For: 9.0.0.Beta1 > > > Something we might want to improve for Hot Rod 3.0 protocol: > [16:40] <galderz> i've been thinking further about converters, and I think i've found a slight mismatch between what converter means for embedded listeners vs remote listeners > [16:40] <wburns> oh yeah? > [16:40] <galderz> for embedded listeners, it essentially transforms what you see as `value` > [16:41] <galderz> with the knowledge that key and metadata information will be shipped > [16:41] <galderz> the way i mapped converter to remote listeners is that whatever the converter returns, we ship that, as is, to the client > [16:41] <galderz> so, if a remote listener wants a custom event that includes key + value > [16:41] <galderz> it needs to develop a converter impl that returns bytes containing key + value > [16:41] <galderz> which is inefficient because you are passing around the key twice > [16:42] <galderz> once as part of the event itself, and again inside the converted value > [16:42] <galderz> inefficient from the POV of shipping stuff around from other nodes to where the cluster listener is located > [16:44] <wburns> yeah makes sense > [16:44] <galderz> not a major issue but not easy to fix without changing semantics or public protocol -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5075) org.infinispan.IllegalLifecycleStateException in query tests

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5075?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5075: -------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 9.0.0.Alpha4) > org.infinispan.IllegalLifecycleStateException in query tests > ------------------------------------------------------------ > > Key: ISPN-5075 > URL: https://issues.jboss.org/browse/ISPN-5075 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Query > Affects Versions: 7.1.0.Alpha1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 9.0.0.Beta1 > > > Many query tests log an error after running: > {code} > Exception in thread "Hibernate Search: async deletion of index segments-1" org.infinispan.IllegalLifecycleStateException: ISPN000323: Cache 'LuceneIndexesMetadata' is in 'TERMINATED' state and so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:89) > at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71) > at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:77) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:44) > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333) > at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:422) > at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:427) > at org.infinispan.lucene.impl.FileListOperations.getFileList(FileListOperations.java:160) > at org.infinispan.lucene.impl.FileListOperations.deleteFileName(FileListOperations.java:129) > at org.infinispan.lucene.impl.DirectoryImplementor.deleteFile(DirectoryImplementor.java:64) > at org.infinispan.lucene.impl.DirectoryLuceneV4$DeleteTask.run(DirectoryLuceneV4.java:195) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > {code} > That error does not cause the tests to fail, and are due to the async deletes of segments recently implemented. Need to check if the executors are being flushed correctly when the cache manager stops -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5179) Add distributed execution and map/reduce job statistics

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5179?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5179: -------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 9.0.0.Alpha4) > Add distributed execution and map/reduce job statistics > -------------------------------------------------------- > > Key: ISPN-5179 > URL: https://issues.jboss.org/browse/ISPN-5179 > Project: Infinispan > Issue Type: Feature Request > Components: JMX, reporting and management > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Fix For: 9.0.0.Beta1 > > > We should add DMR/JMX statistics for the running distributed execution jobs as well as map/reduce jobs. The statistics will also include overview/total system statistics of previously executed jobs; we might store statistics of individual executed jobs in some internal cache. However, the primary objective is to calculate and maintain dist.exec and map/reduce job statistics for Infinispan admin console. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5163) A write operation with the SKIP_LOCKING flag can roll back the transaction

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5163?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5163: -------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 9.0.0.Alpha4) > A write operation with the SKIP_LOCKING flag can roll back the transaction > -------------------------------------------------------------------------- > > Key: ISPN-5163 > URL: https://issues.jboss.org/browse/ISPN-5163 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.3.Final, 7.1.0.Beta1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.Beta1 > > > When a write operation has the SKIP_LOCKING flag, it does not send a {{LockControlCommand}} to the primary owner, but it can send a {{ClusteredGetCommand}} with {{acquireRemoteLocks=true}} instead. The {{ClusteredGetCommmand}} will then execute a {{LockControlCommand}} with the origin not set properly, and {{TxInterceptor}} will roll back the transaction because the originator ({{null}}) appears to have left the cluster. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues August 2016