[JBoss JIRA] (ISPN-11123) Integrate Mutiny in the new api
by Katia Aresti (Jira)
[ https://issues.redhat.com/browse/ISPN-11123?page=com.atlassian.jira.plugi... ]
Katia Aresti updated ISPN-11123:
--------------------------------
Description:
Mutiny API has been released in the first version.
Upgrade the new reactive api to use it
was:
Mutinity API has been released in the first version.
Upgrade the new reactive api to use it
> Integrate Mutiny in the new api
> -------------------------------
>
> Key: ISPN-11123
> URL: https://issues.redhat.com/browse/ISPN-11123
> Project: Infinispan
> Issue Type: Feature Request
> Components: API
> Affects Versions: 10.1.0.Final
> Reporter: Katia Aresti
> Assignee: Katia Aresti
> Priority: Major
> Labels: api
>
> Mutiny API has been released in the first version.
> Upgrade the new reactive api to use it
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (ISPN-11131) server-runtime should use log4j2
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11131?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-11131:
--------------------------------
Status: Open (was: New)
> server-runtime should use log4j2
> --------------------------------
>
> Key: ISPN-11131
> URL: https://issues.redhat.com/browse/ISPN-11131
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 10.1.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.1.1.Final
>
>
> Currently the server uses JBoss LogManager, because that's what the WildFly server used.
> It works, but the properties-based configuration is kind of clunky: it uses almost the same format as {{java.util.logging}}, but there are differences. Also not many of our users are familiar with it: WildFly has its own logging configuration in the XML, and {{logging.properties}} is auto-generated.
> It would be better if we switched to log4j2 with a {{java.util.logging}} bridge.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (ISPN-11131) server-runtime should use log4j2
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11131?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-11131:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/7726
> server-runtime should use log4j2
> --------------------------------
>
> Key: ISPN-11131
> URL: https://issues.redhat.com/browse/ISPN-11131
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 10.1.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.1.1.Final
>
>
> Currently the server uses JBoss LogManager, because that's what the WildFly server used.
> It works, but the properties-based configuration is kind of clunky: it uses almost the same format as {{java.util.logging}}, but there are differences. Also not many of our users are familiar with it: WildFly has its own logging configuration in the XML, and {{logging.properties}} is auto-generated.
> It would be better if we switched to log4j2 with a {{java.util.logging}} bridge.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (ISPN-11116) Invalidation commands should not load the previous value from the store
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11116?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11116:
-----------------------------------
Fix Version/s: 9.3.8.Final
(was: 9.3.7.Final)
> Invalidation commands should not load the previous value from the store
> -----------------------------------------------------------------------
>
> Key: ISPN-11116
> URL: https://issues.redhat.com/browse/ISPN-11116
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.3.6.Final, 9.4.17.Final, 10.0.1.Final, 10.1.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 9.3.8.Final, 11.0.0.Final, 9.4.18.Final, 10.1.1.Final
>
>
> {{CacheLoaderInterceptor.visitInvalidateCommand()}} loads the previous value from the store, just in case there is a {{CacheEntryInvalidated}} listener that needs the previous value. This makes invalidation mode with a shared store very costly: for every write, every node receives an invalidation command, every node reads the value from the store, and then discards it.
> But {{InvalidateCommand}} only removes entries from memory, it never removes entry from stores (either shared or private). If we don't load the previous value in the data container, there is nothing for the {{InvalidateCommand}} to do. No invalidated entry means no listener notifications, so we don't need to load the previous value or to change the behaviour of {{CacheEntryInvalidatedEvent}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months