[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
11 years, 1 month
[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
11 years, 1 month
[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
11 years, 1 month
[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
11 years, 1 month
[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
11 years, 1 month
[JBoss JIRA] (ISPN-3316) CDI Cache interceptor tests are failing while running in EAP container
by Divya Mehra (JIRA)
[ https://issues.jboss.org/browse/ISPN-3316?page=com.atlassian.jira.plugin.... ]
Divya Mehra updated ISPN-3316:
------------------------------
Labels: 620 (was: jdg620_dm jdg62GAblocker)
> CDI Cache interceptor tests are failing while running in EAP container
> ----------------------------------------------------------------------
>
> Key: ISPN-3316
> URL: https://issues.jboss.org/browse/ISPN-3316
> Project: Infinispan
> Issue Type: Bug
> Components: CDI integration
> Affects Versions: 5.3.0.Final
> Reporter: Anna Manukyan
> Assignee: Mircea Markus
> Labels: 620
>
> While migration of the CDI related tests to work under EAP container (at the moment using 6.0.GA), it was found that the tests related to interceptors are failing. The issue relates to
> org.infinispan.cdi.test.interceptor.CachePutInterceptorTest, org.infinispan.cdi.test.interceptor.CacheRemoveAllInterceptorTest, org.infinispan.cdi.test.interceptor.CacheRemoveInterceptorTest, org.infinispan.cdi.test.interceptor.CacheResultInterceptorTest.
> The failure relates to assertions. The thing is that all actions which are done using javax.cache.cache-api annotations, work properly (I've added some logs e.g. in CachePutInterceptor, and it shows that the data is put to the cache properly).
> But later when the test wants to verify that the data is really put to the data, retrieves the cache from the injected CacheContainer, the cache is empty - the data is not there.
> The issue appeared since the latest changes to the Infinispan-CDI module, and split to infinispan-jcache module. For the previous version, the tests are passed under EAP container.
> The example above was given for the CachePutInterceptorTest, but the same refers to the rest of them.
> The git repo for the sources, will be provided later.
--
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, 1 month