Remote Hot Rod events wiki updated
by Galder Zamarreño
Hi all,
I’ve finally managed to get around to updating the remote hot rod event design wiki [1].
The biggest changes are related to piggybacking on the cluster listeners functionality in order to for registration/deregistration of listeners and handling failure scenarios. This should simplify the actual implementation on the Hot Rod side.
Based on feedback, I’ve also changed some of the class names so that it’s clearer what’s client side and what’s server side.
A very important change is the fact that source id information has gone. This is primarily because near-cache like implementations cannot make assumptions on what to store in the near caches when the client invokes operations. Such implementations need to act purely on the events received.
Finally, a filter/converter plugging mechanism will be done via factory implementations, which provide more flexibility on the way filter/converter instances are created. This opens the possibility for filter/converter factory parameters to be added to the protocol and passed, after unmarshalling, to the factory callbacks (this is not included right now).
I hope to get started on this in the next few days, so feedback at this point is crucial to get a solid first release.
Cheers,
[1] https://github.com/infinispan/infinispan/wiki/Remote-Hot-Rod-Events
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
9 years, 12 months
help with Caused by: java.lang.ClassCastException: org.infinispan.context.impl.NonTxInvocationContext cannot be cast to org.infinispan.context.impl.TxInvocationContext
by tudor
Hi all,
Maybe someone had this issue before or it can point me in the right
direction.
I have an env of two Wildfly 8.0.0 Final servers, with Infinispan in
cluster used as second level cache provider for hibernate.
No changes to the default configurations both in Infinispan and also in
hibernate.
Any update or delete on the cache identities fail from the entity
invalidation cache.
Thanks,
Tudor.
Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received
exception from app2/hibernate, see cause for remote stack trace
at
org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:41)
at
org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:362)
at
org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:167)
at
org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:521)
at
org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:281)
at
org.infinispan.interceptors.InvalidationInterceptor.visitClearCommand(InvalidationInterceptor.java:100)
at
org.infinispan.commands.write.ClearCommand.acceptVisitor(ClearCommand.java:38)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at
org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:321)
at
org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForClear(EntryWrappingInterceptor.java:370)
at
org.infinispan.interceptors.EntryWrappingInterceptor.visitClearCommand(EntryWrappingInterceptor.java:146)
at
org.infinispan.commands.write.ClearCommand.acceptVisitor(ClearCommand.java:38)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at
org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitClearCommand(PessimisticLockingInterceptor.java:197)
at
org.infinispan.commands.write.ClearCommand.acceptVisitor(ClearCommand.java:38)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at
org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
at
org.infinispan.commands.AbstractVisitor.visitClearCommand(AbstractVisitor.java:47)
at
org.infinispan.commands.write.ClearCommand.acceptVisitor(ClearCommand.java:38)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at
org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:255)
at
org.infinispan.interceptors.TxInterceptor.visitClearCommand(TxInterceptor.java:206)
at
org.infinispan.commands.write.ClearCommand.acceptVisitor(ClearCommand.java:38)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at
org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
at
org.infinispan.commands.AbstractVisitor.visitClearCommand(AbstractVisitor.java:47)
at
org.infinispan.commands.write.ClearCommand.acceptVisitor(ClearCommand.java:38)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at
org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
at
org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73)
at
org.infinispan.commands.AbstractVisitor.visitClearCommand(AbstractVisitor.java:47)
at
org.infinispan.commands.write.ClearCommand.acceptVisitor(ClearCommand.java:38)
at
org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
at
org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1306)
at org.infinispan.CacheImpl.clearInternal(CacheImpl.java:443)
at org.infinispan.CacheImpl.clear(CacheImpl.java:438)
at org.infinispan.CacheImpl.clear(CacheImpl.java:433)
at
org.infinispan.AbstractDelegatingCache.clear(AbstractDelegatingCache.java:291)
at
org.hibernate.cache.infinispan.access.TransactionalAccessDelegate.removeAll(TransactionalAccessDelegate.java:223)
[hibernate-infinispan-4.3.1.Final.jar:4.3.1.Final]
at
org.hibernate.cache.infinispan.entity.TransactionalAccess.removeAll(TransactionalAccess.java:84)
[hibernate-infinispan-4.3.1.Final.jar:4.3.1.Final]
at
org.hibernate.action.internal.BulkOperationCleanupAction$EntityCleanup.<init>(BulkOperationCleanupAction.java:227)
[hibernate-core-4.3.1.Final.jar:4.3.1.Final]
at
org.hibernate.action.internal.BulkOperationCleanupAction$EntityCleanup.<init>(BulkOperationCleanupAction.java:220)
[hibernate-core-4.3.1.Final.jar:4.3.1.Final]
at
org.hibernate.action.internal.BulkOperationCleanupAction.<init>(BulkOperationCleanupAction.java:82)
[hibernate-core-4.3.1.Final.jar:4.3.1.Final]
at
org.hibernate.hql.internal.ast.exec.BasicExecutor.doExecute(BasicExecutor.java:83)
[hibernate-core-4.3.1.Final.jar:4.3.1.Final]
at
org.hibernate.hql.internal.ast.exec.BasicExecutor.execute(BasicExecutor.java:78)
[hibernate-core-4.3.1.Final.jar:4.3.1.Final]
at
org.hibernate.hql.internal.ast.exec.DeleteExecutor.execute(DeleteExecutor.java:125)
[hibernate-core-4.3.1.Final.jar:4.3.1.Final]
at
org.hibernate.hql.internal.ast.QueryTranslatorImpl.executeUpdate(QueryTranslatorImpl.java:445)
[hibernate-core-4.3.1.Final.jar:4.3.1.Final]
at
org.hibernate.engine.query.spi.HQLQueryPlan.performExecuteUpdate(HQLQueryPlan.java:347)
[hibernate-core-4.3.1.Final.jar:4.3.1.Final]
at
org.hibernate.internal.SessionImpl.executeUpdate(SessionImpl.java:1282)
[hibernate-core-4.3.1.Final.jar:4.3.1.Final]
at
org.hibernate.internal.QueryImpl.executeUpdate(QueryImpl.java:118)
[hibernate-core-4.3.1.Final.jar:4.3.1.Final]
at
org.hibernate.jpa.internal.QueryImpl.internalExecuteUpdate(QueryImpl.java:371)
[hibernate-entitymanager-4.3.1.Final.jar:4.3.1.Final]
at
org.hibernate.jpa.spi.AbstractQueryImpl.executeUpdate(AbstractQueryImpl.java:78)
[hibernate-entitymanager-4.3.1.Final.jar:4.3.1.Final]
at
com.ubicabs.manager.PolygonManager.deleteAllPoints(PolygonManager.java:110)
[classes:]
at
com.ubicabs.manager.PolygonManager.updatePolygonPoints(PolygonManager.java:78)
[classes:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[rt.jar:1.7.0_51]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[rt.jar:1.7.0_51]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[rt.jar:1.7.0_51]
at java.lang.reflect.Method.invoke(Method.java:606)
[rt.jar:1.7.0_51]
at
org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at
org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
at
org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at
org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
at
org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
[wildfly-weld-8.0.0.Final.jar:8.0.0.Final]
at
org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
[wildfly-weld-8.0.0.Final.jar:8.0.0.Final]
at
org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at
org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
at
org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at
org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
[wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at
org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
[wildfly-jpa-8.0.0.Final.jar:8.0.0.Final]
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at
org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
at
org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46)
[weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
at
org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
[wildfly-weld-8.0.0.Final.jar:8.0.0.Final]
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at
org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
[wildfly-ee-8.0.0.Final.jar:8.0.0.Final]
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at
org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at
org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at
org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at
org.jboss.as.ejb3.component.interceptors.NonPooledEJBComponentInstanceAssociatingInterceptor.processInvocation(NonPooledEJBComponentInstanceAssociatingInterceptor.java:59)
[wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at
org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251)
[wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
... 218 more
Caused by: java.lang.ClassCastException:
org.infinispan.context.impl.NonTxInvocationContext cannot be cast to
org.infinispan.context.impl.TxInvocationContext
at
org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitClearCommand(PessimisticLockingInterceptor.java:194)
at
org.infinispan.commands.write.ClearCommand.acceptVisitor(ClearCommand.java:38)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at
org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
at
org.infinispan.commands.AbstractVisitor.visitClearCommand(AbstractVisitor.java:47)
at
org.infinispan.commands.write.ClearCommand.acceptVisitor(ClearCommand.java:38)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at
org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:255)
at
org.infinispan.interceptors.TxInterceptor.visitClearCommand(TxInterceptor.java:206)
at
org.infinispan.commands.write.ClearCommand.acceptVisitor(ClearCommand.java:38)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at
org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
at
org.infinispan.commands.AbstractVisitor.visitClearCommand(AbstractVisitor.java:47)
at
org.infinispan.commands.write.ClearCommand.acceptVisitor(ClearCommand.java:38)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at
org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
at
org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73)
at
org.infinispan.commands.AbstractVisitor.visitClearCommand(AbstractVisitor.java:47)
at
org.infinispan.commands.write.ClearCommand.acceptVisitor(ClearCommand.java:38)
at
org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
at
org.infinispan.commands.remote.BaseRpcInvokingCommand.processVisitableCommand(BaseRpcInvokingCommand.java:39)
at
org.infinispan.commands.remote.SingleRpcCommand.perform(SingleRpcCommand.java:48)
at
org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:95)
at
org.infinispan.remoting.InboundInvocationHandlerImpl.access$000(InboundInvocationHandlerImpl.java:50)
at
org.infinispan.remoting.InboundInvocationHandlerImpl$2.run(InboundInvocationHandlerImpl.java:172)
... 3 more
9 years, 12 months
New API to iterate over current entries in cache
by William Burns
While working on ISPN-4068 to add the current state to listeners that
were added I found that what I essentially needed was a way to iterate
over the entries of the cache. I am thinking of adding this to the
public API available on the AdvancedCache interface.
I wanted to get your guy's opinions if you don't think we should add
it or any changes you might suggest.
My thought was to add 2 overloaded methods:
<C> Iterator<Map.Entry<K, C>> entryIterator(KeyValueFilter<? super K,
? super V> filter, Converter<? super K, ? super V, C> converter);
and
Iterator<Map.Entry<K, V>> entryIterator(KeyValueFilter<? super K, ?
super V> filter);
The method would return almost immediately after invocation and the
iterator would queue entries and block as entries are required to be
returned. The filter and converter are applied on each of the remote
nodes and are required to be serializable or have an externalizer
registered.
Internally the iterator would use chunking to help prevent memory
saturation. The max memory usage would be (chunkSize * N) + local
entries where N is the number of nodes.
These methods would be different than other methods on the
Cache/AdvancedCache in the following things:
1. This operation is treated as nontx and thus won't store them into
the context and thus repeatable read semantics would not be
guaranteed. This doesn't preclude manually adding values to the
context. Also prior writes in the current context would be ignored
(current data returned), although this could be changed if desired.
2. Values are not activated from loaders and visited listeners would
not be notified of access. The latter could be sensibly changed if
desired.
- Will
10 years
Infinispan Test language level to Java 8?
by Galder Zamarreño
Hi all,
Just thinking out loud: what about we start using JDK8+ for all the test code in Infinispan?
The production code would still have language level 6/7 (whatever is required…).
This way we start getting ourselves familiar with JDK8 in a safe environment and we reduce some of the boiler plate code currently existing in the tests.
This would only problematic for anyone consuming our test jars. They’d need move up to JDK8+ along with us.
Thoughts?
p.s. Recently I found https://leanpub.com/whatsnewinjava8/read which provides a great overview on what’s new in JDK8 along with small code samples.
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
10 years
ABI compatibility of C++ client
by Radim Vansa
Hi guys,
as I've tried to get rid of all the warnings emitted in Windows build of
C++ HotRod client, I've noticed that the ABI of this library is not very
well designed.
I am not an expert for this kind of stuff, but many sources I've found
say that exporting STL containers (such as string or vector, or
shared_ptr) is not ABI-safe.
For windows, the STL export is allowed [1] when both library and user
application is linked against the same version of CRT. I am really not
sure whether we want to force it to the user, and moreover, due to bug
in VC10 implementation of STL [2] we can't explicitly export shared_ptr
(I haven't found any workaround for that so far).
Regarding the GCC-world, situation is not better. The usual response for
exporting STL classes is "don't do that". It is expected that these
trouble will be addressed in C++17 (huh :)).
What can we do about that? Fixing this requires a lot of changes in
API... can we afford to do that now? Or will we just declare "compile
with the same versions and compile options as we did"? (we should state
them, then)
I have only limited knowledge of the whole C++ ecosystem, if I am wrong,
I'd be gladly corrected.
Radim
[1] http://support.microsoft.com/kb/168958
[2] http://connect.microsoft.com/VisualStudio/feedback/details/649531
--
Radim Vansa <rvansa(a)redhat.com>
JBoss DataGrid QA
10 years
