[JBoss JIRA] (ISPN-6096) Cache container page does not show any containers when more hotrod-connectors are defined
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-6096?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic commented on ISPN-6096:
-------------------------------------------
[~mgencur] Can you please provide me with a configuration file so I can reproduce and work on this issue?
> Cache container page does not show any containers when more hotrod-connectors are defined
> -----------------------------------------------------------------------------------------
>
> Key: ISPN-6096
> URL: https://issues.jboss.org/browse/ISPN-6096
> Project: Infinispan
> Issue Type: Bug
> Components: Console
> Reporter: Martin Gencur
> Assignee: Vladimir Blagojevic
>
> When there's more than one <hotrod-connector> defined in domain.xml configuration, the cache container page does not show any containers. Tested many times.
> The server should be able to provide multiple HotRod endpoints bound to different cache containers.
> More specifically, this bug appears whenever I add "name" attribut to <hotrod-connector> tag. This attribute is required to differentiate hotrod connectors when there are more than one.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (ISPN-4390) CHMv8 leaks ThreadLocal
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4390?page=com.atlassian.jira.plugin.... ]
Dan Berindei edited comment on ISPN-4390 at 4/7/16 11:42 AM:
-------------------------------------------------------------
I should add that our CHMv8 code comes from Doug Lea's repository, not from OpenJDK, so the original code would also also have a problem with "leaked" {{ThreadLocal}}s.
Still, I have a hunch that the non-deterministic cleanup of stale {{ThreadLocalMap}} entries isn't such a big problem when you have a limited number of {{ThreadLocals}}. It's only when the {{ThreadLocalMap}} grows very large, e.g. because we create one per cache in {{InvocationContextContainerImpl}}, that {{cleanSomeSlots()}} becomes ineffective and it takes multiple rounds to clean up the stale entries created by the previous deployment. That and maybe worker threads that don't process requests often enough :)
was (Author: dan.berindei):
I should add that our CHMv8 code comes from Doug Lea's repository, not from OpenJDK, so the original code would also also have a problem with "leaked" the {{ThreadLocal}}.
Still, I have a hunch that the non-deterministic cleanup of stale {{ThreadLocalMap}} entries isn't such a big problem when you have a limited number of {{ThreadLocals}}. It's only when the {{ThreadLocalMap}} grows very large, e.g. because we create one per cache in {{InvocationContextContainerImpl}}, that {{cleanSomeSlots()}} becomes ineffective and it takes multiple rounds to clean up the stale entries created by the previous deployment. That and maybe worker threads that don't process requests often enough :)
> CHMv8 leaks ThreadLocal
> -----------------------
>
> Key: ISPN-4390
> URL: https://issues.jboss.org/browse/ISPN-4390
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Reporter: Sanne Grinovero
> Assignee: William Burns
> Fix For: 8.1.4.Final, 8.2.2.Final, 9.0.0.Final
>
>
> As discussed on: http://lists.jboss.org/pipermail/infinispan-dev/2014-June/015055.html
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (ISPN-4390) CHMv8 leaks ThreadLocal
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4390?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-4390:
------------------------------------
I should add that our CHMv8 code comes from Doug Lea's repository, not from OpenJDK, so the original code would also also have a problem with "leaked" the {{ThreadLocal}}.
Still, I have a hunch that the non-deterministic cleanup of stale {{ThreadLocalMap}} entries isn't such a big problem when you have a limited number of {{ThreadLocals}}. It's only when the {{ThreadLocalMap}} grows very large, e.g. because we create one per cache in {{InvocationContextContainerImpl}}, that {{cleanSomeSlots()}} becomes ineffective and it takes multiple rounds to clean up the stale entries created by the previous deployment. That and maybe worker threads that don't process requests often enough :)
> CHMv8 leaks ThreadLocal
> -----------------------
>
> Key: ISPN-4390
> URL: https://issues.jboss.org/browse/ISPN-4390
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Reporter: Sanne Grinovero
> Assignee: William Burns
> Fix For: 8.1.4.Final, 8.2.2.Final, 9.0.0.Final
>
>
> As discussed on: http://lists.jboss.org/pipermail/infinispan-dev/2014-June/015055.html
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (ISPN-5743) SIFS.start() throws IllegalArgumentException: Negative position
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/ISPN-5743?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated ISPN-5743:
---------------------------------
Status: Open (was: Pull Request Sent)
> SIFS.start() throws IllegalArgumentException: Negative position
> ----------------------------------------------------------------
>
> Key: ISPN-5743
> URL: https://issues.jboss.org/browse/ISPN-5743
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 8.0.1.Final, 7.2.5.Final
> Reporter: Radim Vansa
> Assignee: Radim Vansa
>
> This can happen when a record about deletion of entry with the same key was read recently and was not applied into index.
> Fix is quite trivial, but this revealed a situation when an entry can be reincarnated during cache store startup - since we don't keep deleted entries in index, we can't see that an entry was deleted (don't know it's last seqId) if files are read in unlucky order.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months