[JBoss JIRA] (ISPN-11519) Cache should not start if it cluster listener replication fails
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11519?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11519:
-----------------------------------
Fix Version/s: 11.0.0.Final
(was: 11.0.0.CR1)
> Cache should not start if it cluster listener replication fails
> ---------------------------------------------------------------
>
> Key: ISPN-11519
> URL: https://issues.redhat.com/browse/ISPN-11519
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 10.1.5.Final, 11.0.0.Dev03
> Reporter: Dan Berindei
> Assignee: Will Burns
> Priority: Major
> Fix For: 11.0.0.Final
>
>
> {{StateConsumerImpl.fetchClusterListeners}} catches any exceptions during the fetch and local installation of cluster listeners from other nodes, and only logs a warning message:
> {noformat}
> 18:04:14,069 WARN (jgroups-5,Test-NodeD:[]) [StateConsumerImpl] ISPN000284: Problem encountered while installing cluster listener
> {noformat}
> If a cache starts without installing all the cluster listeners locally, the listeners will miss events for keys that end up with the joiner as the primary owner, which would be pretty hard to debug. We should instea fail fast, and prevent the cache from starting if the cluster listeners cannot be fetched and installed locally.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (ISPN-11248) Add test for ServerTask that utilizes protostream stored entries
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11248?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11248:
-----------------------------------
Fix Version/s: 11.0.0.Final
(was: 11.0.0.CR1)
> Add test for ServerTask that utilizes protostream stored entries
> ----------------------------------------------------------------
>
> Key: ISPN-11248
> URL: https://issues.redhat.com/browse/ISPN-11248
> Project: Infinispan
> Issue Type: Task
> Reporter: Will Burns
> Priority: Major
> Fix For: 11.0.0.Final
>
>
> We currently have a single ServerTask that just prints out "Hello <name>". We should add a new test that actually tests a very likely use case of storing entries in protostream and using a task that deserializes them properly (this could be done automatically by the encoding layer of the cache, if it is working).
> We may also want to look into sharing this with a custom loader, as we have users doing this today. And it is quite clunky, so we can see how the usability is in 11.0.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (ISPN-11423) Dump information in panic scenarios
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11423?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11423:
-----------------------------------
Fix Version/s: 11.0.0.Final
(was: 11.0.0.CR1)
> Dump information in panic scenarios
> -----------------------------------
>
> Key: ISPN-11423
> URL: https://issues.redhat.com/browse/ISPN-11423
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core, Server
> Affects Versions: 10.1.3.Final, 11.0.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 11.0.0.Final
>
>
> When there is a panic situation (e.g. thread pool exhausted), dump information (e.g. including a thread dump) to a file at FATAL level.
> The server should dump the most important information to another log (file) periodically (e.g. every 15 minutes). This log should be enabled by default.
> These files can be sent to support via an SOS report.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (ISPN-11381) AdvancedCache.getGroup(key) may return incomplete results during state transfer
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11381?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11381:
-----------------------------------
Fix Version/s: 11.0.0.Final
(was: 11.0.0.CR1)
> AdvancedCache.getGroup(key) may return incomplete results during state transfer
> -------------------------------------------------------------------------------
>
> Key: ISPN-11381
> URL: https://issues.redhat.com/browse/ISPN-11381
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.4.18.Final, 10.1.2.Final, 11.0.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 11.0.0.Final
>
>
> {{AdvancedCache.getGroup(groupKey)}} returns all the keys that belong to a group.
> If the originator is not an owner, the command is forwarded to the primary owner. If the originator is a primary or a backup owner for the group key, the command is executed locally.
> During state transfer, a node may be a write owner for the group key but not a read owner. Currently {{GroupingInterceptor}} uses {{LocalizedCacheTopogy.isWriteOwner(groupKey)}} instead of {{isReadOwner(groupKey)}}, so it executes the command on the originator instead of forwarding it to the primary owner.
--
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:
-----------------------------------
Fix Version/s: 11.0.0.Final
(was: 11.0.0.CR1)
> 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: 11.0.0.Final
>
>
> 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