[JBoss JIRA] (ISPN-2590) In case of Errors/Warns/Exceptions include cache name into log/message
by Thomas Fromm (JIRA)
Thomas Fromm created ISPN-2590:
----------------------------------
Summary: In case of Errors/Warns/Exceptions include cache name into log/message
Key: ISPN-2590
URL: https://issues.jboss.org/browse/ISPN-2590
Project: Infinispan
Issue Type: Enhancement
Components: Locking and Concurrency
Affects Versions: 5.2.0.Beta5
Reporter: Thomas Fromm
Assignee: Mircea Markus
When having lots of caches in use and its not always possible to determine the used cache based upon cache key, it would be very useful to have the related cache name inside logs/messages.
For example:
ERROR 05.12.12 20:09:40,589 [OOB-160,IBIS-32523] InvocationContextInterceptor ISPN000136: Execution error
org.infinispan.util.concurrent.TimeoutException: Could not acquire lock on CacheKey{name='Mux234935827442390'} on behalf of transaction GlobalTransaction:<IBIS-15651>:10696:remote. Lock
is being held by null
--
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 month
[JBoss JIRA] (ISPN-2589) NPE in InvalidateL1Command
by Thomas Fromm (JIRA)
Thomas Fromm created ISPN-2589:
----------------------------------
Summary: NPE in InvalidateL1Command
Key: ISPN-2589
URL: https://issues.jboss.org/browse/ISPN-2589
Project: Infinispan
Issue Type: Bug
Components: Core API
Affects Versions: 5.2.0.Beta5
Reporter: Thomas Fromm
Assignee: Mircea Markus
The used cache is an REPL_SYNC one w/o L1 and Optimistic TX.
Can't provide unit test, just saw it in my logs.
WARN 05.12.12 20:08:22,746 [OOB-173,IBIS-2147] CacheTopologyControlCommand ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=MODULE_PROPERTIES_VERSION, type=CH_UPDATE, sender=IBIS-57850, joinInfo=null, topologyId=14, currentCH=ReplicatedConsistentHash{members=[IBIS-57850, IBIS-15651, IBIS-14611, IBIS-7942, IBIS-4256, IBIS-25472, IBIS-32523]}, pendingCH=null, throwable=null, viewId=8}
java.lang.NullPointerException
at org.infinispan.commands.write.InvalidateL1Command.perform(InvalidateL1Command.java:109)
at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:110)
at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:141)
at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:141)
at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:141)
at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at org.infinispan.interceptors.CacheLoaderInterceptor.visitInvalidateCommand(CacheLoaderInterceptor.java:127)
at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:211)
at org.infinispan.interceptors.EntryWrappingInterceptor.visitInvalidateL1Command(EntryWrappingInterceptor.java:143)
at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitInvalidateL1Command(AbstractLockingInterceptor.java:99)
at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:141)
at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:256)
at org.infinispan.interceptors.TxInterceptor.visitInvalidateCommand(TxInterceptor.java:224)
at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at org.infinispan.statetransfer.StateTransferInterceptor.visitInvalidateL1Command(StateTransferInterceptor.java:172)
at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:141)
at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:128)
at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:92)
at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:141)
at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:343)
at org.infinispan.statetransfer.StateConsumerImpl.invalidateSegments(StateConsumerImpl.java:592)
at org.infinispan.statetransfer.StateConsumerImpl.onTopologyUpdate(StateConsumerImpl.java:239)
at org.infinispan.statetransfer.StateTransferManagerImpl.doTopologyUpdate(StateTransferManagerImpl.java:191)
at org.infinispan.statetransfer.StateTransferManagerImpl.access$000(StateTransferManagerImpl.java:58)
at org.infinispan.statetransfer.StateTransferManagerImpl$1.updateConsistentHash(StateTransferManagerImpl.java:117)
at org.infinispan.topology.LocalTopologyManagerImpl.handleConsistentHashUpdate(LocalTopologyManagerImpl.java:194)
at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:165)
at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:137)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:252)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:219)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:483)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:390)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:248)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:598)
at org.jgroups.JChannel.up(JChannel.java:703)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
at org.jgroups.protocols.RSVP.up(RSVP.java:172)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
at org.jgroups.protocols.FC.up(FC.java:479)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:896)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:432)
at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:721)
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:574)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:187)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
at org.jgroups.protocols.MERGE3.up(MERGE3.java:290)
at org.jgroups.protocols.Discovery.up(Discovery.java:359)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1287)
at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1850)
at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1823)
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)
--
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 month
[JBoss JIRA] (ISPN-2553) JBossMarshaller can be used before properly initialized
by Radim Vansa (JIRA)
Radim Vansa created ISPN-2553:
---------------------------------
Summary: JBossMarshaller can be used before properly initialized
Key: ISPN-2553
URL: https://issues.jboss.org/browse/ISPN-2553
Project: Infinispan
Issue Type: Bug
Components: Marshalling
Affects Versions: 5.2.0.Beta4
Reporter: Radim Vansa
Assignee: Galder Zamarreño
The {{JBossMarshaller}} can be used before its {{start()}} method is called. I've noticed that with replicated cache without transactions, an OOB thread can start demarshalling {{SingleRpcCommand}} in {{CacheRpcCommandExternalizer}} but when it tries to create a new unmarshaller (through {{AbstractJBossMarshaller.startObjectInput(...)}} and the {{marshallerTL.initialValue()}} the {{baseCfg}} configuration is not fully initialized yet and this results in creating marshallers in {{PerThreadInstanceHolder}} with {{objectTable == null}}. Then, objects are deserialized to {{null}}.
I have verified this by inserting some log messages into constructors and start method:
{code}
19:49:02,404 INFO [org.infinispan.marshall.jboss.AbstractJBossMarshaller] (pool-1-thread-1) Creating AbstractJBossMarshaller with org.jboss.marshalling.MarshallingConfiguration@1d296aa3: classExternalizerFactor
y=<org.infinispan.marshall.jboss.SerializeWithExtFactory@a18024a> exceptionListener=<null> instanceCount=16 classCount=8 bufferSize=512 version=3
19:49:02,409 INFO [org.infinispan.marshall.jboss.AbstractJBossMarshaller] (pool-1-thread-1) Creating JBossMarshaller org.infinispan.marshall.jboss.JBossMarshaller@2e3e4d73
19:49:02,410 INFO [org.infinispan.marshall.jboss.AbstractJBossMarshaller] (pool-1-thread-1) Starting JBossMarshaller
{code}
and into the thread-local initialization and to {{getUnmarshaller()}} just before {{factory.createUnmarshaller}}:
{code}
19:49:02,410 ERROR [org.infinispan.marshall.jboss.AbstractJBossMarshaller] (OOB-49,rvansa-22965) No object table in org.jboss.marshalling.MarshallingConfiguration@7c4ed0bc: classExternalizerFactory=<org.infinisp
an.marshall.jboss.SerializeWithExtFactory@a18024a> exceptionListener=<null> instanceCount=16 classCount=8 bufferSize=512 version=3, base is org.jboss.marshalling.MarshallingConfiguration@1d296aa3: classExternali
zerFactory=<org.infinispan.marshall.jboss.SerializeWithExtFactory@a18024a> exceptionListener=<null> instanceCount=16 classCount=8 bufferSize=512 version=3
19:49:02,453 ERROR [org.infinispan.marshall.jboss.AbstractJBossMarshaller] (OOB-49,rvansa-22965) Unmarshaller with cfg org.jboss.marshalling.MarshallingConfiguration@7c4ed0bc: classExternalizerFactory=<org.infin
ispan.marshall.jboss.SerializeWithExtFactory@a18024a> exceptionListener=<null> instanceCount=16 classCount=8 bufferSize=512 version=3
{code}
See that the timestamps for {{start()}} and thread-local initialization are same, and the base configuration ({{baseCfg}}) does not have {{objectTable}} initialized.
--
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 month
[JBoss JIRA] (ISPN-2368) Two rebalances in parallel
by Radim Vansa (JIRA)
Radim Vansa created ISPN-2368:
---------------------------------
Summary: Two rebalances in parallel
Key: ISPN-2368
URL: https://issues.jboss.org/browse/ISPN-2368
Project: Infinispan
Issue Type: Bug
Components: State transfer
Affects Versions: 5.2.0.Beta1
Reporter: Radim Vansa
Assignee: Mircea Markus
There is a bug in ClusterTopologyManagerImpl on line 353: the reference to cache topology is obtained prior to entering to the synchronized block, causing that two rebalances can start in parallel, effectively broking the state transfer.
--
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 month
[JBoss JIRA] (ISPN-2352) Second invocation of ClusteredQueryImpl.lazyIterator() yields results in reverse order
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2352?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-2352:
-----------------------------------
Fix Version/s: 5.2.0.Beta6
(was: 5.2.0.CR1)
> Second invocation of ClusteredQueryImpl.lazyIterator() yields results in reverse order
> --------------------------------------------------------------------------------------
>
> Key: ISPN-2352
> URL: https://issues.jboss.org/browse/ISPN-2352
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Affects Versions: 5.1.8.Final, 5.2.0.Alpha4
> Reporter: Marko Lukša
> Assignee: Galder Zamarreño
> Priority: Minor
> Fix For: 5.2.0.Beta6, 5.2.0.Final
>
>
> When you invoke lazyIterator() for the 2nd time on the same ClusteredQueryImpl instance, the iterator returns results in reverse order. This only occurs when the query has a Sort specified.
> Caused by DistributedIterator.setTopDocs(), which inverts the reverse flag on SortField.
> The same is probably also true for ClusteredQueryImpl.iterator()
--
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 month
[JBoss JIRA] (ISPN-1855) Accessing a non-distributed cache from a RemoteCacheManager can break topology updates
by Dan Berindei (JIRA)
Dan Berindei created ISPN-1855:
----------------------------------
Summary: Accessing a non-distributed cache from a RemoteCacheManager can break topology updates
Key: ISPN-1855
URL: https://issues.jboss.org/browse/ISPN-1855
Project: Infinispan
Issue Type: Bug
Affects Versions: 5.1.1.FINAL
Reporter: Dan Berindei
Assignee: Manik Surtani
Fix For: 5.2.0.FINAL
RemoteCacheManager uses a single consistent hash to map requests to different servers, but caches on the server may have different CHs (or even no CH if the cache is not in distributed mode).
If the first request goes to a on-distributed cache, the client will never request an updated CH and so it will use a round robin strategy for routing request to all the caches. Obviously this is not optimal for distributed caches.
Each distributed cache can also have different members since 5.1, so it would be best if we kept a separate CH per cache on the client.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (ISPN-1583) AbstractDelegatingAdvancedCache with(ClassLoader), withFlags(Flag...) logic is broken
by Paul Ferraro (Created) (JIRA)
AbstractDelegatingAdvancedCache with(ClassLoader), withFlags(Flag...) logic is broken
-------------------------------------------------------------------------------------
Key: ISPN-1583
URL: https://issues.jboss.org/browse/ISPN-1583
Project: Infinispan
Issue Type: Bug
Components: Core API
Affects Versions: 5.1.0.BETA5
Reporter: Paul Ferraro
Assignee: Manik Surtani
Priority: Critical
When the withFlags(...) logic was modified to use a DecoratedCache instead of thread-local storage, any caches already decorated with the AbstractDelegatingAdvancedCache(...) broke.
Take the following code:
AdvancedCache<K, V> baseCache;
AdvancedCache<K, V> customCache = new AbstractDelegatingAdvancedCache<K, V>(baseCache) {
public void clear() {
// custom clear logic
}
};
customCache.withFlags(Flag.CACHE_MODE_LOCAL).clear();
In the above statement, the flag is not applied.
The call to withFlags(...) returns a reference to customCache, and the reference to DecoratedCache containing the flags is lost to garbage collection.
In the case of with(ClassLoader) we have the opposite problem.
customCache.with(customClassLoader).clear();
In the above statement, the native clear() method is invoked instead of my custom clear() method. with(ClassLoader) returns a reference to DecoratedCache. The clear() method then operates on baseCache, instead of decoratedCache.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (ISPN-2559) Util.loadClass() swallows certain types of exceptions
by Manik Surtani (JIRA)
Manik Surtani created ISPN-2559:
-----------------------------------
Summary: Util.loadClass() swallows certain types of exceptions
Key: ISPN-2559
URL: https://issues.jboss.org/browse/ISPN-2559
Project: Infinispan
Issue Type: Bug
Components: Core API
Affects Versions: 5.1.8.Final, 5.2.0.Beta4
Reporter: Manik Surtani
Assignee: Manik Surtani
Priority: Minor
Fix For: 5.2.0.CR1, 5.2.0.Final, 5.1.9.Final
Util.loadClassStrict re-wraps NoClassDefFoundErrors as ClassNotFoundExceptions. This is fine, since it is a fatal exception anyway, but it should at least log details out to enable debugging.
--
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 month