[JBoss JIRA] (ISPN-9624) Deprecate StreamingMarshaller interface
by Ryan Emerson (Jira)
[ https://issues.jboss.org/browse/ISPN-9624?page=com.atlassian.jira.plugin.... ]
Ryan Emerson updated ISPN-9624:
-------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/6240, https://github.com/infinispan/infinispan/pull/6906 (was: https://github.com/infinispan/infinispan/pull/6240)
> Deprecate StreamingMarshaller interface
> ---------------------------------------
>
> Key: ISPN-9624
> URL: https://issues.jboss.org/browse/ISPN-9624
> Project: Infinispan
> Issue Type: Sub-task
> Components: Core
> Affects Versions: 9.4.0.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 10.0.0.Beta4
>
>
> The StreamingMarshaller interface is no longer fit for purpose once we move away from jboss-marshalling as the ObjectOutput abstraction does not fit with non-serialization based marshallers. We should provide a simpler interface that simply allows reading/writing objects to a provided stream. This interface should then be exposed via the InitializationContext to store implementations.
> {code:java}
> @ThreadSafe
> public interface StreamAwareMarshaller extends Marshaller {
> /**
> * Marshall an object to the {@link OutputStream}
> *
> * @param o the object to write to the {@link OutputStream}
> * @param out the {@link OutputStream} to write the object to
> * @throws IOException if the object cannot be marshalled to the {@link OutputStream} due to some I/O error
> */
> void writeObject(Object o, OutputStream out) throws IOException;
> /**
> * Unmarshall an object from the {@link InputStream}
> *
> * @param in the {@link InputStream} to unmarshall an object from
> * @return the unmarshalled object instance
> * @throws IOException if unmarshalling cannot complete due to some I/O error
> * @throws ClassNotFoundException if the class of the object trying to unmarshall is not found
> */
> Object readObject(InputStream in) throws ClassNotFoundException, IOException;
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (ISPN-10216) Implement bloom filter based near cache invalidations
by Will Burns (Jira)
Will Burns created ISPN-10216:
---------------------------------
Summary: Implement bloom filter based near cache invalidations
Key: ISPN-10216
URL: https://issues.jboss.org/browse/ISPN-10216
Project: Infinispan
Issue Type: Sub-task
Reporter: Will Burns
Currently our near cache invalidation messages contain every remove/modify/expired event. It would be preferable to only send known invalidation messages to the client using some sort of bloom filter based approach. This should help reduce the number of total messages and allow for write clients to operate more efficiently.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (ISPN-10215) Send clear event to near cache when client is not accepting events quick enough
by Will Burns (Jira)
Will Burns created ISPN-10215:
---------------------------------
Summary: Send clear event to near cache when client is not accepting events quick enough
Key: ISPN-10215
URL: https://issues.jboss.org/browse/ISPN-10215
Project: Infinispan
Issue Type: Sub-task
Components: Hot Rod, Listeners
Reporter: Will Burns
Fix For: 10.0.0.Final
When a near cache is used it will install a remote listener that receives all modified/remove/expired events. If a client is unable to keep up with the amount of updates, this can cause a backup on the server which in turn can slow down writes.
One solution for this would be if a client has been backed up for a given threshold to remove the pending events and send a single clear event to the near cache. This would take away the read performance temporarily of that client temporarily but would allow write heavy clients to continue operating.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (ISPN-8826) Starting a plain Hot Rod server requires fiddling with default cache
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-8826?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-8826:
----------------------------------
Fix Version/s: 10.0.0.Beta4
> Starting a plain Hot Rod server requires fiddling with default cache
> --------------------------------------------------------------------
>
> Key: ISPN-8826
> URL: https://issues.jboss.org/browse/ISPN-8826
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 9.1.6.Final, 9.2.0.CR2
> Reporter: Galder Zamarreño
> Assignee: Tristan Tarrant
> Priority: Major
> Fix For: 10.0.0.Beta4
>
>
> The following code does not work:
> {code}
> final DefaultCacheManager cacheManager = new DefaultCacheManager();
> final HotRodServer server = new HotRodServer();
> server.start(new HotRodServerConfigurationBuilder().build(), cacheManager);
> {code}
> It throws:
> {code}
> org.infinispan.commons.CacheConfigurationException: ISPN000433:
> A default cache has been requested, but no cache has been set as default for this container
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:449)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:440)
> at org.infinispan.security.actions.GetCacheAction.run(GetCacheAction.java:26)
> at org.infinispan.security.actions.GetCacheAction.run(GetCacheAction.java:14)
> at org.infinispan.security.Security.doPrivileged(Security.java:76)
> at org.infinispan.server.hotrod.SecurityActions.doPrivileged(SecurityActions.java:34)
> at org.infinispan.server.hotrod.SecurityActions.getCache(SecurityActions.java:51)
> at org.infinispan.server.hotrod.HotRodServer.getCacheInstance(HotRodServer.java:372)
> at org.infinispan.server.hotrod.HotRodServer.startDefaultCache(HotRodServer.java:302)
> at org.infinispan.server.core.AbstractProtocolServer.startInternal(AbstractProtocolServer.java:57)
> at org.infinispan.server.hotrod.HotRodServer.startInternal(HotRodServer.java:229)
> at org.infinispan.server.hotrod.HotRodServer.startInternal(HotRodServer.java:94)
> at org.infinispan.server.core.AbstractProtocolServer.start(AbstractProtocolServer.java:78)
> at org.infinispan.sandbox.SingleServer.main(SingleServer.java:17)
> {code}
> The Hot Rod server should not have to care about the default cache. In the past, calling getCache on default cache used to be make sure the node starts up components such as JGroups...etc.
> This shouldn't be necessary, but needs double check with [~dan.berindei] and also [~pferraro] for repercussions of changes at this level.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (ISPN-8826) Starting a plain Hot Rod server requires fiddling with default cache
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-8826?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-8826:
-------------------------------------
Assignee: Tristan Tarrant
> Starting a plain Hot Rod server requires fiddling with default cache
> --------------------------------------------------------------------
>
> Key: ISPN-8826
> URL: https://issues.jboss.org/browse/ISPN-8826
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 9.1.6.Final, 9.2.0.CR2
> Reporter: Galder Zamarreño
> Assignee: Tristan Tarrant
> Priority: Major
> Fix For: 10.0.0.Beta4
>
>
> The following code does not work:
> {code}
> final DefaultCacheManager cacheManager = new DefaultCacheManager();
> final HotRodServer server = new HotRodServer();
> server.start(new HotRodServerConfigurationBuilder().build(), cacheManager);
> {code}
> It throws:
> {code}
> org.infinispan.commons.CacheConfigurationException: ISPN000433:
> A default cache has been requested, but no cache has been set as default for this container
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:449)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:440)
> at org.infinispan.security.actions.GetCacheAction.run(GetCacheAction.java:26)
> at org.infinispan.security.actions.GetCacheAction.run(GetCacheAction.java:14)
> at org.infinispan.security.Security.doPrivileged(Security.java:76)
> at org.infinispan.server.hotrod.SecurityActions.doPrivileged(SecurityActions.java:34)
> at org.infinispan.server.hotrod.SecurityActions.getCache(SecurityActions.java:51)
> at org.infinispan.server.hotrod.HotRodServer.getCacheInstance(HotRodServer.java:372)
> at org.infinispan.server.hotrod.HotRodServer.startDefaultCache(HotRodServer.java:302)
> at org.infinispan.server.core.AbstractProtocolServer.startInternal(AbstractProtocolServer.java:57)
> at org.infinispan.server.hotrod.HotRodServer.startInternal(HotRodServer.java:229)
> at org.infinispan.server.hotrod.HotRodServer.startInternal(HotRodServer.java:94)
> at org.infinispan.server.core.AbstractProtocolServer.start(AbstractProtocolServer.java:78)
> at org.infinispan.sandbox.SingleServer.main(SingleServer.java:17)
> {code}
> The Hot Rod server should not have to care about the default cache. In the past, calling getCache on default cache used to be make sure the node starts up components such as JGroups...etc.
> This shouldn't be necessary, but needs double check with [~dan.berindei] and also [~pferraro] for repercussions of changes at this level.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (ISPN-8826) Starting a plain Hot Rod server requires fiddling with default cache
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-8826?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-8826:
----------------------------------
Status: Open (was: New)
> Starting a plain Hot Rod server requires fiddling with default cache
> --------------------------------------------------------------------
>
> Key: ISPN-8826
> URL: https://issues.jboss.org/browse/ISPN-8826
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 9.1.6.Final, 9.2.0.CR2
> Reporter: Galder Zamarreño
> Assignee: Tristan Tarrant
> Priority: Major
> Fix For: 10.0.0.Beta4
>
>
> The following code does not work:
> {code}
> final DefaultCacheManager cacheManager = new DefaultCacheManager();
> final HotRodServer server = new HotRodServer();
> server.start(new HotRodServerConfigurationBuilder().build(), cacheManager);
> {code}
> It throws:
> {code}
> org.infinispan.commons.CacheConfigurationException: ISPN000433:
> A default cache has been requested, but no cache has been set as default for this container
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:449)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:440)
> at org.infinispan.security.actions.GetCacheAction.run(GetCacheAction.java:26)
> at org.infinispan.security.actions.GetCacheAction.run(GetCacheAction.java:14)
> at org.infinispan.security.Security.doPrivileged(Security.java:76)
> at org.infinispan.server.hotrod.SecurityActions.doPrivileged(SecurityActions.java:34)
> at org.infinispan.server.hotrod.SecurityActions.getCache(SecurityActions.java:51)
> at org.infinispan.server.hotrod.HotRodServer.getCacheInstance(HotRodServer.java:372)
> at org.infinispan.server.hotrod.HotRodServer.startDefaultCache(HotRodServer.java:302)
> at org.infinispan.server.core.AbstractProtocolServer.startInternal(AbstractProtocolServer.java:57)
> at org.infinispan.server.hotrod.HotRodServer.startInternal(HotRodServer.java:229)
> at org.infinispan.server.hotrod.HotRodServer.startInternal(HotRodServer.java:94)
> at org.infinispan.server.core.AbstractProtocolServer.start(AbstractProtocolServer.java:78)
> at org.infinispan.sandbox.SingleServer.main(SingleServer.java:17)
> {code}
> The Hot Rod server should not have to care about the default cache. In the past, calling getCache on default cache used to be make sure the node starts up components such as JGroups...etc.
> This shouldn't be necessary, but needs double check with [~dan.berindei] and also [~pferraro] for repercussions of changes at this level.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (ISPN-10093) PersistenceManagerImpl stop deadlock with topology update
by Will Burns (Jira)
[ https://issues.jboss.org/browse/ISPN-10093?page=com.atlassian.jira.plugin... ]
Will Burns commented on ISPN-10093:
-----------------------------------
The UnsupportedOperationException was fixed in ISPN-10187. Sorry thought it was linked before. That would be unrelated though as it never starts a Publisher to do expiration.
The issue can happen due in any test hitting the same PersistenceManager. This manifests itself the exact same way I would expect in ISPN-10206. If this occurs again I would just reopen this issue.
> PersistenceManagerImpl stop deadlock with topology update
> ---------------------------------------------------------
>
> Key: ISPN-10093
> URL: https://issues.jboss.org/browse/ISPN-10093
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 10.0.0.Beta3
> Reporter: Dan Berindei
> Assignee: Will Burns
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.0.0.Beta4
>
> Attachments: threaddump.txt
>
>
> {{DistSyncStoreNotSharedTest.clearContent}} hanged in CI recently:
> {noformat}
> "testng-DistSyncStoreNotSharedTest" #16 prio=5 os_prio=0 cpu=11511.26ms elapsed=435.14s tid=0x00007fdb710b6000 nid=0x3222 waiting on condition [0x00007fdb352d3000]
> java.lang.Thread.State: WAITING (parking)
> at jdk.internal.misc.Unsafe.park(java.base@11/Native Method)
> - parking to wait for <0x00000000c8a22450> (a java.util.concurrent.Semaphore$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(java.base@11/LockSupport.java:194)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11/AbstractQueuedSynchronizer.java:885)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(java.base@11/AbstractQueuedSynchronizer.java:1009)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(java.base@11/AbstractQueuedSynchronizer.java:1324)
> at java.util.concurrent.Semaphore.acquireUninterruptibly(java.base@11/Semaphore.java:504)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.stop(PersistenceManagerImpl.java:222)
> at jdk.internal.reflect.GeneratedMethodAccessor72.invoke(Unknown Source)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11/DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(java.base@11/Method.java:566)
> at org.infinispan.commons.util.SecurityActions.lambda$invokeAccessibly$0(SecurityActions.java:79)
> at org.infinispan.commons.util.SecurityActions$$Lambda$237/0x0000000100661c40.run(Unknown Source)
> at org.infinispan.commons.util.SecurityActions.doPrivileged(SecurityActions.java:71)
> at org.infinispan.commons.util.SecurityActions.invokeAccessibly(SecurityActions.java:76)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:181)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.performStop(BasicComponentRegistryImpl.java:601)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.stopWrapper(BasicComponentRegistryImpl.java:590)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.stop(BasicComponentRegistryImpl.java:461)
> at org.infinispan.factories.AbstractComponentRegistry.internalStop(AbstractComponentRegistry.java:431)
> at org.infinispan.factories.AbstractComponentRegistry.stop(AbstractComponentRegistry.java:366)
> at org.infinispan.cache.impl.CacheImpl.performImmediateShutdown(CacheImpl.java:1160)
> at org.infinispan.cache.impl.CacheImpl.stop(CacheImpl.java:1125)
> at org.infinispan.cache.impl.AbstractDelegatingCache.stop(AbstractDelegatingCache.java:521)
> at org.infinispan.manager.DefaultCacheManager.terminate(DefaultCacheManager.java:747)
> at org.infinispan.manager.DefaultCacheManager.stopCaches(DefaultCacheManager.java:799)
> at org.infinispan.manager.DefaultCacheManager.stop(DefaultCacheManager.java:775)
> at org.infinispan.test.TestingUtil.killCacheManagers(TestingUtil.java:846)
> at org.infinispan.test.MultipleCacheManagersTest.clearContent(MultipleCacheManagersTest.java:158)
> "persistence-thread-DistSyncStoreNotSharedTest-NodeB-p16432-t1" #53654 daemon prio=5 os_prio=0 cpu=1.26ms elapsed=301.93s tid=0x00007fdb3c3d8000 nid=0x8ef waiting on condition [0x00007fdb00055000]
> java.lang.Thread.State: WAITING (parking)
> at jdk.internal.misc.Unsafe.park(java.base@11/Native Method)
> - parking to wait for <0x00000000c8b1fb88> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(java.base@11/LockSupport.java:194)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11/AbstractQueuedSynchronizer.java:885)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(java.base@11/AbstractQueuedSynchronizer.java:1009)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(java.base@11/AbstractQueuedSynchronizer.java:1324)
> at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(java.base@11/ReentrantReadWriteLock.java:738)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.pollStoreAvailability(PersistenceManagerImpl.java:196)
> at org.infinispan.persistence.manager.PersistenceManagerImpl$$Lambda$492/0x00000001007fb440.run(Unknown Source)
> at java.util.concurrent.Executors$RunnableAdapter.call(java.base@11/Executors.java:515)
> at java.util.concurrent.FutureTask.runAndReset(java.base@11/FutureTask.java:305)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(java.base@11/ScheduledThreadPoolExecutor.java:305)
> "transport-thread-DistSyncStoreNotSharedTest-NodeB-p16424-t5" #53646 daemon prio=5 os_prio=0 cpu=3.15ms elapsed=301.94s tid=0x00007fdb2007a000 nid=0x8e8 waiting on condition [0x00007fdb0b406000]
> java.lang.Thread.State: WAITING (parking)
> at jdk.internal.misc.Unsafe.park(java.base@11/Native Method)
> - parking to wait for <0x00000000c8d2abb0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(java.base@11/LockSupport.java:194)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base@11/AbstractQueuedSynchronizer.java:2081)
> at io.reactivex.internal.operators.flowable.BlockingFlowableIterable$BlockingFlowableIterator.hasNext(BlockingFlowableIterable.java:94)
> at io.reactivex.Flowable.blockingForEach(Flowable.java:5682)
> at org.infinispan.statetransfer.StateConsumerImpl.removeStaleData(StateConsumerImpl.java:1011)
> at org.infinispan.statetransfer.StateConsumerImpl.onTopologyUpdate(StateConsumerImpl.java:453)
> at org.infinispan.statetransfer.StateTransferManagerImpl.doTopologyUpdate(StateTransferManagerImpl.java:202)
> at org.infinispan.statetransfer.StateTransferManagerImpl.access$000(StateTransferManagerImpl.java:58)
> at org.infinispan.statetransfer.StateTransferManagerImpl$1.updateConsistentHash(StateTransferManagerImpl.java:114)
> at org.infinispan.topology.LocalTopologyManagerImpl.resetLocalTopologyBeforeRebalance(LocalTopologyManagerImpl.java:437)
> at org.infinispan.topology.LocalTopologyManagerImpl.doHandleRebalance(LocalTopologyManagerImpl.java:519)
> - locked <0x00000000c8b30b30> (a org.infinispan.topology.LocalCacheStatus)
> at org.infinispan.topology.LocalTopologyManagerImpl.lambda$handleRebalance$3(LocalTopologyManagerImpl.java:484)
> at org.infinispan.topology.LocalTopologyManagerImpl$$Lambda$574/0x000000010089a040.run(Unknown Source)
> at org.infinispan.executors.LimitedExecutor.runTasks(LimitedExecutor.java:175){noformat}
> [Full thread dump|https://ci.infinispan.org/job/Infinispan/job/master/1133/artifact/core/]
> Somehow the producer thread for the transport-thread iteration is blocked, but without waiting for the persistence mutex. Maybe it's waiting for a topology? Not sure if it's relevant, but the last test to run was {{testClearWithFlag}}, so the data container was empty and the store had 5 entries.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (ISPN-10127) Error "mismatched input" in JDG CLI when trying to run site command with a hyphen in site's name
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10127?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10127:
-----------------------------------
Status: Pull Request Sent (was: Reopened)
Git Pull Request: https://github.com/infinispan/infinispan/pull/6843, https://github.com/infinispan/infinispan/pull/6844, https://github.com/infinispan/infinispan/pull/6944 (was: https://github.com/infinispan/infinispan/pull/6843, https://github.com/infinispan/infinispan/pull/6844)
> Error "mismatched input" in JDG CLI when trying to run site command with a hyphen in site's name
> ------------------------------------------------------------------------------------------------
>
> Key: ISPN-10127
> URL: https://issues.jboss.org/browse/ISPN-10127
> Project: Infinispan
> Issue Type: Bug
> Components: CLI
> Affects Versions: 9.4.12.Final, 10.0.0.Beta3
> Environment: JDG 7.1.2 GA
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Priority: Major
> Fix For: 10.0.0.Beta4, 9.4.14.Final
>
>
> An error message is returned when trying to get status of a site in JDG CLI, possibly because the site name has a hyphen character on it.
> The following example of the site command being executed in CLI shows the response I've got, trying to execute in different ways:
> {code:borderStyle=solid}
> [standalone@localhost:9990 distributed-cache=default] site --status site-01
> line 1:14 mismatched input 'site' expecting set null
> line 1:20 mismatched input '1' expecting set null
> [standalone@localhost:9990 distributed-cache=default] site --status 'site-01'
> Incorrect site name: 'site-01'
> [standalone@localhost:9990 distributed-cache=default] site --status "site-01"
> Incorrect site name: "site-01"
> [standalone@localhost:9990 distributed-cache=default] site --status {site-01}
> line 1:14 mismatched input '{' expecting set null
> line 1:21 mismatched input '1' expecting set null
> [standalone@localhost:9990 distributed-cache=default] site --status "{site-01}"
> Incorrect site name: "{site-01}"
> {code}
> However, if I try to execute the following command with a site name without the hyphen character in it's value, everything works as expected:
> {code:borderStyle=solid}
> [standalone@localhost:9990 distributed-cache=default] site --status SFO
> online
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months