January 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3539) Allow adding multiple custom interceptors without calling customInterceptors() every time

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3539?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-3539: ------------------------------------- Assignee: (was: Mircea Markus) > Allow adding multiple custom interceptors without calling customInterceptors() every time > ----------------------------------------------------------------------------------------- > > Key: ISPN-3539 > URL: https://issues.jboss.org/browse/ISPN-3539 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Jiří Holuša > Priority: Minor > > When adding multiple custom interceptors programmatically via ConfigurationBuilder, you have to call customInterceptors() every time you want to add a new one. > The code than looks like this: > {code:borderStyle=solid} > Configuration c2 = new ConfigurationBuilder() > .customInterceptors() > .addInterceptor() > .position(InterceptorConfiguration.Position.FIRST).interceptor(new FirstInterceptor(1)) > .customInterceptors() > .addInterceptor() > .after(FirstInterceptor.class).interceptor(new SecondInterceptor(2)) > .build(); > {code} > I think this is very ugly and it would be nice and even semantically more meaningful to do it like: > {code:borderStyle=solid} > Configuration c2 = new ConfigurationBuilder() > .customInterceptors() > .addInterceptor() > .position(InterceptorConfiguration.Position.FIRST).interceptor(new FirstInterceptor(1)) > .addInterceptor() > .after(FirstInterceptor.class).interceptor(new SecondInterceptor(2)) > .build(); > {code} > e.g. calling customInterceptors() only once. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3847) Improve resilience of ModuleLifecycle loading

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3847?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-3847: ------------------------------------- Assignee: (was: Mircea Markus) > Improve resilience of ModuleLifecycle loading > --------------------------------------------- > > Key: ISPN-3847 > URL: https://issues.jboss.org/browse/ISPN-3847 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 6.0.1.Final > Reporter: Paul Ferraro > > Currently, org.infinispan.util.ModuleProperties.resolveModuleLifecycles(...) uses a ServiceLoader to directly load ModuleLifecycle instances. However, if a jar exists on the classpath containing a META-INF/services/org.infinispan.lifecycle.ModuleLifecycle file, but the class name contained within cannot be loaded, due to, for example, a dependency jar being missing, then the whole resolveModuleLifecycles(...) method chokes due to a ServiceConfigurationError. For example, if infinispan-query is on the classpath, but hibernate-search is not, Infinispan is unusable. > I can see 2 ways to fix this: > 1. Use the iterator directly instead of the enhanced for-loop, and catch and handle the SCE: > e.g. > {code:java} > Iterator<ModuleLifecycle> lifecycles = ServiceLoader.load(ModuleLifecycle.class, classLoader); > while (lifecycles.hasNext()) { > try { > ModuleLifecycle lifecycle = lifecycles.next(); // This can throw SCE > result.add(lifecycle); > } catch (ServiceConfigurationError e) { > // Log error > } > } > {code} > 2. Introduce a ModuleLifecycleProvider abstraction - that won't throw an SCE. The ServiceLoader spec actually recommends this: > "The provider class is typically not the entire provider itself but rather a proxy which contains enough information to decide whether the provider is able to satisfy a particular request together with code that can create the actual provider on demand." > In the end, this would look something like: > {code:java} > for (ModuleLifecycleFactory factory: ServiceLoader.load(ModuleLifecycleFactory.class, classLoader)) { > if (factory.isEnabled()) { // returns true if create method will not throw SCE > ModuleLifecycle lifecycle = factory.createModuleLifecycle(); > result.add(lifecycle); > } > } > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2893) GUI Demo sample configs include old RELAY configuration instead of RELAY2

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2893?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-2893: ------------------------------------- Assignee: (was: Mircea Markus) > GUI Demo sample configs include old RELAY configuration instead of RELAY2 > ------------------------------------------------------------------------- > > Key: ISPN-2893 > URL: https://issues.jboss.org/browse/ISPN-2893 > Project: Infinispan > Issue Type: Feature Request > Components: Demos and Tutorials > Affects Versions: 5.2.3.Final > Reporter: NadirX > Priority: Minor > > The files in infinispan/demos/gui/src/main/release/etc/config-samples related to xsite configuration still reference the old RELAY stack instead of the newer RELAY2. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3545) Migrate jdbm cache store to the 6.0 cachestore API

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3545?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-3545: ------------------------------------- Assignee: (was: Mircea Markus) > Migrate jdbm cache store to the 6.0 cachestore API > --------------------------------------------------- > > Key: ISPN-3545 > URL: https://issues.jboss.org/browse/ISPN-3545 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: Mircea Markus > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4815) Broken connection in server JDBC tests

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4815?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-4815: ------------------------------------- Assignee: (was: Mircea Markus) > Broken connection in server JDBC tests > -------------------------------------- > > Key: ISPN-4815 > URL: https://issues.jboss.org/browse/ISPN-4815 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 7.0.0.CR1 > Environment: All tested platforms > Reporter: Roman Macor > Labels: jdbc > > All server related JDBC tests are experience problem with broken connection. > The main error extracted from test logs is this: > Caused by: org.h2.jdbc.JdbcSQLException: Connection is broken: "unexpected status 16777216" [90067-168] > at org.h2.message.DbException.getJdbcSQLException(DbException.java:329) > at org.h2.message.DbException.get(DbException.java:169) > at org.h2.message.DbException.get(DbException.java:146) > at org.h2.engine.SessionRemote.done(SessionRemote.java:582) > at org.h2.command.CommandRemote.prepare(CommandRemote.java:67) > at org.h2.command.CommandRemote.<init>(CommandRemote.java:46) > at org.h2.engine.SessionRemote.prepareCommand(SessionRemote.java:439) > at org.h2.jdbc.JdbcConnection.prepareCommand(JdbcConnection.java:1113) > at org.h2.jdbc.JdbcConnection.getTransactionIsolation(JdbcConnection.java:732) > at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.<init>(BaseWrapperManagedConnection.java:195) > at org.jboss.jca.adapters.jdbc.local.LocalManagedConnection.<init>(LocalManagedConnection.java:61) > at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:309) > ... 42 more -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3804) Test server.hotrod.HotRod<11, 12>ReplicationTest.testReplicatedPutWithTopologyChanges fails on all platforms

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3804?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-3804: ------------------------------------- Assignee: (was: Mircea Markus) > Test server.hotrod.HotRod<11,12>ReplicationTest.testReplicatedPutWithTopologyChanges fails on all platforms > ----------------------------------------------------------------------------------------------------------- > > Key: ISPN-3804 > URL: https://issues.jboss.org/browse/ISPN-3804 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 6.0.0.Final > Environment: Solaris, Oracle JDK 6 and 7, Windows Oracle JDK6 > Reporter: Vojtech Juranek > Labels: testsuite_stability > Attachments: server.hotrod.zip > > > SO following tests fail often on RHEL > org.infinispan.server.hotrod.HotRodReplicationTest.testReplicatedPutWithTopologyChanges > org.infinispan.server.hotrod.HotRod12ReplicationTest.testReplicatedPutWithTopologyChanges > org.infinispan.server.hotrod.HotRod11ReplicationTest.testDistributedPutWithTopologyChanges > And these fail on Solaris > org.infinispan.server.hotrod.HotRodReplicationTest.testReplicatedPutWithTopologyChanges > org.infinispan.server.hotrod.HotRod12ReplicationTest.testReplicatedPutWithTopologyChanges > org.infinispan.server.hotrod.HotRod11ReplicationTest.testDistributedPutWithTopologyChanges > Tests {{HotRod12ReplicationTest.testReplicatedPutWithTopologyChanges}}, {{HotRod11ReplicationTest.testDistributedPutWithTopologyChanges}} and {{HotRodReplicationTest.testReplicatedPutWithTopologyChanges}} fails with following assertions failure: > {noformat} > java.lang.AssertionError: expected [2] but found [3] > at org.testng.Assert.fail(Assert.java:89) > at org.testng.Assert.failNotEquals(Assert.java:489) > at org.testng.Assert.assertEquals(Assert.java:118) > at org.testng.Assert.assertEquals(Assert.java:365) > at org.testng.Assert.assertEquals(Assert.java:375) > at org.infinispan.server.hotrod.HotRodReplicationTest.testReplicatedPutWithTopologyChanges(HotRodReplicationTest.scala:123) > 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.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:715) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) > at org.testng.TestRunner.privateRun(TestRunner.java:767) > at org.testng.TestRunner.run(TestRunner.java:617) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:37) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368) > at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) > 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:724) > {noformat} > See e.g. > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4455) Provide ability to block/notify on RPC readiness on node startup

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4455?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-4455: ------------------------------------- Assignee: (was: Mircea Markus) > Provide ability to block/notify on RPC readiness on node startup > ---------------------------------------------------------------- > > Key: ISPN-4455 > URL: https://issues.jboss.org/browse/ISPN-4455 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 6.0.0.Final > Reporter: Mikhail Dobrinin > Priority: Minor > > Currently, when a node joins the cluster, the members will receive a ViewChanged event. However, this does not mean you can act on it in all ways. For example, you cannot send an RPC command to the new member. If you do then he will respond with {{CacheNotFoundResponse}} because his ComponentRegistry is not set up with the cache yet. It would be helpful if there were some way to know when someone joined *and* they are fully functional. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3789) Cross site replication site status does not reflect real status

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3789?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-3789: ------------------------------------- Assignee: (was: Mircea Markus) > Cross site replication site status does not reflect real status > --------------------------------------------------------------- > > Key: ISPN-3789 > URL: https://issues.jboss.org/browse/ISPN-3789 > Project: Infinispan > Issue Type: Bug > Components: CLI, Cross-Site Replication > Affects Versions: 5.2.5.Final > Environment: ISPN 5.2.5 final > Reporter: dex chen > > Having 2 site configured for cross site replication (sync). > With the tcp port for xsite replication is blocked, and starts both sites. > After cache managers started up, using CLI to check site status (site --status), the status shows the backup site is ONLINE. > However, the cache entry is not replicating, and network connection for xsite replication is not established (by netstat output). > Anyway, the CLI site status does not return the real/correct status, or misleading. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2590) In case of Errors/Warns/Exceptions include cache name into log/message

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2590?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-2590: ------------------------------------- Assignee: (was: Mircea Markus) > In case of Errors/Warns/Exceptions include cache name into log/message > ---------------------------------------------------------------------- > > Key: ISPN-2590 > URL: https://issues.jboss.org/browse/ISPN-2590 > Project: Infinispan > Issue Type: Enhancement > Components: Transactions > Affects Versions: 5.2.0.Beta5 > Reporter: Thomas Fromm > > When having lots of caches in use and its not always possible to determine the used cache based upon cache key, it would be very useful to have the related cache name inside logs/messages. > For example: > ERROR 05.12.12 20:09:40,589 [OOB-160,IBIS-32523] InvocationContextInterceptor ISPN000136: Execution error > org.infinispan.util.concurrent.TimeoutException: Could not acquire lock on CacheKey{name='Mux234935827442390'} on behalf of transaction GlobalTransaction:<IBIS-15651>:10696:remote. Lock > is being held by null -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2732) Support more efficient operations when value is a collection

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2732?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-2732: ------------------------------------- Assignee: (was: Mircea Markus) > Support more efficient operations when value is a collection > ------------------------------------------------------------ > > Key: ISPN-2732 > URL: https://issues.jboss.org/browse/ISPN-2732 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Ray Tsang > > Support operations such as append, push/pop, etc for being able to store collection/list as value > Support operation such as slice to retrieve parts of collections. > Some collections in mind are: Deque, PriorityQueue (heap, sorted list), etc. > Perhaps expand on Delta and DeltaAware, and as counterparts to AtomicHashMap. > If using current map interface, maybe something along the line of: > map.put("key", new AppendDelta("...")); > map.get("key", new RangeSlice(1, 5)); > or advancedCache.applyDelta(...); and advancedCache.retrieveSlice(...)? -- 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