[JBoss JIRA] (ISPN-3904) Migrate JDBC cache store tests
by Vitalii Chepeliuk (JIRA)
Vitalii Chepeliuk created ISPN-3904:
---------------------------------------
Summary: Migrate JDBC cache store tests
Key: ISPN-3904
URL: https://issues.jboss.org/browse/ISPN-3904
Project: Infinispan
Issue Type: Task
Components: Server
Reporter: Vitalii Chepeliuk
Assignee: Vitalii Chepeliuk
Migrating finctional tests for JDBC cache store
Following modules will be migrated: async-store, binary-no-passivation, binary-with-passivation, invalidation-cache, mixed-no-passivation
, mixed-with-passivation, string-based-multinode, string-based-no-passivation, string-based-with-passivation
--
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, 2 months
[JBoss JIRA] (ISPN-3903) Transaction Code Optimizations
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3903?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3903:
------------------------------
Description:
Currently, I found the following problems (so far, last update 18/01, 17h30, fix in progress):
* the LocalTxInvocationContext is creating an empty map every time a new instance is created. It originates >10GB of data in 5min. It can use the Collections.emptyMap()
* TransactionCoordinator is creating LocalTxInvocationContext twice when commit. First, prepare() method creates LocalTxInvocationContext and if it is read only, it invokes commitInternal (that will create a new LocalTxInvocationContext). The same for commit() method when the transaction is one phase. commitInternal() can reuse the LocalTxInvocationContext since they are stateless (and they already have a reference for the LocalTransaction).
* Refactor LocalTxInvocationContext and RemoteTxInvocationContext
Results (for 5 min profiling):
* HashMap allocation reduced from 20.80GB to 3.76GB
* LocalTxInvocationContext allocation reduced from 13.80GB to 7.44GB
was:
Currently, I found the following problems (so far, last update 18/01, 17h30, fix in progress):
* the LocalTxInvocationContext is creating an empty map every time a new instance is created. It originates >10GB of data in 5min. It can use the Collections.emptyMap()
* TransactionCoordinator is creating LocalTxInvocationContext twice when commit. First, prepare() method creates LocalTxInvocationContext and if it is read only, it invokes commitInternal (that will create a new LocalTxInvocationContext). The same for commit() method when the transaction is one phase. commitInternal() can reuse the LocalTxInvocationContext since they are stateless (and they already have a reference for the LocalTransaction).
> Transaction Code Optimizations
> ------------------------------
>
> Key: ISPN-3903
> URL: https://issues.jboss.org/browse/ISPN-3903
> Project: Infinispan
> Issue Type: Enhancement
> Components: Transactions
> Affects Versions: 6.0.1.Final
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Fix For: 7.0.0.Alpha1
>
>
> Currently, I found the following problems (so far, last update 18/01, 17h30, fix in progress):
> * the LocalTxInvocationContext is creating an empty map every time a new instance is created. It originates >10GB of data in 5min. It can use the Collections.emptyMap()
> * TransactionCoordinator is creating LocalTxInvocationContext twice when commit. First, prepare() method creates LocalTxInvocationContext and if it is read only, it invokes commitInternal (that will create a new LocalTxInvocationContext). The same for commit() method when the transaction is one phase. commitInternal() can reuse the LocalTxInvocationContext since they are stateless (and they already have a reference for the LocalTransaction).
> * Refactor LocalTxInvocationContext and RemoteTxInvocationContext
> Results (for 5 min profiling):
> * HashMap allocation reduced from 20.80GB to 3.76GB
> * LocalTxInvocationContext allocation reduced from 13.80GB to 7.44GB
--
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, 2 months
[JBoss JIRA] (ISPN-3868) Deadlock in RemoteCache getAsync
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3868?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3868:
------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 7.0.0.Alpha1
7.0.0.Final
Resolution: Done
> Deadlock in RemoteCache getAsync
> --------------------------------
>
> Key: ISPN-3868
> URL: https://issues.jboss.org/browse/ISPN-3868
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 6.0.0.Final
> Environment: RemoteCahe component of 6.0.0.Final
> Reporter: Alexander Furer
> Assignee: Mircea Markus
> Labels: remote
> Fix For: 7.0.0.Alpha1, 7.0.0.Final
>
>
> Here is the implementation of remoteCahe.getAsync() :
> {code}
> public NotifyingFuture<V> getAsync(final K key) {
> assertRemoteCacheManagerIsStarted();
> final NotifyingFutureImpl<V> result = new NotifyingFutureImpl<V>();
> Future<V> future = executorService.submit(new Callable<V>() {
> @Override
> public V call() throws Exception {
> V toReturn = get(key);
> result.notifyFutureCompletion();
> return toReturn;
> }
> });
> result.setExecuting(future);
> return result;
> }
> {code}
> 2 problems here :
> 1. Callable's call method might be called BEFORE calling client had a chance to add listener (i.e. getAsync is not returned yet), in this case its' listener futureDone method will never be called.
> 2. Even case #1 has not happened and notifyFutureCompletion is called on listener, but the future is not resolved yet : "call" has not returned, that's why the future that is passed to listener is not resolved, and calling future.get from listener blocks forever.
--
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, 2 months
[JBoss JIRA] (ISPN-3848) JBoss Marshalling Dependency is LGPL (not usable for Apache projects)
by Sebastian Schaffert (JIRA)
[ https://issues.jboss.org/browse/ISPN-3848?page=com.atlassian.jira.plugin.... ]
Sebastian Schaffert commented on ISPN-3848:
-------------------------------------------
Any news on this issue? We'd like to do a new Apache Marmotta release soon and need to decide if we need to drop Infinispan support for the moment.
> JBoss Marshalling Dependency is LGPL (not usable for Apache projects)
> ---------------------------------------------------------------------
>
> Key: ISPN-3848
> URL: https://issues.jboss.org/browse/ISPN-3848
> Project: Infinispan
> Issue Type: Feature Request
> Components: Marshalling
> Reporter: Sebastian Schaffert
> Assignee: Galder Zamarreño
>
> The marshalling component has a dependency to jboss-marshalling, which is currently licensed under LGPL only. This makes it very hard to use Infinispan in projects that require a licensing 100% compatible with the Apache License, in particular those hosted by the Apache Software Foundation. In my concrete case, I'd like to use Infinispan in Apache Marmotta, but the dependency to LGPL libraries is not possible.
--
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, 2 months
[JBoss JIRA] (ISPN-3903) Transaction Code Optimizations
by Pedro Ruivo (JIRA)
Pedro Ruivo created ISPN-3903:
---------------------------------
Summary: Transaction Code Optimizations
Key: ISPN-3903
URL: https://issues.jboss.org/browse/ISPN-3903
Project: Infinispan
Issue Type: Enhancement
Components: Transactions
Affects Versions: 6.0.1.Final
Reporter: Pedro Ruivo
Assignee: Pedro Ruivo
Fix For: 7.0.0.Alpha1
Currently, I found the following problems (so far, last update 18/01, 17h30, fix in progress):
* the LocalTxInvocationContext is creating an empty map every time a new instance is created. It originates >10GB of data in 5min. It can use the Collections.emptyMap()
* TransactionCoordinator is creating LocalTxInvocationContext twice when commit. First, prepare() method creates LocalTxInvocationContext and if it is read only, it invokes commitInternal (that will create a new LocalTxInvocationContext). The same for commit() method when the transaction is one phase. commitInternal() can reuse the LocalTxInvocationContext since they are stateless (and they already have a reference for the LocalTransaction).
--
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, 2 months
[JBoss JIRA] (ISPN-3902) Upgrade to Apache Lucene 4.6.1
by Sanne Grinovero (JIRA)
Sanne Grinovero created ISPN-3902:
-------------------------------------
Summary: Upgrade to Apache Lucene 4.6.1
Key: ISPN-3902
URL: https://issues.jboss.org/browse/ISPN-3902
Project: Infinispan
Issue Type: Component Upgrade
Components: Lucene Directory
Reporter: Sanne Grinovero
Assignee: Sanne Grinovero
Priority: Minor
Fix For: 7.0.0.Alpha1, 7.0.0.Final
Apache Lucene 4.6.1 is coming, probably tomorrow.
Verified the candidate release.
--
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, 2 months
[JBoss JIRA] (ISPN-3355) Add support for clustered listeners
by Desmond Kirrane (JIRA)
[ https://issues.jboss.org/browse/ISPN-3355?page=com.atlassian.jira.plugin.... ]
Desmond Kirrane commented on ISPN-3355:
---------------------------------------
Few comments on the ClusterListeners:
- Can the listener be made durable i.e. if the primary dies then the listener will be registered on the backup
- Can the listener use a query api e.g. notify me of any Books having "title" like "%engine%"
- Can the listener add the option to remove or modify the entry/entires its query matches.
> Add support for clustered listeners
> -----------------------------------
>
> Key: ISPN-3355
> URL: https://issues.jboss.org/browse/ISPN-3355
> Project: Infinispan
> Issue Type: Feature Request
> Reporter: Mircea Markus
> Assignee: William Burns
>
> As opposed to the current listener approach in Infinispan ( a listener instance is invoked on the data owners ), this JIRA is about adding support for a cluster listener: the same listener instance that is notified disregarding of data ownership ( RPC calls involved).
> Due to the fact that the listener notification might involve an RPC, it is nice to be able to specify filters on these listeners.
> The clustered listener support opens the way for some interesting architectures:
> * persistent/continuous queries: the query is transformed in a filter. On each notification, the listener (stateful) updates the query state
> * simplistic CEP can be built on top of the persistent query described above
> * remote/hotrod notifications might be based on clustered listeners as well.
--
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, 2 months
[JBoss JIRA] (ISPN-3873) Race condition in AbstractInvocationContextFactory (results in NullPointerException in EquivalentHashMap when receiving an invalidate command during startup)
by Karl von Randow (JIRA)
[ https://issues.jboss.org/browse/ISPN-3873?page=com.atlassian.jira.plugin.... ]
Karl von Randow commented on ISPN-3873:
---------------------------------------
Cool, yeah, I was thinking about how to write a test and… yeah. I'm available to test at any time; we have a production site that exhibits the problem pretty much immediately.
> Race condition in AbstractInvocationContextFactory (results in NullPointerException in EquivalentHashMap when receiving an invalidate command during startup)
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3873
> URL: https://issues.jboss.org/browse/ISPN-3873
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 6.0.1.Final
> Environment: Ubuntu Linux 12.04_LTS, Oracle Java SE 1.7.0_45
> Reporter: Karl von Randow
> Assignee: Mircea Markus
> Fix For: 7.0.0.Alpha1
>
> Attachments: infinispan.trace.gz
>
>
> Sometimes when I start one server in a cluster I see the NullPointerException reproduced below. This only occurs if there is another server running. I run multiple caches with clustering using invalidation. JGroups using JDBC_PING and TCP. The caches are non-transactional.
> The NPE is because the keyEq (Equivalence instance for keys) is null. I believe this is because the command is processed before the start() method has been called on the AbstractInvocationContextFactory, as the start() method sets the keyEq ivar.
> At this point I'm not sure how to fix it!
> java.lang.NullPointerException
> at org.infinispan.commons.equivalence.EquivalentHashMap.put(EquivalentHashMap.java:176)
> at org.infinispan.commons.equivalence.EquivalentHashSet.add(EquivalentHashSet.java:109)
> at org.infinispan.context.impl.NonTxInvocationContext.addLockedKey(NonTxInvocationContext.java:84)
> at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:190)
> at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLockNoCheck(LockManagerImpl.java:181)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockKey(AbstractLockingInterceptor.java:149)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitInvalidateCommand(AbstractLockingInterceptor.java:85)
> at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:118)
> 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.visitInvalidateCommand(AbstractVisitor.java:111)
> at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:118)
> 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.visitInvalidateCommand(AbstractVisitor.java:111)
> at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:118)
> 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.visitInvalidateCommand(AbstractVisitor.java:111)
> at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:118)
> 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.handleWithWaitForBlocks(InboundInvocationHandlerImpl.java:186)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:84)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:259)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:211)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:460)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:377)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:247)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:665)
> at org.jgroups.JChannel.up(JChannel.java:730)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1019)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:182)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:434)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:434)
> at org.jgroups.stack.Protocol.up(Protocol.java:409)
> at org.jgroups.stack.Protocol.up(Protocol.java:409)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294)
> at org.jgroups.protocols.RSVP.up(RSVP.java:221)
> at org.jgroups.protocols.UNICAST2.removeAndPassUp(UNICAST2.java:919)
> at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:800)
> at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:415)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:600)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:147)
> at org.jgroups.protocols.FD.up(FD.java:255)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:301)
> at org.jgroups.protocols.MERGE2.up(MERGE2.java:209)
> at org.jgroups.protocols.Discovery.up(Discovery.java:379)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1399)
> at org.jgroups.protocols.TP$MyHandler.run(TP.java:1585)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
--
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, 2 months