[JBoss JIRA] (ISPN-11978) Java ScriptEngine
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11978?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11978:
-----------------------------------
Sprint: DataGrid Sprint #46, DataGrid Sprint #47, DataGrid Sprint #48 (was: DataGrid Sprint #46, DataGrid Sprint #47)
> Java ScriptEngine
> -----------------
>
> Key: ISPN-11978
> URL: https://issues.redhat.com/browse/ISPN-11978
> Project: Infinispan
> Issue Type: Enhancement
> Components: Tasks
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Priority: Major
> Fix For: 12.0.0.Final
>
>
> Since Java 11 the Nashorn script engine has been deprecated and marked for removal.
> We can use either the Java compiler API or JShell to implement a ScriptEngine for Java.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (ISPN-12004) Add JGroups stack.combine INSERT_BEFORE
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-12004?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-12004:
-----------------------------------
Sprint: DataGrid Sprint #46, DataGrid Sprint #47, DataGrid Sprint #48 (was: DataGrid Sprint #46, DataGrid Sprint #47)
> Add JGroups stack.combine INSERT_BEFORE
> ---------------------------------------
>
> Key: ISPN-12004
> URL: https://issues.redhat.com/browse/ISPN-12004
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration
> Affects Versions: 11.0.0.Final
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Priority: Major
> Fix For: 12.0.0.Dev02
>
>
> The JGroups stack combiner supports INSERT_AFTER. It is also useful to add INSERT_BEFORE as well as INSERT_ABOVE and INSERT_BELOW aliases to better fit with the JGroups terminology.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (ISPN-11336) Infinispan BOM should only have dependency management
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11336?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11336:
-----------------------------------
Sprint: DataGrid Sprint #46, DataGrid Sprint #47, DataGrid Sprint #48 (was: DataGrid Sprint #46, DataGrid Sprint #47)
> Infinispan BOM should only have dependency management
> -----------------------------------------------------
>
> Key: ISPN-11336
> URL: https://issues.redhat.com/browse/ISPN-11336
> Project: Infinispan
> Issue Type: Bug
> Components: Build
> Affects Versions: 10.1.2.Final
> Reporter: Stéphane Nicoll
> Assignee: Pedro Ruivo
> Priority: Major
> Fix For: 12.0.0.Dev01
>
>
> The BOM has a {{pluginManagement}} section that's a bit misleading since Maven isn't going to do anything with it.
> It is also invalid at the moment per the following:
> {code:xml}
> <plugin>
> <groupId>org.infinispan.maven-plugins</groupId>
> <artifactId>protocol-parser-generator</artifactId>
> <version>${version.infinispan.maven-plugins}</version>
> </plugin>
> {code}
> This artifact does not seem to be published anymore. Using the BOM with resolution leads to
> {noformat}
> [WARNING] The POM for org.infinispan:infinispan-protocol-parser-generator-maven-plugin:jar:10.1.1.Final is missing, no dependency information available
> [WARNING] Failed to retrieve plugin descriptor for org.infinispan:infinispan-protocol-parser-generator-maven-plugin:10.1.1.Final: Plugin org.infinispan:infinispan-protocol-parser-generator-maven-plugin:10.1.1.Final or one of its dependencies could not be resolved: Failure to find org.infinispan:infinispan-protocol-parser-generator-maven-plugin:jar:10.1.1.Final in https://repo.spring.io/milestone was cached in the local repository, resolution will not be reattempted until the update interval of spring-milestones has elapsed or updates are forced
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (ISPN-11304) Allow scaling up without state transfer
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11304?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11304:
-----------------------------------
Sprint: DataGrid Sprint #40, DataGrid Sprint #46, DataGrid Sprint #47, DataGrid Sprint #48 (was: DataGrid Sprint #40, DataGrid Sprint #46, DataGrid Sprint #47)
> Allow scaling up without state transfer
> ---------------------------------------
>
> Key: ISPN-11304
> URL: https://issues.redhat.com/browse/ISPN-11304
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Affects Versions: 10.1.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 12.0.0.Dev01
>
>
> We should allow a cache to scale up without performing any state transfer, but without losing the data.
> To simplify things, the initial version will support a single owner, and will assume that only one node is being added at a time.
> The cache must be accessible remotely, but since information about the location of the keys is not accessible from the client, the client is expected to ignore ownership and use a round-robin access strategy.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (ISPN-12005) Store purge should ignore errors
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-12005?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-12005:
-----------------------------------
Sprint: DataGrid Sprint #46, DataGrid Sprint #47, DataGrid Sprint #48 (was: DataGrid Sprint #46, DataGrid Sprint #47)
> Store purge should ignore errors
> --------------------------------
>
> Key: ISPN-12005
> URL: https://issues.redhat.com/browse/ISPN-12005
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Loaders and Stores
> Affects Versions: 10.1.5.Final, 11.0.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 12.0.0.Final, 11.0.4.Final
>
>
> Purging of expired entries from stores is a pretty involved process, especially with {{RocksDBStore}}. When there's a problem unmarshalling the expired bucket or deleting an expired key, the purge task bails out immediately, without processing the remaining keys. To make matters worse, the exception it not logged anywhere. The only sign that something is wrong is a growing store (in the case of {{RocksDBStore}}, a growing number of SST files).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (ISPN-12009) Upgrade Hibernate to latest micro
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-12009?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-12009:
-----------------------------------
Sprint: DataGrid Sprint #46, DataGrid Sprint #47, DataGrid Sprint #48 (was: DataGrid Sprint #46, DataGrid Sprint #47)
> Upgrade Hibernate to latest micro
> ---------------------------------
>
> Key: ISPN-12009
> URL: https://issues.redhat.com/browse/ISPN-12009
> Project: Infinispan
> Issue Type: Component Upgrade
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Priority: Major
> Fix For: 11.0.1.Final
>
>
> Upgrade Hibernate to the following versions:
> * 5.1.17.Final
> * 5.3.17.Final
> Also, overwrite the following transitive dependencies version:
> * Apache Avro to 1.9.1
> * Dom4j to 2.1.3
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (ISPN-12231) Cache fails to start with IllegalStateException: We already had a newer topology
by Dan Berindei (Jira)
Dan Berindei created ISPN-12231:
-----------------------------------
Summary: Cache fails to start with IllegalStateException: We already had a newer topology
Key: ISPN-12231
URL: https://issues.redhat.com/browse/ISPN-12231
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 11.0.3.Final
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 12.0.0.Dev02
{{LocalTopologyManagerImpl.join()}} registers the {{LocalCacheStatus}} outside the {{ActionSequencer}} call, allowing another topology update command to install a topology before the join response is processed.
This is very unlikely to happen outside of tests, but I was able to reproduce it reliably when starting lots of nodes in parallel.
{noformat}
org.infinispan.commons.CacheConfigurationException: Error starting component org.infinispan.statetransfer.StateTransferManager
at org.infinispan.factories.impl.BasicComponentRegistryImpl.startWrapper(BasicComponentRegistryImpl.java:560)
at org.infinispan.factories.impl.BasicComponentRegistryImpl.access$700(BasicComponentRegistryImpl.java:30)
at org.infinispan.factories.impl.BasicComponentRegistryImpl$ComponentWrapper.running(BasicComponentRegistryImpl.java:775)
at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:341)
at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:237)
at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:210)
at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:1008)
at org.infinispan.cache.impl.AbstractDelegatingCache.start(AbstractDelegatingCache.java:512)
at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:697)
at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:643)
at org.infinispan.manager.DefaultCacheManager.internalGetCache(DefaultCacheManager.java:532)
at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:510)
at org.infinispan.stress.LargeClusterStressTest.lambda$testLargeClusterStart$0(LargeClusterStressTest.java:92)
at java.base/java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:264)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:264)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
at java.base/java.lang.Thread.run(Thread.java:832)
Caused by: java.util.concurrent.CompletionException: java.lang.IllegalStateException: We already had a newer topology by the time we received the join response
at org.infinispan.util.concurrent.CompletionStages.join(CompletionStages.java:82)
at org.infinispan.statetransfer.StateTransferManagerImpl.start(StateTransferManagerImpl.java:133)
at org.infinispan.statetransfer.CorePackageImpl$1.start(CorePackageImpl.java:48)
at org.infinispan.statetransfer.CorePackageImpl$1.start(CorePackageImpl.java:27)
at org.infinispan.factories.impl.BasicComponentRegistryImpl.invokeStart(BasicComponentRegistryImpl.java:592)
at org.infinispan.factories.impl.BasicComponentRegistryImpl.doStartWrapper(BasicComponentRegistryImpl.java:583)
at org.infinispan.factories.impl.BasicComponentRegistryImpl.startWrapper(BasicComponentRegistryImpl.java:552)
... 20 more
Caused by: java.lang.IllegalStateException: We already had a newer topology by the time we received the join response
at org.infinispan.topology.LocalTopologyManagerImpl.lambda$handleJoinResponse$5(LocalTopologyManagerImpl.java:227)
at java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1183)
at java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2299)
at java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:143)
at org.infinispan.topology.LocalTopologyManagerImpl.handleJoinResponse(LocalTopologyManagerImpl.java:225)
at org.infinispan.topology.LocalTopologyManagerImpl.lambda$join$0(LocalTopologyManagerImpl.java:161)
at java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1146)
at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2137)
at org.infinispan.remoting.transport.AbstractRequest.complete(AbstractRequest.java:67)
at org.infinispan.remoting.transport.impl.SingleTargetRequest.onResponse(SingleTargetRequest.java:45)
at org.infinispan.remoting.transport.impl.RequestRepository.addResponse(RequestRepository.java:52)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.processResponse(JGroupsTransport.java:1405)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.processMessage(JGroupsTransport.java:1308)
{noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months