[JBoss JIRA] (ISPN-3539) Allow adding multiple custom interceptors without calling customInterceptors() every time
by Jiří Holuša (JIRA)
Jiří Holuša created ISPN-3539:
---------------------------------
Summary: 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
Reporter: Jiří Holuša
Assignee: Mircea Markus
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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (ISPN-3538) Align recovery() enabling in Configuration
by Jiří Holuša (JIRA)
Jiří Holuša created ISPN-3538:
---------------------------------
Summary: Align recovery() enabling in Configuration
Key: ISPN-3538
URL: https://issues.jboss.org/browse/ISPN-3538
Project: Infinispan
Issue Type: Bug
Components: Configuration
Affects Versions: 6.0.0.Beta1
Reporter: Jiří Holuša
Assignee: Mircea Markus
Priority: Minor
When configuring recovery via ConfigurationBuilder, calling .transaction().recovery() will by default enable recovery, so no need to call enable().
But when calling e.g. globalJmxStatistics() in GlobalConfigurationBuilder, you have to explicitly call enable(). Another example is when configuring L1 cache, e.g. l1().lifespan(60000L), you also have to explicitly call enable().
I think it would be nice to have it consistent.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (ISPN-3537) Custom interceptor with Position.LAST set programmatically doesn't work
by Jiří Holuša (JIRA)
Jiří Holuša created ISPN-3537:
---------------------------------
Summary: Custom interceptor with Position.LAST set programmatically doesn't work
Key: ISPN-3537
URL: https://issues.jboss.org/browse/ISPN-3537
Project: Infinispan
Issue Type: Bug
Components: Configuration
Affects Versions: 6.0.0.Beta1
Reporter: Jiří Holuša
Assignee: Mircea Markus
When configuring cache programmatically, adding a custom interceptor with position set to Position.LAST cause not calling this interceptor.
Code sample:
{code:borderStyle=solid}
EmbeddedCacheManager manager = new DefaultCacheManager();
Configuration c2 = new ConfigurationBuilder()
.customInterceptors()
.addInterceptor() .position(InterceptorConfiguration.Position.LAST).interceptor(new MyInterceptor())
.build();
manager.defineConfiguration("interceptors", c2);
Cache<String, String> cache = manager.getCache("interceptors");
cache.put("hello", "world");
{code}
MyInterceptor is very simple, reacting to all events. When changing to Position.FIRST, everything works fine. Also tried two/three interceptors, various combinations, but always with same result - when position set to Position.LAST, interceptors is not called.
Note that no problem when setting by index().
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (ISPN-3345) CachePutInterceptorTest does not always close cache managers
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3345?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-3345:
-----------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2091
> CachePutInterceptorTest does not always close cache managers
> ------------------------------------------------------------
>
> Key: ISPN-3345
> URL: https://issues.jboss.org/browse/ISPN-3345
> Project: Infinispan
> Issue Type: Bug
> Components: CDI integration
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Labels: testsuite_stability
> Fix For: 6.0.0.Final
>
>
> Sometimes CDI's CachePutInterceptorTest fails to close all cache managers:
> {code}
> [16:39:06][org.infinispan:infinispan-cdi] [testng-CachePutInterceptorTest] Test putWithCacheKeyGenerator(org.infinispan.cdi.test.interceptor.CachePutInterceptorTest) succeeded.
> [16:39:06][org.infinispan:infinispan-cdi] Test suite progress: tests succeeded: 29, failed: 0, skipped: 0.
> [16:39:07][org.infinispan:infinispan-cdi] [testng-CachePutInterceptorTest] Test testCachePut(org.infinispan.cdi.test.interceptor.CachePutInterceptorTest) succeeded.
> [16:39:07][org.infinispan:infinispan-cdi] Test suite progress: tests succeeded: 30, failed: 0, skipped: 0.
> [16:39:07][org.infinispan:infinispan-cdi] [testng-CachePutInterceptorTest] Test testCachePutBeforeInvocation(org.infinispan.cdi.test.interceptor.CachePutInterceptorTest) succeeded.
> [16:39:07][org.infinispan:infinispan-cdi] Test suite progress: tests succeeded: 31, failed: 0, skipped: 0.
> [16:39:07][org.infinispan:infinispan-cdi] [testng-CachePutInterceptorTest] Test testCachePutCacheKeyParam(org.infinispan.cdi.test.interceptor.CachePutInterceptorTest) succeeded.
> [16:39:07][org.infinispan:infinispan-cdi] Test suite progress: tests succeeded: 32, failed: 0, skipped: 0.
> [16:39:07][org.infinispan:infinispan-cdi] [testng-CachePutInterceptorTest] Test testCachePutWithCacheName(org.infinispan.cdi.test.interceptor.CachePutInterceptorTest) succeeded.
> [16:39:07][org.infinispan:infinispan-cdi] Test suite progress: tests succeeded: 33, failed: 0, skipped: 0.
> [16:40:07][org.infinispan:infinispan-cdi]
> [16:40:07][org.infinispan:infinispan-cdi] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> [16:40:07][org.infinispan:infinispan-cdi] !!!!!! (testng-CachePutInterceptorTest) Exiting because CachePutInterceptorTest has NOT shut down all the cache managers it has started !!!!!!!
> [16:40:07][org.infinispan:infinispan-cdi] !!!!!! (testng-CachePutInterceptorTest) The still-running cacheManager was created here: org.infinispan.cdi.AdvancedCacheProducer.getAdvancedCache(AdvancedCacheProducer.java:67) !!!!!!!
> [16:40:07][org.infinispan:infinispan-cdi] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> [16:40:07][org.infinispan:infinispan-cdi] {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (ISPN-3345) CachePutInterceptorTest does not always close cache managers
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3345?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-3345:
-----------------------------------
Fix Version/s: 6.0.0.Beta2
> CachePutInterceptorTest does not always close cache managers
> ------------------------------------------------------------
>
> Key: ISPN-3345
> URL: https://issues.jboss.org/browse/ISPN-3345
> Project: Infinispan
> Issue Type: Bug
> Components: CDI integration
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Labels: testsuite_stability
> Fix For: 6.0.0.Beta2, 6.0.0.Final
>
>
> Sometimes CDI's CachePutInterceptorTest fails to close all cache managers:
> {code}
> [16:39:06][org.infinispan:infinispan-cdi] [testng-CachePutInterceptorTest] Test putWithCacheKeyGenerator(org.infinispan.cdi.test.interceptor.CachePutInterceptorTest) succeeded.
> [16:39:06][org.infinispan:infinispan-cdi] Test suite progress: tests succeeded: 29, failed: 0, skipped: 0.
> [16:39:07][org.infinispan:infinispan-cdi] [testng-CachePutInterceptorTest] Test testCachePut(org.infinispan.cdi.test.interceptor.CachePutInterceptorTest) succeeded.
> [16:39:07][org.infinispan:infinispan-cdi] Test suite progress: tests succeeded: 30, failed: 0, skipped: 0.
> [16:39:07][org.infinispan:infinispan-cdi] [testng-CachePutInterceptorTest] Test testCachePutBeforeInvocation(org.infinispan.cdi.test.interceptor.CachePutInterceptorTest) succeeded.
> [16:39:07][org.infinispan:infinispan-cdi] Test suite progress: tests succeeded: 31, failed: 0, skipped: 0.
> [16:39:07][org.infinispan:infinispan-cdi] [testng-CachePutInterceptorTest] Test testCachePutCacheKeyParam(org.infinispan.cdi.test.interceptor.CachePutInterceptorTest) succeeded.
> [16:39:07][org.infinispan:infinispan-cdi] Test suite progress: tests succeeded: 32, failed: 0, skipped: 0.
> [16:39:07][org.infinispan:infinispan-cdi] [testng-CachePutInterceptorTest] Test testCachePutWithCacheName(org.infinispan.cdi.test.interceptor.CachePutInterceptorTest) succeeded.
> [16:39:07][org.infinispan:infinispan-cdi] Test suite progress: tests succeeded: 33, failed: 0, skipped: 0.
> [16:40:07][org.infinispan:infinispan-cdi]
> [16:40:07][org.infinispan:infinispan-cdi] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> [16:40:07][org.infinispan:infinispan-cdi] !!!!!! (testng-CachePutInterceptorTest) Exiting because CachePutInterceptorTest has NOT shut down all the cache managers it has started !!!!!!!
> [16:40:07][org.infinispan:infinispan-cdi] !!!!!! (testng-CachePutInterceptorTest) The still-running cacheManager was created here: org.infinispan.cdi.AdvancedCacheProducer.getAdvancedCache(AdvancedCacheProducer.java:67) !!!!!!!
> [16:40:07][org.infinispan:infinispan-cdi] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> [16:40:07][org.infinispan:infinispan-cdi] {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (ISPN-3330) Hotrod clients getWithMetadata doesn't work when locking isolation != NONE
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3330?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3330:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 987524|https://bugzilla.redhat.com/show_bug.cgi?id=987524] from ASSIGNED to ON_QA
> Hotrod clients getWithMetadata doesn't work when locking isolation != NONE
> --------------------------------------------------------------------------
>
> Key: ISPN-3330
> URL: https://issues.jboss.org/browse/ISPN-3330
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.3.0.Final, 6.0.0.Alpha4
> Reporter: Jakub Markos
> Assignee: Galder Zamarreño
> Priority: Minor
> Fix For: 6.0.0.Beta1, 6.0.0.Final
>
>
> I have a cluster of 2 infinispan servers with this configuration:
> {code:xml}<subsystem xmlns="urn:infinispan:server:core:5.3">
> <cache-container name="default" default-cache="default" listener-executor="infinispan-listener">
> <transport stack="udp" executor="infinispan-transport" lock-timeout="240000"/>
> <distributed-cache name="default" start="EAGER" mode="SYNC" segments="1" owners="2" batching="false" l1-lifespan="0" remote-timeout="60000">
> <locking isolation="REPEATABLE_READ"/>
> </distributed-cache>
> </cache-container>
> </subsystem>{code}
> Running this code:
> {code}remoteCache.put("k1", "v1", 10000000, TimeUnit.MICROSECONDS); // setting only lifespan
> MetadataValue<String> k1 = remoteCache.getWithMetadata("k1");
> assertTrue(k1.getValue().equals("v1"));
> // microseconds converted to seconds
> assertTrue(k1.getLifespan() == 10);
> assertTrue(k1.getMaxIdle() == -1);{code}
> fails with:
> {code}org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[5] returned server error (status=0x85): java.lang.ClassCastException: org.infinispan.container.entries.RepeatableReadEntry can
> not be cast to org.infinispan.container.entries.InternalCacheEntry
> at org.infinispan.client.hotrod.impl.protocol.Codec10.checkForErrorsInResponseStatus(Codec10.java:143)
> at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:99)
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56)
> at org.infinispan.client.hotrod.impl.operations.AbstractKeyOperation.sendKeyOperation(AbstractKeyOperation.java:52)
> at org.infinispan.client.hotrod.impl.operations.GetWithMetadataOperation.executeOperation(GetWithMetadataOperation.java:35)
> at org.infinispan.client.hotrod.impl.operations.GetWithMetadataOperation.executeOperation(GetWithMetadataOperation.java:23)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:46)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.getWithMetadata(RemoteCacheImpl.java:145){code}
> Works with isolation="READ_COMMITED"/"NONE" or with no <locking> at all.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (ISPN-3457) Infinispan error running on IBM JDK
by Luis Montoya (JIRA)
[ https://issues.jboss.org/browse/ISPN-3457?page=com.atlassian.jira.plugin.... ]
Luis Montoya commented on ISPN-3457:
------------------------------------
The required information:
java version "1.6.0"
Java(TM) SE Runtime Environment (build pwa6460_26sr5fp2-20130423_01(SR5 FP2))
IBM J9 VM (build 2.6, JRE 1.6.0 Windows 7 amd64-64 Compressed References 20130419_145740 (JIT enabled, AOT enabled)
J9VM - R26_Java626_SR5_FP2_20130419_1420_B145740
JIT - r11.b03_20130131_32403ifx4
GC - R26_Java626_SR5_FP2_20130419_1420_B145740_CMPRSS
J9CL - 20130419_145740)
JCL - 20130419_01
Something else:
I have been writting a test case in this class org.infinispan.manager.CacheManagerComponentRegistryTest.java:
public void testCreateCacheManagerGlobalConfiguration(){
cm = new DefaultCacheManager(GlobalConfigurationBuilder.defaultClusteredBuilder().build());
}
When I run this lines of code into Eclipse IDE over IBM JDK, it throws the mentioned exception, but if I run them using maven (executing it from the commands line using the same IBM JDK used before), it doesn´t throw the Exception, that's why I have not committed the UT in GitHub
> Infinispan error running on IBM JDK
> -----------------------------------
>
> Key: ISPN-3457
> URL: https://issues.jboss.org/browse/ISPN-3457
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 6.0.0.Alpha3
> Environment: WAS 8.0.0.6 JDK, Windows 7 Professional
> Reporter: Luis Montoya
> Assignee: Mircea Markus
> Fix For: 6.0.0.Alpha3
>
>
> I created a sample application using infinispan on standar JDK (Sun/Oracle). This app works fine using this JDK.
>
> I tried to run the app on IBM JDK (the needed for WAS), but I get the below error:
>
> org.infinispan.commons.CacheException: Unable to construct a GlobalComponentRegistry!
> at org.infinispan.factories.GlobalComponentRegistry.<init>(GlobalComponentRegistry.java:129)
> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:276)
> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:246)
> at org.infinispan.quickstart.clusteredcache.replication.AbstractNode.createCacheManagerProgramatically(AbstractNode.java:41)
> at org.infinispan.quickstart.clusteredcache.replication.AbstractNode.<init>(AbstractNode.java:62)
> at org.infinispan.quickstart.clusteredcache.replication.Node0.main(Node0.java:32)
> Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.topology.LocalTopologyManagerImpl.inject(org.infinispan.remoting.transport.Transport,java.util.concurrent.ExecutorService,org.infinispan.factories.GlobalComponentRegistry,org.infinispan.util.TimeService) on object of type LocalTopologyManagerImpl with parameters [org.infinispan.executors.LazyInitializingExecutorService@96d7b55b, org.infinispan.executors.LazyInitializingExecutorService@96d7b55b, org.infinispan.factories.GlobalComponentRegistry@9fd5a559, org.infinispan.util.DefaultTimeService@725adace]
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:188)
> at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:229)
> at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:65)
> at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:797)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:201)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:156)
> at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:277)
> at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:253)
> at org.infinispan.factories.GlobalComponentRegistry.<init>(GlobalComponentRegistry.java:125)
> ... 5 more
> Caused by: java.lang.IllegalArgumentException: discrepancia en el tipo de argumento
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:600)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
> ... 13 more
>
>
> It seems that a method which is being invoked through reflection is receiving incorrectly the first parameter, which should be a org.infinispan.remoting.transport.Transport instance, but it is receiving a org.infinispan.executors.LazyInitializingExecutorService@96d7b55b instance
>
> The code which launch the error is the next:
>
>
> new DefaultCacheManager(
> GlobalConfigurationBuilder.defaultClusteredBuilder().globalJmxStatistics().allowDuplicateDomains(true)
> .transport().addProperty("configurationFile", "jgroups.xml")
> .build(),
> new ConfigurationBuilder()
> .clustering().cacheMode(CacheMode.REPL_SYNC)
> .build()
> );
> Making a review and debug of the code, the next behavior was seen which produce the error:
> if a map called map contains something like this {1=some.class.type}, and you try to get a value using the 0 as the key ( map.get(0), it doens't return null rather it returns the value for the 1 key, it means, for map.get(0) it returns "some.class.type", as if map.get(1) was called)
> Also, when the contains method of Map interface is called ( map.contains(0)), it returns true, which is incorrect because the map only has the 1 key
> This behavior is happening on this class and method:
> class: org.infinispan.factories.components.ComponentMetadata$InjectMetadata
> methods: getParameterName, isParameterNameSet
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months