November 2013 - infinispan-issues

[JBoss JIRA] (ISPN-3714) No need to wrap ClassLoaders in WeakReference in invocationContext implementations

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-3714?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-3714: ---------------------------------- Priority: Minor (was: Major) > No need to wrap ClassLoaders in WeakReference in invocationContext implementations > ---------------------------------------------------------------------------------- > > Key: ISPN-3714 > URL: https://issues.jboss.org/browse/ISPN-3714 > Project: Infinispan > Issue Type: Bug > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Minor > Fix For: 6.0.0.CR2, 6.0.0.Final > > > AbstractInvocationContext is having a reference to the ClassLoader but uses a weak reference. > Besides not being needed and being an unnecessary object allocation, I think it could also be dangerous if the CL "vanishes" during an in-flight operation which should be using it. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3714) No need to wrap ClassLoaders in WeakReference in invocationContext implementations

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-3714?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-3714: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2226 > No need to wrap ClassLoaders in WeakReference in invocationContext implementations > ---------------------------------------------------------------------------------- > > Key: ISPN-3714 > URL: https://issues.jboss.org/browse/ISPN-3714 > Project: Infinispan > Issue Type: Enhancement > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 6.0.0.CR2, 6.0.0.Final > > > AbstractInvocationContext is having a reference to the ClassLoader but uses a weak reference. > Besides not being needed and being an unnecessary object allocation, I think it could also be dangerous if the CL "vanishes" during an in-flight operation which should be using it. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3714) No need to wrap ClassLoaders in WeakReference in invocationContext implementations

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-3714?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-3714: ---------------------------------- Issue Type: Bug (was: Enhancement) > No need to wrap ClassLoaders in WeakReference in invocationContext implementations > ---------------------------------------------------------------------------------- > > Key: ISPN-3714 > URL: https://issues.jboss.org/browse/ISPN-3714 > Project: Infinispan > Issue Type: Bug > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 6.0.0.CR2, 6.0.0.Final > > > AbstractInvocationContext is having a reference to the ClassLoader but uses a weak reference. > Besides not being needed and being an unnecessary object allocation, I think it could also be dangerous if the CL "vanishes" during an in-flight operation which should be using it. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3715) SingleKeyNonTxInvocationContext is not using the provided KeyEquivalence

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-3715: ------------------------------------- Summary: SingleKeyNonTxInvocationContext is not using the provided KeyEquivalence Key: ISPN-3715 URL: https://issues.jboss.org/browse/ISPN-3715 Project: Infinispan Issue Type: Bug Components: Core API Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 6.0.0.CR2, 6.0.0.Final -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3714) No need to wrap ClassLoaders in WeakReference in invocationContext implementations

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-3714?page=com.atlassian.jira.plugin.... ] Sanne Grinovero reassigned ISPN-3714: ------------------------------------- Assignee: Sanne Grinovero (was: Mircea Markus) > No need to wrap ClassLoaders in WeakReference in invocationContext implementations > ---------------------------------------------------------------------------------- > > Key: ISPN-3714 > URL: https://issues.jboss.org/browse/ISPN-3714 > Project: Infinispan > Issue Type: Enhancement > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 6.0.0.CR2, 6.0.0.Final > > > AbstractInvocationContext is having a reference to the ClassLoader but uses a weak reference. > Besides not being needed and being an unnecessary object allocation, I think it could also be dangerous if the CL "vanishes" during an in-flight operation which should be using it. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3714) No need to wrap ClassLoaders in WeakReference in invocationContext implementations

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-3714: ------------------------------------- Summary: No need to wrap ClassLoaders in WeakReference in invocationContext implementations Key: ISPN-3714 URL: https://issues.jboss.org/browse/ISPN-3714 Project: Infinispan Issue Type: Enhancement Reporter: Sanne Grinovero Assignee: Mircea Markus Fix For: 6.0.0.CR2, 6.0.0.Final AbstractInvocationContext is having a reference to the ClassLoader but uses a weak reference. Besides not being needed and being an unnecessary object allocation, I think it could also be dangerous if the CL "vanishes" during an in-flight operation which should be using it. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2999) getCacheEntry not working when distribution gets go remote

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2999?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2999: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > getCacheEntry not working when distribution gets go remote > ---------------------------------------------------------- > > Key: ISPN-2999 > URL: https://issues.jboss.org/browse/ISPN-2999 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.5.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Critical > Labels: 620 > Fix For: 6.0.0.Final > > > Assuming the cache contains byte[], you get this exception when calling getCacheEntry(K) for a key not available locally: > {code}org.infinispan.server.hotrod.HotRodException: java.lang.ClassCastException: [B cannot be cast to org.infinispan.container.entries.CacheEntry > at org.infinispan.server.hotrod.HotRodDecoder.createServerException(HotRodDecoder.scala:216) > at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:79) > at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:49) > at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:500) > at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:435) > at org.infinispan.server.core.AbstractProtocolDecoder.messageReceived(AbstractProtocolDecoder.scala:393) > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) > at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88) > at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:107) > at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:313) > at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:88) > at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) > at java.lang.Thread.run(Thread.java:680) > Caused by: java.lang.ClassCastException: [B cannot be cast to org.infinispan.container.entries.CacheEntry > at org.infinispan.CacheImpl.getCacheEntry(CacheImpl.java:299) > at org.infinispan.CacheImpl.getCacheEntry(CacheImpl.java:304) > at org.infinispan.server.core.AbstractProtocolDecoder.get(AbstractProtocolDecoder.scala:287) > at org.infinispan.server.core.AbstractProtocolDecoder.decodeKey(AbstractProtocolDecoder.scala:117) > at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:73) > ... 14 more{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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3712) HotRod Rolling Upgrades from Delirium 5.2.4 to latest server needs dropped org.infinispan.util.ByteArrayKey

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3712?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3712: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2225, https://github.com/infinispan/infinispan-server/pull/188 > HotRod Rolling Upgrades from Delirium 5.2.4 to latest server needs dropped org.infinispan.util.ByteArrayKey > ----------------------------------------------------------------------------------------------------------- > > Key: ISPN-3712 > URL: https://issues.jboss.org/browse/ISPN-3712 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.CR1 > Environment: Processing HotRod rolling upgrades from source Infinispan 'Delirium' 5.2.4.Final-redhat-1 server to the latest Infinispan 'Infinium' 6.0.0-SNAPSHOT. Using old standalone.xml for source node and examples/standalone-hotrod-rolling-upgrade.xml for new target server. > Reporter: Tomas Sykora > Assignee: Mircea Markus > Fix For: 6.0.0.Final > > > When it is running from 6.0.0-SNAPSHOT to 6.0.0-SNAPSHOT it is ok. It looks like some back-porting compatibility issue. > See stacktrace: > javax.management.MBeanException > at org.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:273) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) > at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791) > at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:527) > at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:263) > at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:915) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:152) > 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: java.lang.reflect.InvocationTargetException > 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:601) > at org.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:271) > ... 9 more > Caused by: org.infinispan.commons.CacheException: java.lang.ClassNotFoundException: org.infinispan.util.ByteArrayKey from [Module "org.infinispan:main" from local module loader @4099a992 (finder: local module finder @284bd160 (roots: /home/tsykora/programs/eclipseWorkspace/Infinispan-server-tsykora/infinispan-server/testsuite/target/server/node1/modules,/home/tsykora/programs/eclipseWorkspace/Infinispan-server-tsykora/infinispan-server/testsuite/target/server/node1/modules/system/layers/base))] > at org.infinispan.persistence.remote.upgrade.HotRodTargetMigrator.synchronizeData(HotRodTargetMigrator.java:63) > at org.infinispan.upgrade.RollingUpgradeManager.synchronizeData(RollingUpgradeManager.java:59) > ... 14 more > Caused by: java.lang.ClassNotFoundException: org.infinispan.util.ByteArrayKey from [Module "org.infinispan:main" from local module loader @4099a992 (finder: local module finder @284bd160 (roots: /home/tsykora/programs/eclipseWorkspace/Infinispan-server-tsykora/infinispan-server/testsuite/target/server/node1/modules,/home/tsykora/programs/eclipseWorkspace/Infinispan-server-tsykora/infinispan-server/testsuite/target/server/node1/modules/system/layers/base))] > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:264) > at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135) > at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:947) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1259) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadCollectionObject(RiverUnmarshaller.java:184) > at org.jboss.marshalling.river.RiverUnmarshaller.readCollectionData(RiverUnmarshaller.java:777) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:656) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213) > at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37) > at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:140) > at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromByteBuffer(AbstractJBossMarshaller.java:118) > at org.infinispan.commons.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:82) > at org.infinispan.persistence.remote.upgrade.HotRodTargetMigrator.synchronizeData(HotRodTargetMigrator.java:61) > ... 15 more -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3614) Add remote query quick start/demo

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3614?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-3614: ------------------------------------- in order for the CPP client to be able to read an object written by the java client the following enhancement is require on the CPP client side: https://issues.jboss.org/browse/HRCPP-85 > Add remote query quick start/demo > --------------------------------- > > Key: ISPN-3614 > URL: https://issues.jboss.org/browse/ISPN-3614 > Project: Infinispan > Issue Type: Task > Reporter: Mircea Markus > Assignee: Adrian Nistor > Fix For: 6.0.0.CR2 > > > Should describe how the users: > - download the servers > - configure it (indexing ...) > - with sample domain model, how to write the marshallers, define the indexes using the RHQ plugin > - some code that connects to the server, adds and queries the data (mvn module?) -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3315) Retry remote get after topology change if all the targets are no longer owners

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3315?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3315: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Retry remote get after topology change if all the targets are no longer owners > ------------------------------------------------------------------------------ > > Key: ISPN-3315 > URL: https://issues.jboss.org/browse/ISPN-3315 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.3.0.Final > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Priority: Critical > Labels: 620 > Fix For: 6.0.0.CR2, 6.0.0.Final > > > It's possible for a remote get to reach its intended targets only after they are no longer owners, and they don't have the key anymore. If that happens, instead of returning a {{null}} value, the originator should retry on the new owners (possibly in a loop). > Note that this is different from all the owners leaving the cluster at the same time: in that case retrying on the new owners wouldn't make a difference, because data would be lost anyway. -- 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, 5 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 November 2013