February 2017 - infinispan-issues

[JBoss JIRA] (ISPN-5793) Expose massindexer status and progress over mbean/dmr

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5793?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5793: ---------------------------------- Fix Version/s: (was: 9.0.0.Final) > Expose massindexer status and progress over mbean/dmr > ----------------------------------------------------- > > Key: ISPN-5793 > URL: https://issues.jboss.org/browse/ISPN-5793 > Project: Infinispan > Issue Type: Enhancement > Reporter: Tristan Tarrant > Assignee: Gustavo Fernandes > > It would be useful for the console/cli to expose the ongoing status/progress of any indexing happening on a cache. This would need to happen both on the massIndexer Mbean and on the server dmr > https://rawgit.com/infinispan/infinispan-console-mockup/master/cache-cont... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5794) Hot Rod should use functional map to do version-based replace

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5794?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5794: ---------------------------------- Fix Version/s: (was: 9.0.0.Final) > Hot Rod should use functional map to do version-based replace > ------------------------------------------------------------- > > Key: ISPN-5794 > URL: https://issues.jboss.org/browse/ISPN-5794 > Project: Infinispan > Issue Type: Enhancement > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > > Hot Rod should do version-based replace using the functional map API so that atomicity can be guaranteed and avoid odd behaviour like ISPN-4972 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5803) Custom Key Results in ClassCastException in CacheLoader

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5803?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5803: ---------------------------------- Fix Version/s: (was: 9.0.0.Final) > Custom Key Results in ClassCastException in CacheLoader > ------------------------------------------------------- > > Key: ISPN-5803 > URL: https://issues.jboss.org/browse/ISPN-5803 > Project: Infinispan > Issue Type: Bug > Components: JCache > Affects Versions: 8.0.1.Final > Reporter: Dan Siviter > Assignee: Galder Zamarreño > > If a a JCache is created using a read-through {{javax.cache.integration.CacheLoader}} using a custom Serializable key (in this case {{acme.MyCache$MyKey}}) a {{ClassCastException}} is thrown when trying to pass the key value of {{org.infinispan.marshall.core.MarshalledValue}} instead of {{MarshalledValue#get()}} into the {{CacheLoader}} instance. > {code} > java.lang.ClassCastException: org.infinispan.marshall.core.MarshalledValue cannot be cast to acme.MyCache$MyKey > at acme.MyCache$2.load(MyCache.java:1) [my-app-1.0.0-SNAPSHOT.jar:] > at org.infinispan.jcache.embedded.JCacheLoaderAdapter.loadKey(JCacheLoaderAdapter.java:65) [infinispan-jcache-8.0.1.Final.jar:8.0.1.Final] > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5849) AutoCloseable return from adding listeners can be clunky to use

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5849?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5849: ---------------------------------- Fix Version/s: (was: 9.0.0.Final) > AutoCloseable return from adding listeners can be clunky to use > --------------------------------------------------------------- > > Key: ISPN-5849 > URL: https://issues.jboss.org/browse/ISPN-5849 > Project: Infinispan > Issue Type: Sub-task > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > > On one side, to use it as a try-with-resource, you need to declare it right in the {{try()}}; > {code} > try(AutoCloseable handler = writeOnlyMap.listeners().onWrite(written -> > System.out.printf("Written (via onWrite): %s%n", written.get()))) { > Map<String, String> entries = new HashMap<>(); > entries.put("key1", "value1"); > entries.put("key2", "value2"); > writeOnlyMap.evalMany(entries, (v, writeView) -> writeView.set(v)) > .get(); // Wait for completable future > } > {code} > So its usability is mostly designed for unit tests since listeners tend to be set and removed at a later stage. IOW, listeners are not generally a short-lived object. > The other aspect that is clunky to use is the fact that AutoCloseable's close() throws Exception, which again makes it ackward to use for example if lambdas. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5849) AutoCloseable return from adding listeners can be clunky to use

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5849?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5849: ---------------------------------- Description: On one side, to use it as a try-with-resource, you need to declare it right in the {{try()}}; {code} try(AutoCloseable handler = writeOnlyMap.listeners().onWrite(written -> System.out.printf("Written (via onWrite): %s%n", written.get()))) { Map<String, String> entries = new HashMap<>(); entries.put("key1", "value1"); entries.put("key2", "value2"); writeOnlyMap.evalMany(entries, (v, writeView) -> writeView.set(v)) .get(); // Wait for completable future } {code} So its usability is mostly designed for unit tests since listeners tend to be set and removed at a later stage. IOW, listeners are not generally a short-lived object. The other aspect that is clunky to use is the fact that AutoCloseable's close() throws Exception, which again makes it ackward to use for example if lambdas. was: On one side, to use it as a try-with-resource, you need to declare it right in the {{try()}}; {code} try(AutoCloseable handler = writeOnlyMap.listeners().onWrite(written -> System.out.printf("Written (via onWrite): %s%n", written.get()))) { Map<String, String> entries = new HashMap<>(); entries.put("key1", "value1"); entries.put("key2", "value2"); writeOnlyMap.evalMany(entries, (v, writeView) -> writeView.set(v)) .get(); // Wait for completable future } {code} So it's usability is mostly designed for unit tests since listeners tend to be set and removed at a later stage. IOW, listeners are not generally a short-lived object. The other aspect that is clunky to use is the fact that AutoCloseable's close() throws Exception, which again makes it ackward to use for example if lambdas. > AutoCloseable return from adding listeners can be clunky to use > --------------------------------------------------------------- > > Key: ISPN-5849 > URL: https://issues.jboss.org/browse/ISPN-5849 > Project: Infinispan > Issue Type: Sub-task > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > > On one side, to use it as a try-with-resource, you need to declare it right in the {{try()}}; > {code} > try(AutoCloseable handler = writeOnlyMap.listeners().onWrite(written -> > System.out.printf("Written (via onWrite): %s%n", written.get()))) { > Map<String, String> entries = new HashMap<>(); > entries.put("key1", "value1"); > entries.put("key2", "value2"); > writeOnlyMap.evalMany(entries, (v, writeView) -> writeView.set(v)) > .get(); // Wait for completable future > } > {code} > So its usability is mostly designed for unit tests since listeners tend to be set and removed at a later stage. IOW, listeners are not generally a short-lived object. > The other aspect that is clunky to use is the fact that AutoCloseable's close() throws Exception, which again makes it ackward to use for example if lambdas. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5615) Transfer sections from the Hibernate Search reference documentation about the Lucene Directory Provider

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5615?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5615: ---------------------------------- Fix Version/s: (was: 9.0.0.Final) > Transfer sections from the Hibernate Search reference documentation about the Lucene Directory Provider > ------------------------------------------------------------------------------------------------------- > > Key: ISPN-5615 > URL: https://issues.jboss.org/browse/ISPN-5615 > Project: Infinispan > Issue Type: Task > Components: Documentation-Query > Reporter: Sanne Grinovero > > The general introduction to Infinispan should stay in the Hibernate Search documentation > - http://docs.jboss.org/hibernate/search/5.3/reference/en-US/html_single/#i... > But configuration options and tuning recommendations whould be transferred to the Infinispan reference documentation as the exact properties and their effect would depend on the Infinispan version being used (most of section 3.3.1.3. Infinispan Configuration) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5862) Add version number to deprecated comments

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5862?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5862: ---------------------------------- Fix Version/s: (was: 9.0.0.Final) > Add version number to deprecated comments > ----------------------------------------- > > Key: ISPN-5862 > URL: https://issues.jboss.org/browse/ISPN-5862 > Project: Infinispan > Issue Type: Task > Components: Documentation-Core > Affects Versions: 8.1.0.Alpha1 > Reporter: Dan Berindei > > It should be possible to remove deprecated classes and methods after one major version cycle, but it's not always obvious when the API was deprecated. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5642) Reduce contention in the RPC timeout handling

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5642?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5642: ---------------------------------- Fix Version/s: (was: 9.0.0.Final) > Reduce contention in the RPC timeout handling > --------------------------------------------- > > Key: ISPN-5642 > URL: https://issues.jboss.org/browse/ISPN-5642 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 8.0.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > Labels: help_wanted > > Most of the RPC timeout tasks are cancelled way before their timeout expires. This means the scheduler spends a lot of time reordering the elements of its DelayQueue. > It should be possible to store the tasks with a long timeout (e.g. 1s) in a queue and only move them to the scheduler's priority queue when they have less than 1s to expiration (e.g. by a worker thread that runs every 0.5s) > Storing all the tasks in a single queue may be impractical because the worker thread would have more and work to do as load increases and the RPCs take longer to finish, so a [hashed timing wheel|http://www.cse.wustl.edu/~cdgill/courses/cs6874/TimingWheels.ppt] may be needed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5614) Write performance regression after ISPN-5484

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5614?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-5614. --------------------------------- Fix Version/s: (was: 9.0.0.Final) Resolution: Out of Date > Write performance regression after ISPN-5484 > -------------------------------------------- > > Key: ISPN-5614 > URL: https://issues.jboss.org/browse/ISPN-5614 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.0.0.Beta1 > Reporter: Dan Berindei > Assignee: Dan Berindei > > Regression test shows a significant drop in throughput in the replicated and distributed write tests. > This was after adjusting the internal thread pool settings in the JGroups configuration: with the default (min=5, max=20, queue=0), the distributed read test would fail to finish. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7533) Accessing cache with disabled security resolves in SecurityException

by Roman Macor (JIRA)

[ https://issues.jboss.org/browse/ISPN-7533?page=com.atlassian.jira.plugin.... ] Roman Macor updated ISPN-7533: ------------------------------ Priority: Blocker (was: Major) > Accessing cache with disabled security resolves in SecurityException > --------------------------------------------------------------------- > > Key: ISPN-7533 > URL: https://issues.jboss.org/browse/ISPN-7533 > Project: Infinispan > Issue Type: Bug > Components: Security, Server > Affects Versions: 9.0.0.CR2 > Reporter: Roman Macor > Priority: Blocker > > This happens when the security is defined in cache container, but the cache has security disabled. > Steps to reproduce: > - Start standalone with defined security e.g. docs/examples/configs/standalone-auth.xml > - try accessing unsecured cache with hotrod e.g. > {code:title=Reproducer.java|borderStyle=solid} > ConfigurationBuilder builder = new ConfigurationBuilder(); > builder.addServer().host("127.0.0.1").port(ConfigurationProperties.DEFAULT_HOTROD_PORT) > RemoteCacheManager cacheManager = new RemoteCacheManager(builder.build()); > RemoteCache<String, String> cache = cacheManager.getCache("default"); > cache.put("key", "value"); > System.out.printf("key = %s\n", cache.get("key")); > cacheManager.stop(); > {code} > Result: > org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for messageId=3 returned server error (status=0x85): java.lang.SecurityException: ISPN006017: Unauthorized operation > at org.infinispan.client.hotrod.impl.protocol.Codec20.checkForErrorsInResponseStatus(Codec20.java:363) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:152) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:138) > at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:60) > at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:58) > at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:34) > at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:56) > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:269) > at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79) > at HotRodAuthTest.test(HotRodAuthTest.java:18) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > 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:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > 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) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2017