November 2013 - infinispan-issues

[JBoss JIRA] (ISPN-3396) Multiple classloader key store/lookup fails, even with storeAsBinary

by Divya Mehra (JIRA)

[ https://issues.jboss.org/browse/ISPN-3396?page=com.atlassian.jira.plugin.... ] Divya Mehra updated ISPN-3396: ------------------------------ Labels: dm (was: jdg620_dm) > Multiple classloader key store/lookup fails, even with storeAsBinary > -------------------------------------------------------------------- > > Key: ISPN-3396 > URL: https://issues.jboss.org/browse/ISPN-3396 > Project: Infinispan > Issue Type: Bug > Components: Marshalling > Affects Versions: 5.3.0.Final, 6.0.0.Alpha2 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Labels: dm > > Same key, multiple classloaders. Storing from one classloader cannot be found from the other, even when storeAsBinary is enabled (even with defensive=true). [IRC chat debugging issue|https://gist.github.com/galderz/63163644fee0c27d66c7]. -- 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

12 years

1
0
0 / 0

[JBoss JIRA] (ISPN-3468) ClassCastException in map-reduce with unfamiliar key type, some cache stores and storeAsBinary

by Divya Mehra (JIRA)

[ https://issues.jboss.org/browse/ISPN-3468?page=com.atlassian.jira.plugin.... ] Divya Mehra updated ISPN-3468: ------------------------------ Labels: dm (was: jdg620_dm) > ClassCastException in map-reduce with unfamiliar key type, some cache stores and storeAsBinary > ---------------------------------------------------------------------------------------------- > > Key: ISPN-3468 > URL: https://issues.jboss.org/browse/ISPN-3468 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 5.3.0.Final > Reporter: Krzysztof Sobolewski > Assignee: Mircea Markus > Labels: dm > Attachments: 0001-core-add-BaseCacheStoreFunctionalTest.testMapReduceS.patch > > > The conditions needed to replicate: > 1) storeAsBinary enabled for keys > 2) a cache store that marshals keys directly, e.g. any BucketBasedCacheStore (I'm using JdbcBinaryCacheStore) > 3) a key type that is unfamiliar to MarshalledValue.isTypeExcluded(Class<?>) > If these are satisfied, then map-reduce fails with an exception like this: > org.infinispan.CacheException: java.util.concurrent.ExecutionException: java.lang.ClassCastException: org.infinispan.marshall.MarshalledValue cannot be cast to com.example.UnfamiliarKeyType > at com.example.TestMapper.map(TestMapper.java:11) ~[?:?] > at org.infinispan.distexec.mapreduce.MapReduceManagerImpl.map(MapReduceManagerImpl.java:216) ~[?:?] > at org.infinispan.distexec.mapreduce.MapReduceManagerImpl.mapAndCombineForLocalReduction(MapReduceManagerImpl.java:103) ~[?:?] > at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart.invokeMapCombineLocallyForLocalReduction(MapReduceTask.java:977) ~[?:?] > at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart.access$300(MapReduceTask.java:916) ~[?:?] > at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart$2.call(MapReduceTask.java:948) ~[?:?] > at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart$2.call(MapReduceTask.java:944) ~[?:?] > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) ~[?:1.6.0_45] > at java.util.concurrent.FutureTask.run(FutureTask.java:138) ~[?:1.6.0_45] > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439) ~[?:1.6.0_45] > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) ~[?:1.6.0_45] > at java.util.concurrent.FutureTask.run(FutureTask.java:138) ~[?:1.6.0_45] > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) ~[?:1.6.0_45] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) ~[?:1.6.0_45] -- 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

12 years

1
0
0 / 0

[JBoss JIRA] (ISPN-3602) Cache statistics update differently in library and Client-Server mode

by Divya Mehra (JIRA)

[ https://issues.jboss.org/browse/ISPN-3602?page=com.atlassian.jira.plugin.... ] Divya Mehra updated ISPN-3602: ------------------------------ Labels: dm (was: jdg620_dm) > Cache statistics update differently in library and Client-Server mode > --------------------------------------------------------------------- > > Key: ISPN-3602 > URL: https://issues.jboss.org/browse/ISPN-3602 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 6.0.0.CR1 > Reporter: Jiří Holuša > Assignee: Mircea Markus > Priority: Minor > Labels: dm > > When running jdg quickstart carmart ( https://github.com/infinispan/jdg-quickstart/tree/master/carmart ) I noticed interesting thing. > When calling replace() in library mode, the number of stores in cache statistics doesn't change whereas when calling in Client-Server mode, the number of stores increase by 1. > I went deeper into the code and I found out that in CacheMgmtInterceptor, where there are implemented methods for such statistics updates (like for put() ), there isn't implemented method for updating stats for replace() method, so the control flow is just passed. > I think it should be consistent, but I don't know which approach is intended, if either increase by 1 or leave it the same. > If increase is the answer than the solution is simple, implement CacheMgmtInterceptor.visitReplaceCommand(...) the same way as e.g. visitPutKeyValueCommand. -- 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

12 years

1
0
0 / 0

[JBoss JIRA] (ISPN-3667) Existing cacher stores should be generic types

by Divya Mehra (JIRA)

[ https://issues.jboss.org/browse/ISPN-3667?page=com.atlassian.jira.plugin.... ] Divya Mehra updated ISPN-3667: ------------------------------ Labels: dm (was: jdg620_dm) > Existing cacher stores should be generic types > ---------------------------------------------- > > Key: ISPN-3667 > URL: https://issues.jboss.org/browse/ISPN-3667 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.0.CR1 > Reporter: Mircea Markus > Assignee: Mircea Markus > Labels: dm > Fix For: 6.0.0.CR2 > > -- 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

12 years

1
0
0 / 0

[JBoss JIRA] (ISPN-3558) PutForExternalRead won't work after a clear(), when both in same tx

by Divya Mehra (JIRA)

[ https://issues.jboss.org/browse/ISPN-3558?page=com.atlassian.jira.plugin.... ] Divya Mehra updated ISPN-3558: ------------------------------ Labels: dm (was: jdg620_dm) > PutForExternalRead won't work after a clear(), when both in same tx > ------------------------------------------------------------------- > > Key: ISPN-3558 > URL: https://issues.jboss.org/browse/ISPN-3558 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.3.0.Final, 6.0.0.Beta1 > Reporter: Galder Zamarreño > Assignee: William Burns > Priority: Blocker > Labels: dm > Fix For: 6.0.0.Final > > > {code} > public void testPutForExternalReadAfterClear() throws Exception { > cache.put(1, "v1"); > tm().begin(); > try { > cache.getAdvancedCache().clear(); > cache.putForExternalRead(1, "v1"); > assertEquals("v1", cache.get(1)); > } finally { > tm().commit(); > } > } > {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

12 years

1
0
0 / 0

[JBoss JIRA] (ISPN-3339) Jon plugin, two deprecated ops are failing. [RpcManager] [Transaction]

by Divya Mehra (JIRA)

[ https://issues.jboss.org/browse/ISPN-3339?page=com.atlassian.jira.plugin.... ] Divya Mehra updated ISPN-3339: ------------------------------ Labels: dm (was: jdg620_dm) > Jon plugin, two deprecated ops are failing. [RpcManager] [Transaction] > ---------------------------------------------------------------------- > > Key: ISPN-3339 > URL: https://issues.jboss.org/browse/ISPN-3339 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Environment: Local machine, Fedora16 > Reporter: Tomas Sykora > Assignee: Mircea Markus > Labels: dm > > These 2 operations are failing using infinispan-rhq-plugin: > [Transactions] Enable/disable statistics. Deprecated, use the statisticsEnabled attribute instead. > [RpcManager] Enable/disable statistics. Deprecated, use the statisticsEnabled attribute instead. > While this is deprecated, should we remove it from plugin? Should we replace it by different operation? > Typical error stack trace: > org.mc4j.ems.connection.EmsInvocationException: Exception on invocation of [setStatisticsEnabled]javax.management.MBeanException > at org.mc4j.ems.impl.jmx.connection.bean.operation.DOperation.invoke(DOperation.java:126) > at org.infinispan.rhq.CacheComponent.invokeOperation(CacheComponent.java:192) > at sun.reflect.GeneratedMethodAccessor129.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:634) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > Caused by: javax.management.MBeanException > at org.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:271) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836) > at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761) > at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:498) > at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:246) > at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1427) > at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72) > at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265) > at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1360) > at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788) > at sun.reflect.GeneratedMethodAccessor118.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:303) > at sun.rmi.transport.Transport$1.run(Transport.java:159) > at java.security.AccessController.doPrivileged(Native Method) > at sun.rmi.transport.Transport.serviceCall(Transport.java:155) > at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) > at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) > at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:273) > at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:251) > at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:160) > at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source) > at javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke(Unknown Source) > at javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.invoke(RMIConnector.java:1017) > at sun.reflect.GeneratedMethodAccessor131.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.mc4j.ems.impl.jmx.connection.support.providers.proxy.JMXRemotingMBeanServerProxy.invoke(JMXRemotingMBeanServerProxy.java:59) > at $Proxy110.invoke(Unknown Source) > at org.mc4j.ems.impl.jmx.connection.bean.operation.DOperation.invoke(DOperation.java:110) > ... 10 more > Caused by: java.lang.IllegalArgumentException: argument type mismatch > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:269) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836) > at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761) > at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:498) > at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:246) > at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1427) > at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72) > at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265) > at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1360) > at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788) > at sun.reflect.GeneratedMethodAccessor118.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:303) > at sun.rmi.transport.Transport$1.run(Transport.java:159) > at java.security.AccessController.doPrivileged(Native Method) > at sun.rmi.transport.Transport.serviceCall(Transport.java:155) > at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) > at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) > at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) -- 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

12 years

1
0
0 / 0

[JBoss JIRA] (ISPN-3532) AsyncStore has only one live AsyncStoreProcessor (thread) in one time

by Divya Mehra (JIRA)

[ https://issues.jboss.org/browse/ISPN-3532?page=com.atlassian.jira.plugin.... ] Divya Mehra updated ISPN-3532: ------------------------------ Labels: dm (was: jdg620_dm) > AsyncStore has only one live AsyncStoreProcessor (thread) in one time > --------------------------------------------------------------------- > > Key: ISPN-3532 > URL: https://issues.jboss.org/browse/ISPN-3532 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 5.3.0.Final, 6.0.0.Beta1 > Reporter: Laszlo Hadadi > Assignee: Mircea Markus > Labels: dm > > AsyncStore cache modifications processed asynchronously only on one thread in one time. -- 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

12 years

1
0
0 / 0

[JBoss JIRA] (ISPN-3462) Unable to add custom interceptors declaratively to server config

by Divya Mehra (JIRA)

[ https://issues.jboss.org/browse/ISPN-3462?page=com.atlassian.jira.plugin.... ] Divya Mehra updated ISPN-3462: ------------------------------ Labels: dm (was: jdg620_dm) > Unable to add custom interceptors declaratively to server config > ---------------------------------------------------------------- > > Key: ISPN-3462 > URL: https://issues.jboss.org/browse/ISPN-3462 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 5.3.0.Final > Reporter: Riad Mohammed > Assignee: Tristan Tarrant > Labels: dm > > Per Tristan Tarrant, creating jira ticket: > I've upgraded from Infinispan 5.2.5 to Infinispan server 5.3 and it looks like the configuration file (urn:infinispan:server:core:5.3) doesn't support declaring custom interceptors as jboss-infinispan-core_5_3.xsd does not have the necessary elements. [I did try just adding the custom interceptor elements and got a parse error]. -- 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

12 years

1
0
0 / 0

[JBoss JIRA] (ISPN-3585) The CDI module dependency on core and hotrod client should be optional

by Divya Mehra (JIRA)

[ https://issues.jboss.org/browse/ISPN-3585?page=com.atlassian.jira.plugin.... ] Divya Mehra updated ISPN-3585: ------------------------------ Labels: dm (was: jdg620_dm) > The CDI module dependency on core and hotrod client should be optional > ---------------------------------------------------------------------- > > Key: ISPN-3585 > URL: https://issues.jboss.org/browse/ISPN-3585 > Project: Infinispan > Issue Type: Bug > Components: CDI integration > Affects Versions: 6.0.0.Beta2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Critical > Labels: dm > Fix For: 6.0.0.Final > > > The CDI module Extension has a hard dependency on both core and remote. We need to refactor the code so that the two dependencies are optional and features are enabled only when found in classpath -- 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

12 years

1
0
0 / 0

[JBoss JIRA] (ISPN-3454) Hot Rod client doesn't retry operation on RemoteException

by Divya Mehra (JIRA)

[ https://issues.jboss.org/browse/ISPN-3454?page=com.atlassian.jira.plugin.... ] Divya Mehra updated ISPN-3454: ------------------------------ Labels: 620 (was: jdg62GAblocker) > Hot Rod client doesn't retry operation on RemoteException > --------------------------------------------------------- > > Key: ISPN-3454 > URL: https://issues.jboss.org/browse/ISPN-3454 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.Alpha3 > Reporter: Michal Linhard > Assignee: Galder Zamarreño > Priority: Critical > Labels: 620 > Fix For: 6.0.0.CR2, 6.0.0.Final > > > This is a client-side problem. > In a resilience test with 4 nodes where 1 is killed, I'm getting a lot of these: > {code} > 08:30:55,198 ERROR [org.jboss.smartfrog.jdg.loaddriver.DriverThread] (DriverThread-369) Error doing: PUT key399869 to node node04, took 493 ms > org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[821188] returned server error (status=0x85): org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node01/default, see cause for remote stack trace > 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.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:50) > at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:30) > at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:19) > at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:46) > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:209) > at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79) > at org.jboss.qa.jdg.adapter.Infinispan60Adapter$HotRodRemoteCacheAdapter.put(Infinispan60Adapter.java:269) > at org.jboss.smartfrog.jdg.loaddriver.DriverThreadImpl.makeRequest(DriverThreadImpl.java:265) > at org.jboss.smartfrog.jdg.loaddriver.DriverThreadImpl.run(DriverThreadImpl.java:378) > {code} > Isn't this a recoverable problem that shouldn't be left to user to handle ? > source: > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/RESILIENCE... -- 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

12 years

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2013