[JBoss JIRA] (ISPN-8981) Generate Hot Rod parser automatically
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-8981?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-8981:
-----------------------------------
Fix Version/s: 9.4.0.Final
(was: 9.3.0.Final)
> Generate Hot Rod parser automatically
> -------------------------------------
>
> Key: ISPN-8981
> URL: https://issues.jboss.org/browse/ISPN-8981
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 9.2.0.Final
> Reporter: Radim Vansa
> Assignee: Radim Vansa
> Fix For: 9.4.0.Final
>
>
> This JIRA has two objectives:
> 1. reduce number of allocated objects
> 2. improve the parsing on server side to avoid chains of lambda mappings
> Manual parsing of Hot Rod protocol, invoking recursive methods that return {{Optional}}s or {{Optional<Optional<...>}}s seems to generate a lot of garbage. A better approach would be a finite state automaton that would read the byte stream and invoke callbacks.
> Such automaton can be generated from a high-level grammar as part of the build process.
> Along with these changes we can remove the {{Response}} abstraction and write responses directly as {{ByteBuf}}s.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ISPN-8955) ClusterTopologyManagerImpl should only use non-blocking RPCs
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-8955?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-8955:
-----------------------------------
Fix Version/s: 9.4.0.Final
(was: 9.3.0.Final)
> ClusterTopologyManagerImpl should only use non-blocking RPCs
> ------------------------------------------------------------
>
> Key: ISPN-8955
> URL: https://issues.jboss.org/browse/ISPN-8955
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 9.2.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.4.0.Final
>
>
> {{ClusterTopologyManagerImpl}} still uses some blocking RPCs, particularly when a node becomes coordinator or after a merge. It should use non-blocking RPCs instead.
> It could also use non-blocking RPCs instead of fire-and-forget messages for things like topology updates, which would allow delivering topology updates in the same order on all the nodes instead of having regular nodes make to with missing topology updates (when the coordinator doesn't change).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ISPN-9072) Document Protobuf annotated collection null set callbacks
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-9072?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-9072:
-----------------------------------
Fix Version/s: 9.4.0.Final
(was: 9.3.0.Final)
> Document Protobuf annotated collection null set callbacks
> ---------------------------------------------------------
>
> Key: ISPN-9072
> URL: https://issues.jboss.org/browse/ISPN-9072
> Project: Infinispan
> Issue Type: Task
> Components: Documentation-Query
> Affects Versions: 9.2.1.Final
> Reporter: Galder Zamarreño
> Assignee: Adrian Nistor
> Fix For: 9.4.0.Final
>
>
> When using collection fields in Protobuf annotated classes, empty collections are marshalled into the same value as {{null}}, because Protobuf only has repeated fields and no fields is represented as {{null}}.
> This means that if you have an entity with an empty collection, when it's deserialized the collection will be null. This can be confusing for users and should be documented.
> [~anistor] had some ideas on how to improve this:
> {code}
> <anistor> I'm thinking of a way to make this easier for users that
> would prefer an empty collection being set instead of a
> null. would be possible by adding a new attribute for this in
> @ProtoField anotation
> > that'd be more predictable
> <anistor> would still not give you at deserializtion what was written
> during serialization. we do not have a null marker
> <anistor> it would just give you an empty collection if you prefer
> <anistor> instead of null
> > that option should be enabled by default
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ISPN-9064) SiteManualSwitchTest.testManualClusterSwitch randomly fails
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-9064?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-9064:
-----------------------------------
Fix Version/s: 9.4.0.Final
(was: 9.3.0.Final)
> SiteManualSwitchTest.testManualClusterSwitch randomly fails
> -----------------------------------------------------------
>
> Key: ISPN-9064
> URL: https://issues.jboss.org/browse/ISPN-9064
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Reporter: Galder Zamarreño
> Labels: testsuite_stability
> Fix For: 9.4.0.Final
>
>
> {code}
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.infinispan.client.hotrod.xsite.AbstractHotRodSiteFailoverTest.assertSiteHit(AbstractHotRodSiteFailoverTest.java:146)
> at org.infinispan.client.hotrod.xsite.SiteManualSwitchTest.assertSingleSiteHit(SiteManualSwitchTest.java:47)
> at org.infinispan.client.hotrod.xsite.SiteManualSwitchTest.testManualClusterSwitch(SiteManualSwitchTest.java:37)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ISPN-9054) Upgrade to Aesh 1.0
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-9054?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-9054:
-----------------------------------
Fix Version/s: 9.4.0.Final
(was: 9.3.0.Final)
> Upgrade to Aesh 1.0
> -------------------
>
> Key: ISPN-9054
> URL: https://issues.jboss.org/browse/ISPN-9054
> Project: Infinispan
> Issue Type: Component Upgrade
> Components: CLI
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Fix For: 9.4.0.Final
>
>
> Aesh 1.0 has been released, and is currently used by Wildfly 12.x. 1.0 has several differences to Aesh 0.66.x, most notably the introduction of the aesh-readline project and the removal of AeshConsoleCallback. The upgrade is non-trivial, however due to some of the new features provided by Aesh 1.x, it could greatly reduce the amount of code required.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ISPN-9151) All client listener parameters passed in programmatically
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-9151?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-9151:
-----------------------------------
Fix Version/s: 9.4.0.Final
(was: 9.3.0.Final)
> All client listener parameters passed in programmatically
> ---------------------------------------------------------
>
> Key: ISPN-9151
> URL: https://issues.jboss.org/browse/ISPN-9151
> Project: Infinispan
> Issue Type: Enhancement
> Components: Listeners, Remote Protocols
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Labels: redhat-summit-18
> Fix For: 9.3.0.CR1, 9.4.0.Final
>
>
> We're working with the OpenWhisk team to create a generic Feed that allows Infinispan remote events to be exposed in an OpenWhisk way.
> So, you'd pass in Hot Rod endpoint information, name of cache and other details and you'd establish a feed of data from that cache for create/updated/removed data.
> However, making this generic is tricky when you want to pass in filter/converter factory names since these are defined at the annotation level.
> Ideally we should have a way to pass in filter/converter factory names programmatically. To avoid limiting ourselves, you could potentially pass in an instance of the annotation in an overloaded method or as optional parameter [[1|https://stackoverflow.com/questions/16299717/how-to-create-an-instance-of-an-annotation]].
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months