[JBoss JIRA] (JGRP-1951) Flexible buffers for scatter/gather
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1951?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1951:
--------------------------------
- {{WriteBuffers}} was merged into {{Buffers}}
- Reading into a variable number of buffers is possible by adding (e.g.) 3 buffers, doing a scattering read and reading the individual buffers, see {{BuffersTest.testRead3Buffers()}} for an example
> Flexible buffers for scatter/gather
> -----------------------------------
>
> Key: JGRP-1951
> URL: https://issues.jboss.org/browse/JGRP-1951
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> Currently, {{Buffers}} and {{WriteBuffers}} are inflexible in that they always expect a length buffer followed by data ({{Buffers}}), or a sequence of len/data pairs ({{WriteBuffers}}).
> This is bad if we for example want to read a sequence like the one below (for connection establishment in TCP):
> {noformat}
> | cookie | version | len | peer-address |
> (4) (2) (2) (variable)
> {noformat}
> Goals:
> * Have only 1 buffer, for reading *and* writing
> * Allow to define the sequence by adding buffers dynamically, e.g. in the above case, we'd add a 4 and a 2-length buffer and read data into them. If the cookie and version don't match, throw an exception, else *dynamically* add a length buffer (possibly doing a clear() which removes the first 2 buffers), read data into it, then add a new buffer sized to the read length and finally read data into it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-1019) History browsing in CLI (using the up arrow) works strangely
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1019?page=com.atlassian.jira.plugi... ]
Alexey Loubyansky closed WFCORE-1019.
-------------------------------------
Fix Version/s: 1.0.2.Final
Resolution: Done
The issue was fixed by upgrading Aesh to version 0.66.1 (which was done for WFCORE-877)
> History browsing in CLI (using the up arrow) works strangely
> ------------------------------------------------------------
>
> Key: WFCORE-1019
> URL: https://issues.jboss.org/browse/WFCORE-1019
> Project: WildFly Core
> Issue Type: Enhancement
> Components: CLI
> Affects Versions: 2.0.0.CR1, 2.0.0.CR5
> Reporter: Ladislav Thon
> Assignee: Alexey Loubyansky
> Fix For: 1.0.2.Final
>
>
> I tend to rely on history browsing in the CLI a lot, but it got broken in WildFly 10.0.0.CR1 / WildFly Core 2.0.0.CR1 (I'd guess that the cause is the AESH upgrade). Let's see:
> {code}
> rm ~/.jboss-cli-history # let's start with clean slate
> ./wildfly-10.0.0.Beta2/bin/standalone.sh
> # the following is in second console
> ./wildfly-10.0.0.Beta2/bin/jboss-cli.sh -c
> :read-resource
> :whoami
> [up arrow shows :whoami, so press Enter to run it]
> [and repeat, up arrow shows :whoami]
> {code}
> OK, that's expected. Repeat the process with WildFly 10.0.0.CR1 or CR2 and you'll find out that the second \[up arrow\] shows {{:read-resource}}. This is IMHO highly wrong and it confused me _a lot_ when I first encoutered this bad behavior.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months