January 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5187) Node.js HotRod client

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-5187: ------------------------------------- Summary: Node.js HotRod client Key: ISPN-5187 URL: https://issues.jboss.org/browse/ISPN-5187 Project: Infinispan Issue Type: Feature Request Components: Remote Protocols Reporter: Tristan Tarrant Either implement a pure javascript client or base on the native C++ client. Should be L2/L3 aware. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5186) Implement a topology-aware RESTful client

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-5186: ------------------------------------- Summary: Implement a topology-aware RESTful client Key: ISPN-5186 URL: https://issues.jboss.org/browse/ISPN-5186 Project: Infinispan Issue Type: Feature Request Components: Remote Protocols Reporter: Tristan Tarrant After we implement ISPN-5185, implement an intelligent RESTful client which can use the topology information contained in the headers to be topology and consistent-hash -aware. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5185) Optionally add topology information to REST headers

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5185?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5185: ---------------------------------- Priority: Minor (was: Major) > Optionally add topology information to REST headers > --------------------------------------------------- > > Key: ISPN-5185 > URL: https://issues.jboss.org/browse/ISPN-5185 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Reporter: Tristan Tarrant > Priority: Minor > > If we add topology information to the HTTP headers returned by our RESTful server, it would be possible to implement to implement a topology and consistent hash-aware HTTP client. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5185) Optionally add topology information to REST headers

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-5185: ------------------------------------- Summary: Optionally add topology information to REST headers Key: ISPN-5185 URL: https://issues.jboss.org/browse/ISPN-5185 Project: Infinispan Issue Type: Feature Request Reporter: Tristan Tarrant If we add topology information to the HTTP headers returned by our RESTful server, it would be possible to implement to implement a topology and consistent hash-aware HTTP client. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5185) Optionally add topology information to REST headers

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5185?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5185: ---------------------------------- Component/s: Remote Protocols > Optionally add topology information to REST headers > --------------------------------------------------- > > Key: ISPN-5185 > URL: https://issues.jboss.org/browse/ISPN-5185 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Reporter: Tristan Tarrant > > If we add topology information to the HTTP headers returned by our RESTful server, it would be possible to implement to implement a topology and consistent hash-aware HTTP client. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4810) Local Transactional Cache loses data when eviction is enabled and there are multiple readers and one writer

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4810?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-4810: ------------------------------------- Changing the use case to use ISPN 7.0.3 it got much further but I encountered a NPE {code} shouldHandleOneWriterAndMultipleReadersRepeatedly(org.infinispan.InfinispanConcurrent7Test) Time elapsed: 6.452 sec <<< ERROR! java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) at java.util.concurrent.FutureTask.get(FutureTask.java:202) at org.infinispan.InfinispanConcurrent7Test.cacheShouldHandleOneWriterAndMultipleReaders(InfinispanConcurrent7Test.java:125) at org.infinispan.InfinispanConcurrent7Test.shouldHandleOneWriterAndMultipleReadersRepeatedly(InfinispanConcurrent7Test.java:76) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) Caused by: java.lang.NullPointerException at org.infinispan.util.concurrent.BoundedConcurrentHashMap$LIRSHashEntry.access$1400(BoundedConcurrentHashMap.java:588) at org.infinispan.util.concurrent.BoundedConcurrentHashMap$LIRS.removeFromSegment(BoundedConcurrentHashMap.java:1068) at org.infinispan.util.concurrent.BoundedConcurrentHashMap$LIRS.onEntryMiss(BoundedConcurrentHashMap.java:1062) at org.infinispan.util.concurrent.BoundedConcurrentHashMap$BatchWrapper.onEntryMiss(BoundedConcurrentHashMap.java:451) at org.infinispan.util.concurrent.BoundedConcurrentHashMap$Segment.put(BoundedConcurrentHashMap.java:1391) at org.infinispan.util.concurrent.BoundedConcurrentHashMap.put(BoundedConcurrentHashMap.java:1953) at org.infinispan.container.DefaultDataContainer$BoundedConcurrentExtendedMap.compute(DefaultDataContainer.java:537) at org.infinispan.container.DefaultDataContainer.compute(DefaultDataContainer.java:251) at org.infinispan.persistence.PersistenceUtil.loadAndStoreInDataContainer(PersistenceUtil.java:90) at org.infinispan.interceptors.CacheLoaderInterceptor.loadIfNeeded(CacheLoaderInterceptor.java:236) at org.infinispan.interceptors.CacheLoaderInterceptor.loadIfNeededAndUpdateStats(CacheLoaderInterceptor.java:362) at org.infinispan.interceptors.CacheLoaderInterceptor.visitGetKeyValueCommand(CacheLoaderInterceptor.java:121) at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:39) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) at org.infinispan.interceptors.EntryWrappingInterceptor.visitDataReadCommand(EntryWrappingInterceptor.java:139) at org.infinispan.interceptors.EntryWrappingInterceptor.visitGetKeyValueCommand(EntryWrappingInterceptor.java:129) at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:39) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataReadCommand(PessimisticLockingInterceptor.java:81) at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitGetKeyValueCommand(PessimisticLockingInterceptor.java:67) at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:39) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:77) at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:39) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:322) at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:300) at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:39) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) at org.infinispan.interceptors.CacheMgmtInterceptor.visitDataReadCommand(CacheMgmtInterceptor.java:103) at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:91) at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:39) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102) 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:39) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:66) at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:77) at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:39) at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333) at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:423) at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:415) at org.infinispan.InfinispanConcurrent7Test$ListReader.call(InfinispanConcurrent7Test.java:175) at org.infinispan.InfinispanConcurrent7Test$ListReader.call(InfinispanConcurrent7Test.java:163) at java.util.concurrent.FutureTask.run(FutureTask.java:262) 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} > Local Transactional Cache loses data when eviction is enabled and there are multiple readers and one writer > ----------------------------------------------------------------------------------------------------------- > > Key: ISPN-4810 > URL: https://issues.jboss.org/browse/ISPN-4810 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.2.Final > Environment: Windows 7 x64 (NTFS) > Oracle JDK1.7.0_40 > Apache Maven 3.0.5 > Reporter: Horia Chiorean > Labels: modeshape > Attachments: ispn_concurrent.zip > > > Using Infinispan 6.0.2 and a local, transactional cache backed by a <singleFile> store, with eviction enabled and a small {{max-entries}} setting, we have the following scenario: > * the main thread (i.e. the "writer") starts a transaction, adds a batch of strings into the cache and also appends the same strings into a List cache entry and then commits the transaction > * after the above has finished (i.e. after tx.commit) it fires a number of reader threads where each reader thread > ** checks that the string entries were added into the cache and > ** checks that the entries were correctly appended to the List entry > * the above steps are repeated a number of times > On any given run, based on timing, we're seeing that at some point (after some time) some of the reader threads will not see the latest version of the List entry (i.e. will not see the latest elements that were added into the list) but rather an old, stale List (sort of a "lost update" scenario). > If we either: > * disable eviction or > * set the {{max-entries}} to a large enough value (which I suspect has the same effect - not evicting anything) the problem doesn't show up. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4359) Provide an annotation driven way of declaring protobuf metadata

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4359?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4359: ----------------------------------------------- Misha H. Ali <mhusnain(a)redhat.com> changed the Status of [bug 1182112|https://bugzilla.redhat.com/show_bug.cgi?id=1182112] from RELEASE_PENDING to CLOSED > Provide an annotation driven way of declaring protobuf metadata > --------------------------------------------------------------- > > Key: ISPN-4359 > URL: https://issues.jboss.org/browse/ISPN-4359 > Project: Infinispan > Issue Type: Feature Request > Components: Marshalling > Affects Versions: 7.0.0.Alpha4 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: jdg > Fix For: 7.1.0.Beta1 > > > The main goal of this is to simply marshalling of java objects to protobuf using the Protostream library. > Instead of providing a Protostream MessageMarshaller implementation and a proto schema file it would be nice to have an alternative way of just adding minimal annotations to a Java class (and its fields) to assist on the fly generation (via reflection) of the proto schema. The Protostream library should also infer the marshaller so it would not require a manually implemented one. The annotation should require minimal info (tag number) and the rest should be inferred based on common sense defaults (protobuf type, java collection type, collection element type ...) but should be possible to override. The auto-generated schema should be available to users and they should be able then to use it as reference if they need it to implement domain model classes and marshallers for other languages. > The user should still be able to specify a manually created schema (besides the annotated classes) and in that case the Protostream library should check the auto-inferred schema against the provided one and ensure they match. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4820) Change Size method on Cache to return the contents of the entire cluster

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4820?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4820: ----------------------------------------------- Misha H. Ali <mhusnain(a)redhat.com> changed the Status of [bug 1157390|https://bugzilla.redhat.com/show_bug.cgi?id=1157390] from RELEASE_PENDING to CLOSED > Change Size method on Cache to return the contents of the entire cluster > ------------------------------------------------------------------------ > > Key: ISPN-4820 > URL: https://issues.jboss.org/browse/ISPN-4820 > Project: Infinispan > Issue Type: Enhancement > Affects Versions: 7.0.0.CR1 > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.CR2 > > > It has been discussed to change the size method to properly reflect the contents of the entire cache instead of just locally. > http://lists.jboss.org/pipermail/infinispan-dev/2014-October/015524.html > It seems for now we should do this via the entry iterator for distributed caches otherwise use current implementation for local. Or something of that sort. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3718) Select which protobuf fields to index

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3718?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3718: ----------------------------------------------- Misha H. Ali <mhusnain(a)redhat.com> changed the Status of [bug 1172107|https://bugzilla.redhat.com/show_bug.cgi?id=1172107] from RELEASE_PENDING to CLOSED > Select which protobuf fields to index > ------------------------------------- > > Key: ISPN-3718 > URL: https://issues.jboss.org/browse/ISPN-3718 > Project: Infinispan > Issue Type: Feature Request > Components: Embedded Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: 64QueryBlockers > Fix For: 7.0.0.Final > > > Currently we index all fields. An interesting idea is to use a custom protobuf Option (see 'Custom Options' section here https://developers.google.com/protocol-buffers/docs/proto) to indicate which message types and specifically which fields should be indexed, similar to Hibernate Search annotations. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4769) XSD documentation generator does not handle some types (e.g. xs:list)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4769?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4769: ----------------------------------------------- Misha H. Ali <mhusnain(a)redhat.com> changed the Status of [bug 1164688|https://bugzilla.redhat.com/show_bug.cgi?id=1164688] from RELEASE_PENDING to CLOSED > XSD documentation generator does not handle some types (e.g. xs:list) > --------------------------------------------------------------------- > > Key: ISPN-4769 > URL: https://issues.jboss.org/browse/ISPN-4769 > Project: Infinispan > Issue Type: Bug > Components: Documentation-Core > Affects Versions: 7.0.0.Beta2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.0.0.CR1 > > > The XSD documentation generator does not handle xs:list simpleTypes and doesn't show documentation for restrictions. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 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 January 2015