[JBoss JIRA] Created: (ISPN-1066) Partition merges when using topology hintscan cause null pointers and leave the system in an unstable state
by Manik Surtani (JIRA)
Partition merges when using topology hintscan cause null pointers and leave the system in an unstable state
-----------------------------------------------------------------------------------------------------------
Key: ISPN-1066
URL: https://issues.jboss.org/browse/ISPN-1066
Project: Infinispan
Issue Type: Bug
Components: Distributed Cache
Affects Versions: 5.0.0.BETA2, 4.2.1.FINAL
Reporter: Manik Surtani
Assignee: Manik Surtani
Priority: Critical
Fix For: 4.2.2.BETA1, 5.0.0.CR1, 5.0.0.FINAL
Due to a missing null check in MergeTask, and the way TopologyInfo instances are dealt with (inconsistently) in DistributionManagerImpl and ConsistentHash implementations.
In this scenario, seen on the joining node:
{code}
Caused by: java.lang.NullPointerException
at org.infinispan.distribution.DistributionManagerImpl.informRehashOnJoin(DistributionManagerImpl.java:475)
at org.infinispan.commands.control.RehashControlCommand.perform(RehashControlCommand.java:134)
at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:145)
at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithWaitForBlocks(InboundInvocationHandlerImpl.java:159)
at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithRetry(InboundInvocationHandlerImpl.java:249)
at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:131)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:159)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:144)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:577)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:488)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:364)
{code}
and on the coordinator:
{code}
Caused by: java.lang.NullPointerException
at org.infinispan.distribution.DistributionManagerImpl.rehash(DistributionManagerImpl.java:283)
at org.infinispan.distribution.DistributionManagerImpl$ViewChangeListener.handleViewChange(DistributionManagerImpl.java:563)
at sun.reflect.GeneratedMethodAccessor482.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:175)
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] Created: (ISPN-1060) Avoid errors when starting from a 4.x configuration mentioning lazyDeserialization
by Sanne Grinovero (JIRA)
Avoid errors when starting from a 4.x configuration mentioning lazyDeserialization
----------------------------------------------------------------------------------
Key: ISPN-1060
URL: https://issues.jboss.org/browse/ISPN-1060
Project: Infinispan
Issue Type: Feature Request
Components: Configuration
Affects Versions: 5.0.0.BETA2
Reporter: Sanne Grinovero
Assignee: Vladimir Blagojevic
Priority: Optional
Fix For: 5.0.0.CR1
The configuration element lazyDeserialization was renamed to storeAsBinary, and the programmatic configuration is able to deal with it via deprecation.
When starting a CacheManager v.5b2 on such an older XML configuration mentioning the old attribute, Infinispan fails to start.
It would be very nice to be able to maintain backwards compatibility, or in alternative to make sure the error message is very clear.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] Created: (ISPN-792) Migrate to David's JBoss Logging
by Galder Zamarreño (JIRA)
Migrate to David's JBoss Logging
--------------------------------
Key: ISPN-792
URL: https://jira.jboss.org/browse/ISPN-792
Project: Infinispan
Issue Type: Feature Request
Reporter: Galder Zamarreño
Assignee: Manik Surtani
Based on what David Lloyd said in the AS7 podcast, it performs much better than log4j and in particular, when it comes to log level checks (it apparently uses volatile int checks).
This could have a direct impact on the Infinispan performance since we do a fair few level checks.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] Created: (ISPN-1045) Python client should have dictionary-like syntactic sugar
by Manik Surtani (JIRA)
Python client should have dictionary-like syntactic sugar
---------------------------------------------------------
Key: ISPN-1045
URL: https://issues.jboss.org/browse/ISPN-1045
Project: Infinispan
Issue Type: Enhancement
Components: Hot Rod Client - Python
Affects Versions: 4.2.1.FINAL
Reporter: Manik Surtani
Assignee: Manik Surtani
Fix For: 4.2.2.BETA1
The Python Cache class uses Java Map-style put(), get(), remove() and contains(). Which is fine, but we should also offer Python-style syntactic sugar, so that we can do:
{code}
cache['key'] = 'value'
print cache['key']
if 'key' in cache:
print 'Key exists!'
for e in cache:
print e
{code}
etc. Have a look at the implementation of a Python map for more details, or one of the many custom map-like classes available for Python.
This is usually implemented by defining internal methods, such as:
{code}
def __getitem__(self, key):
return self.get(key)
def __setitem__(self, key, value):
self.put(key, value)
{code}
etc.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] Created: (ISPN-1053) Rename lazyDeserialization to storeAsBinary
by Manik Surtani (JIRA)
Rename lazyDeserialization to storeAsBinary
-------------------------------------------
Key: ISPN-1053
URL: https://issues.jboss.org/browse/ISPN-1053
Project: Infinispan
Issue Type: Task
Components: Marshalling
Affects Versions: 4.2.1.FINAL
Reporter: Manik Surtani
Assignee: Manik Surtani
Priority: Minor
Fix For: 5.0.0.BETA2, 5.0.0.FINAL
The old LazyDeserialization option should be deprecated. The name LazyDeserialization is incorrect, since the usage and implication of storing objects as binary are far greater than simply deserializing something lazily on replication. The primary use case here is class loader isolation, and in addition it benefits persistent cache stores as well even in a single node environment where there is no RPC going on.
Hence a more descriptive name.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months