April 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4208) Regression: storeAsBinary causes RemoteCache to return a MarshalledValue rather than the cached object.

by Mark K (JIRA)

[ https://issues.jboss.org/browse/ISPN-4208?page=com.atlassian.jira.plugin.... ] Mark K closed ISPN-4208. ------------------------ Resolution: Cannot Reproduce Bug My bad. I had not updated another dependency jar which caused this test to pass with 6.0.0.Final. This is not a regression. I'll post on the forums to find out what the deal is with MarshalledValue being returned. > Regression: storeAsBinary causes RemoteCache to return a MarshalledValue rather than the cached object. > ------------------------------------------------------------------------------------------------------- > > Key: ISPN-4208 > URL: https://issues.jboss.org/browse/ISPN-4208 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 6.0.2.Final > Reporter: Mark K > Assignee: Galder Zamarreño > Priority: Blocker > > This is a regression from Infinispan 6.0.0.Final. > When using the storeAsBinary setting on a cache, RemoteCache.get() method returns a MarshalledValue rather than the actual cached object. > When I revert back to 6.0.0.Final, the problem does not exist. > The following exception occurs: > {code:title=Bar.java|borderStyle=solid} > ERROR 0410-16:51:45:904 Error interpreting supplied block {ecobee.communicator.util.EcobeeConsole.interpret} [main]({}) > org.mozilla.javascript.WrappedException: Wrapped java.lang.ClassCastException: org.infinispan.marshall.core.MarshalledValue cannot be cast to com.ecobee.foundation.model.thermostat.Thermostat (<cmd>#2) > at org.mozilla.javascript.Context.throwAsScriptRuntimeEx(Context.java:1757) > at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:170) > at org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:243) > at org.mozilla.javascript.optimizer.OptRuntime.call1(OptRuntime.java:66) > at org.mozilla.javascript.gen.c3._c0(<cmd>:2) > at org.mozilla.javERROR 0410-16:51:45:904 Error interpreting supplied block {ecobee.communicator.util.EcobeeConsole.interpret} [main]({}) > org.mozilla.javascript.WrappedException: Wrapped java.lang.ClassCastException: org.infinispan.marshall.core.MarshalledValue cannot be cast to com.ecobee.foundation.model.thermostat.Thermostat (<cmd>#2) > at org.mozilla.javascript.Context.throwAsScriptRuntimeEx(Context.java:1757) > at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:170) > at org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:243) > at org.mozilla.javascript.optimizer.OptRuntime.call1(OptRuntime.java:66) > at org.mozilla.javascript.gen.c3._c0(<cmd>:2) > at org.mozilla.javascript.gen.c3.call(<cmd>) > at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:393) > at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:2834) > at org.mozilla.javascript.gen.c3.call(<cmd>) > at org.mozilla.javascript.gen.c3.exec(<cmd>) > at org.mozilla.javascript.Context.evaluateString(Context.java:1196) > at com.ecobee.communicator.util.EcobeeConsole.interpret(EcobeeConsole.java:148) > at com.ecobee.communicator.util.EcobeeConsole.console(EcobeeConsole.java:102) > at com.ecobee.communicator.Administrator.main(Administrator.java:69) > Caused by: java.lang.ClassCastException: org.infinispan.marshall.core.MarshalledValue cannot be cast to com.ecobee.foundation.model.thermostat.Thermostat > at com.ecobee.foundation.dao.cluster.impl.ClusterCacheThermostatDao.getThermostat(ClusterCacheThermostatDao.java:66) > 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.mozilla.javascript.MemberBox.invoke(MemberBox.java:155) > ... 12 more > nullascript.gen.c3.call(<cmd>) > at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:393) > at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:2834) > at org.mozilla.javascript.gen.c3.call(<cmd>) > at org.mozilla.javascript.gen.c3.exec(<cmd>) > at org.mozilla.javascript.Context.evaluateString(Context.java:1196) > at com.ecobee.communicator.util.EcobeeConsole.interpret(EcobeeConsole.java:148) > at com.ecobee.communicator.util.EcobeeConsole.console(EcobeeConsole.java:102) > at com.ecobee.communicator.Administrator.main(Administrator.java:69) > Caused by: java.lang.ClassCastException: org.infinispan.marshall.core.MarshalledValue cannot be cast to com.ecobee.foundation.model.thermostat.Thermostat > at com.ecobee.foundation.dao.cluster.impl.ClusterCacheThermostatDao.getThermostat(ClusterCacheThermostatDao.java:66) > 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.mozilla.javascript.MemberBox.invoke(MemberBox.java:155) > ... 12 more > null > {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, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4208) Regression: storeAsBinary causes RemoteCache to return a MarshalledValue rather than the cached object.

by Mark K (JIRA)

Mark K created ISPN-4208: ---------------------------- Summary: Regression: storeAsBinary causes RemoteCache to return a MarshalledValue rather than the cached object. Key: ISPN-4208 URL: https://issues.jboss.org/browse/ISPN-4208 Project: Infinispan Issue Type: Bug Components: Remote Protocols Affects Versions: 6.0.2.Final Reporter: Mark K Assignee: Galder Zamarreño Priority: Blocker This is a regression from Infinispan 6.0.0.Final. When using the storeAsBinary setting on a cache, RemoteCache.get() method returns a MarshalledValue rather than the actual cached object. When I revert back to 6.0.0.Final, the problem does not exist. The following exception occurs: {code:title=Bar.java|borderStyle=solid} ERROR 0410-16:51:45:904 Error interpreting supplied block {ecobee.communicator.util.EcobeeConsole.interpret} [main]({}) org.mozilla.javascript.WrappedException: Wrapped java.lang.ClassCastException: org.infinispan.marshall.core.MarshalledValue cannot be cast to com.ecobee.foundation.model.thermostat.Thermostat (<cmd>#2) at org.mozilla.javascript.Context.throwAsScriptRuntimeEx(Context.java:1757) at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:170) at org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:243) at org.mozilla.javascript.optimizer.OptRuntime.call1(OptRuntime.java:66) at org.mozilla.javascript.gen.c3._c0(<cmd>:2) at org.mozilla.javERROR 0410-16:51:45:904 Error interpreting supplied block {ecobee.communicator.util.EcobeeConsole.interpret} [main]({}) org.mozilla.javascript.WrappedException: Wrapped java.lang.ClassCastException: org.infinispan.marshall.core.MarshalledValue cannot be cast to com.ecobee.foundation.model.thermostat.Thermostat (<cmd>#2) at org.mozilla.javascript.Context.throwAsScriptRuntimeEx(Context.java:1757) at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:170) at org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:243) at org.mozilla.javascript.optimizer.OptRuntime.call1(OptRuntime.java:66) at org.mozilla.javascript.gen.c3._c0(<cmd>:2) at org.mozilla.javascript.gen.c3.call(<cmd>) at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:393) at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:2834) at org.mozilla.javascript.gen.c3.call(<cmd>) at org.mozilla.javascript.gen.c3.exec(<cmd>) at org.mozilla.javascript.Context.evaluateString(Context.java:1196) at com.ecobee.communicator.util.EcobeeConsole.interpret(EcobeeConsole.java:148) at com.ecobee.communicator.util.EcobeeConsole.console(EcobeeConsole.java:102) at com.ecobee.communicator.Administrator.main(Administrator.java:69) Caused by: java.lang.ClassCastException: org.infinispan.marshall.core.MarshalledValue cannot be cast to com.ecobee.foundation.model.thermostat.Thermostat at com.ecobee.foundation.dao.cluster.impl.ClusterCacheThermostatDao.getThermostat(ClusterCacheThermostatDao.java:66) 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.mozilla.javascript.MemberBox.invoke(MemberBox.java:155) ... 12 more nullascript.gen.c3.call(<cmd>) at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:393) at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:2834) at org.mozilla.javascript.gen.c3.call(<cmd>) at org.mozilla.javascript.gen.c3.exec(<cmd>) at org.mozilla.javascript.Context.evaluateString(Context.java:1196) at com.ecobee.communicator.util.EcobeeConsole.interpret(EcobeeConsole.java:148) at com.ecobee.communicator.util.EcobeeConsole.console(EcobeeConsole.java:102) at com.ecobee.communicator.Administrator.main(Administrator.java:69) Caused by: java.lang.ClassCastException: org.infinispan.marshall.core.MarshalledValue cannot be cast to com.ecobee.foundation.model.thermostat.Thermostat at com.ecobee.foundation.dao.cluster.impl.ClusterCacheThermostatDao.getThermostat(ClusterCacheThermostatDao.java:66) 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.mozilla.javascript.MemberBox.invoke(MemberBox.java:155) ... 12 more null {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, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4204) Sync distexec demo project with current test code

by Alan Field (JIRA)

[ https://issues.jboss.org/browse/ISPN-4204?page=com.atlassian.jira.plugin.... ] Alan Field updated ISPN-4204: ----------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2501 > Sync distexec demo project with current test code > ------------------------------------------------- > > Key: ISPN-4204 > URL: https://issues.jboss.org/browse/ISPN-4204 > Project: Infinispan > Issue Type: Enhancement > Components: Distributed Execution and Map/Reduce > Affects Versions: 6.0.2.Final, 7.0.0.Alpha3 > Reporter: Alan Field > Assignee: Alan Field > > Add a no argument constructor to WordCountCollator > Add a new distributed executor that performs a regular expression search of the values in the cache -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4207) Lock container ignores key Equivalence

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4207?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4207: ------------------------------ Description: AbstractPerEntryLockContainer uses an EquivalentConcurrentHashMapV8 to map keys to lock. It can create issues when the key is a byte array. edit: the Stripped*LockContainer suffers from the same problem since it uses object.hashCode(). was:AbstractPerEntryLockContainer uses an EquivalentConcurrentHashMapV8 to map keys to lock. It can create issues when the key is a byte array. > Lock container ignores key Equivalence > -------------------------------------- > > Key: ISPN-4207 > URL: https://issues.jboss.org/browse/ISPN-4207 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Alpha3 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 7.0.0.Alpha4 > > > AbstractPerEntryLockContainer uses an EquivalentConcurrentHashMapV8 to map keys to lock. It can create issues when the key is a byte array. > edit: the Stripped*LockContainer suffers from the same problem since it uses object.hashCode(). -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4207) Lock container ignores key Equivalence

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4207?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4207: ------------------------------ Summary: Lock container ignores key Equivalence (was: Per entry lock container ignores key equivalence) > Lock container ignores key Equivalence > -------------------------------------- > > Key: ISPN-4207 > URL: https://issues.jboss.org/browse/ISPN-4207 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Alpha3 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 7.0.0.Alpha4 > > > AbstractPerEntryLockContainer uses an EquivalentConcurrentHashMapV8 to map keys to lock. It can create issues when the key is a byte array. -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4199) Server logs that databaseType is ignored, when it's really not

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4199?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4199: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1086158|https://bugzilla.redhat.com/show_bug.cgi?id=1086158] from NEW to POST > Server logs that databaseType is ignored, when it's really not > -------------------------------------------------------------- > > Key: ISPN-4199 > URL: https://issues.jboss.org/browse/ISPN-4199 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores, Server > Reporter: Jakub Markos > Assignee: Dan Berindei > > In current snapshot, when you configure the databaseType property for the jdbc cache store, server logs: > {code} > 11:10:21,088 WARN [org.infinispan.configuration.parsing.XmlConfigHelper] (ServerService Thread Pool -- 18) ISPN000282: Unrecognized attribute databaseType. Please check your configuration. Ignoring!! > {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, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4199) Server logs that databaseType is ignored, when it's really not

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-4199?page=com.atlassian.jira.plugin.... ] Martin Gencur resolved ISPN-4199. --------------------------------- Resolution: Duplicate Issue Duplicates https://issues.jboss.org/browse/ISPN-4100 > Server logs that databaseType is ignored, when it's really not > -------------------------------------------------------------- > > Key: ISPN-4199 > URL: https://issues.jboss.org/browse/ISPN-4199 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores, Server > Reporter: Jakub Markos > Assignee: Dan Berindei > > In current snapshot, when you configure the databaseType property for the jdbc cache store, server logs: > {code} > 11:10:21,088 WARN [org.infinispan.configuration.parsing.XmlConfigHelper] (ServerService Thread Pool -- 18) ISPN000282: Unrecognized attribute databaseType. Please check your configuration. Ignoring!! > {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, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4199) Server logs that databaseType is ignored, when it's really not

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-4199?page=com.atlassian.jira.plugin.... ] Martin Gencur commented on ISPN-4199: ------------------------------------- For upstream, this issue is already tracked by https://issues.jboss.org/browse/ISPN-4100. > Server logs that databaseType is ignored, when it's really not > -------------------------------------------------------------- > > Key: ISPN-4199 > URL: https://issues.jboss.org/browse/ISPN-4199 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores, Server > Reporter: Jakub Markos > Assignee: Dan Berindei > > In current snapshot, when you configure the databaseType property for the jdbc cache store, server logs: > {code} > 11:10:21,088 WARN [org.infinispan.configuration.parsing.XmlConfigHelper] (ServerService Thread Pool -- 18) ISPN000282: Unrecognized attribute databaseType. Please check your configuration. Ignoring!! > {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, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4207) Per entry lock container ignores key equivalence

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-4207: --------------------------------- Summary: Per entry lock container ignores key equivalence Key: ISPN-4207 URL: https://issues.jboss.org/browse/ISPN-4207 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 7.0.0.Alpha3 Reporter: Pedro Ruivo Assignee: Pedro Ruivo Fix For: 7.0.0.Alpha4 AbstractPerEntryLockContainer uses an EquivalentConcurrentHashMapV8 to map keys to lock. It can create issues when the key is a byte array. -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4207) Per entry lock container ignores key equivalence

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4207?page=com.atlassian.jira.plugin.... ] Work on ISPN-4207 started by Pedro Ruivo. > Per entry lock container ignores key equivalence > ------------------------------------------------ > > Key: ISPN-4207 > URL: https://issues.jboss.org/browse/ISPN-4207 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Alpha3 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 7.0.0.Alpha4 > > > AbstractPerEntryLockContainer uses an EquivalentConcurrentHashMapV8 to map keys to lock. It can create issues when the key is a byte array. -- 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, 12 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 April 2014