[JBoss JIRA] (ISPN-9127) Remote commands can access components before they are started
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9127?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9127:
----------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/5965, https://github.com/infinispan/infinispan/pull/6232, https://github.com/infinispan/infinispan/pull/6344 (was: https://github.com/infinispan/infinispan/pull/5965, https://github.com/infinispan/infinispan/pull/6232)
> Remote commands can access components before they are started
> -------------------------------------------------------------
>
> Key: ISPN-9127
> URL: https://issues.jboss.org/browse/ISPN-9127
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.2.2.Final, 9.3.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 9.4.0.Final
>
> Attachments: server0, server1, server2, trace.tar.gz
>
>
> {{PerCacheInboundInvocationHandler.handle()}} may be called before the component was started, because {{GlobalInboundInvocationHandler}} fetches it from the component registry without any checks. {{CommandsFactoryImpl.initializeReplicableCommand()}} doesn't wait for the components that it injects into remote commands to be started, either.
> This started causing random test failures in {{ConcurrentStartForkChannelTest}} after ISPN-8515, which moved most initialization work from {{init()}} methods to {{start()}} methods. Because {{StateProviderImpl}} starts after {{StateTransferManagerImpl}}, it's possible for a node to receive a {{StateRequestCommand}} before {{StateProviderImpl}} has initialized:
> {noformat}
> 16:15:09,549 TRACE (remote-thread-Test-NodeB-p51957-t2:[org.infinispan.CONFIG]) [StateProviderImpl] Starting outbound transfer to node Test-NodeA for cache null, topology id 2, segments {0-255}
> 16:15:09,551 WARN (remote-thread-Test-NodeB-p51957-t2:[]) [NonTotalOrderPerCacheInboundInvocationHandler] ISPN000071: Caught exception when handling command StateRequestCommand{cache=org.infinispan.CONFIG, origin=Test-NodeA, type=START_STATE_TRANSFER, topologyId=2, segments={0-255}}
> java.lang.IllegalArgumentException: chunkSize must be greater than 0
> at org.infinispan.statetransfer.OutboundTransferTask.<init>(OutboundTransferTask.java:114) ~[classes/:?]
> at org.infinispan.statetransfer.StateProviderImpl.startOutboundTransfer(StateProviderImpl.java:273) ~[classes/:?]
> at org.infinispan.statetransfer.StateRequestCommand.invokeAsync(StateRequestCommand.java:101) ~[classes/:?]
> at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokeCommand(BasePerCacheInboundInvocationHandler.java:94) ~[classes/:?]
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (ISPN-9627) Removing a listener after cache manager stop throws an exception
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9627?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9627:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Removing a listener after cache manager stop throws an exception
> ----------------------------------------------------------------
>
> Key: ISPN-9627
> URL: https://issues.jboss.org/browse/ISPN-9627
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.4.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 9.4.1.Final, 10.0.0.Alpha1
>
>
> {{DefaultCacheManager.removeListener()}} needs the {{CacheManagerNotifier}} component and fails if the component can't be accessed, e.g. because the manager is stopped. Since listeners are removed automatically on stop, a {{DefaultCacheManager.removeListener()}} call after stop should be a no-op.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (ISPN-9604) Support to run converters in the user requested format
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-9604?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-9604:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.4.1.Final
10.0.0.Alpha1
Resolution: Done
> Support to run converters in the user requested format
> ------------------------------------------------------
>
> Key: ISPN-9604
> URL: https://issues.jboss.org/browse/ISPN-9604
> Project: Infinispan
> Issue Type: Feature Request
> Components: Listeners, Remote Protocols
> Affects Versions: 9.4.0.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Major
> Fix For: 9.4.1.Final, 10.0.0.Alpha1
>
>
> As described in the [docs|http://infinispan.org/docs/stable/user_guide/user_guide.html#event_m...], a filter/converter can optionally specify a {{MediaType}} to process events, and let Infinispan perform the conversion between the storage format and the chosen format. Once converters are applied, the last step, in case it's needed, it to convert the event to the request format, which is the format that the cache was decorated with the {{withMediaType(...)}} method when the listener registration was performed.
> This is the basic mechanism that allow events to be received in a different MediaType than the data is stored, at the same time allowing the filter/converter to pick the best format to process data.
> Some converters, such as {{org.infinispan.server.hotrod.KeyValueVersionConverter}} (used in NearCache and the Spark Connecor) cannot work in this scheme since as part of its operation, it reads the stored key and values and creates a new value which is the aggregation of the Key and the Value in the byte[] format, thus preventing the final transformation step to the requested mediatype, since the type information is totally lost in the process.
> For this case it'd be interesting to have the possibility of applying the converters's convert() operation *after* having transformed the Key and Values to the final request format, therefore the final event value will be an aggregated byte[] but in the user requested format.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (ISPN-9627) Removing a listener after cache manager stop throws an exception
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-9627?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-9627:
-------------------------------
Fix Version/s: 10.0.0.Alpha1
> Removing a listener after cache manager stop throws an exception
> ----------------------------------------------------------------
>
> Key: ISPN-9627
> URL: https://issues.jboss.org/browse/ISPN-9627
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.4.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 9.4.1.Final, 10.0.0.Alpha1
>
>
> {{DefaultCacheManager.removeListener()}} needs the {{CacheManagerNotifier}} component and fails if the component can't be accessed, e.g. because the manager is stopped. Since listeners are removed automatically on stop, a {{DefaultCacheManager.removeListener()}} call after stop should be a no-op.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (ISPN-9641) Using expiration with off heap doesn't subtract size properly with expiration
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-9641?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-9641:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.3.4.Final
Resolution: Done
> Using expiration with off heap doesn't subtract size properly with expiration
> -----------------------------------------------------------------------------
>
> Key: ISPN-9641
> URL: https://issues.jboss.org/browse/ISPN-9641
> Project: Infinispan
> Issue Type: Bug
> Components: Off Heap
> Affects Versions: 9.4.0.Final
> Reporter: William Burns
> Assignee: William Burns
> Priority: Major
> Fix For: 9.4.1.Final, 9.3.4.Final, 10.0.0.Alpha1
>
>
> The OffHeapEntryFactoryImpl#getSize method is invoked when removing an entry. Unfortunately we don't add in the size for expiration (lifespan/maxidle). This can cause the count to think there are more bytes than there actually are, eventually evicting entries erroneously.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months