[JBoss JIRA] (JGRP-2241) Bundler using direct memory as buffer
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2241?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2241:
---------------------------
Fix Version/s: 5.3
(was: 5.0)
> Bundler using direct memory as buffer
> -------------------------------------
>
> Key: JGRP-2241
> URL: https://issues.jboss.org/browse/JGRP-2241
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.3
>
>
> The current bundler impls use a byte[] array in an output stream as buffer into which messages are written.
> If we instead used a direct byte buffer (off-heap), the JDK would not create an additional copy but simply pass the contents to the corresponding socket. This would reduce the memory allocation rate.
> Direct buffers can also be used on the receiver side, investigate.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (JGRP-2108) TCP_NIO2: make default
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2108?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2108:
---------------------------
Fix Version/s: 5.2
(was: 5.0)
> TCP_NIO2: make default
> ----------------------
>
> Key: JGRP-2108
> URL: https://issues.jboss.org/browse/JGRP-2108
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.2
>
>
> This requires the following things:
> * performance of {{TCP_NIO2}} must be better than {{TCP}}
> * (possibly) use multiple selectors: each selector handles only a max number of connections; create more selectors when the number of connections per selector exceeds a certain value
> * (possibly) get rid of the reader thread and let the above selector do the read (the write is already done by the selector thread)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (JGRP-2140) Replace Table with RingBuffer in UNICAST3 and NAKACK2
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2140?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2140:
---------------------------
Fix Version/s: 5.3
(was: 5.0)
> Replace Table with RingBuffer in UNICAST3 and NAKACK2
> -----------------------------------------------------
>
> Key: JGRP-2140
> URL: https://issues.jboss.org/browse/JGRP-2140
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.3
>
>
> Table does allocate memory on resizing or compaction; whereas RingBuffer doesn't. Replacing Table with RingBuffer might bring memory allocation rates even further down.
> However, using RingBuffer as message store means that the capacity is fixed; when the RingBuffer is full, sender threads would have to block as messages cannot be dropped.
> However, blocking is something that should be done in a flow control protocol, such as {{UFC}} or {{MFC}}, and some applications might choose completely non-blocking flow control, e.g. {{UFC_NB}} or {{MFC_NB}}, and blocking in {{UNICAST3}} or {{NAKACK2}} would move part of the blocking/non-blocking aspect away from the flow control protocols.
> Measure the impact on performance. Table is a critical class used by NAKACK2 and UNICAST3, and is battle tested. Do this only if the benefits trump the risk.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (JGRP-2025) Counter enhancements
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2025?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2025:
---------------------------
Fix Version/s: 5.2
(was: 5.0)
> Counter enhancements
> --------------------
>
> Key: JGRP-2025
> URL: https://issues.jboss.org/browse/JGRP-2025
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.2
>
>
> * Add option to _not_ use a backup coordinator and instead run a reconciliation round on a view change in which the new coordinator asks everyone for their counter values. Perhaps use some simple timestamping mechanism to resolve conflicts
> * Add async operations, ie. returning {{CompletableFutures}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (JGRP-2065) RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2065?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2065:
---------------------------
Fix Version/s: 5.2
(was: 5.0)
> RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
> -------------------------------------------------------------------
>
> Key: JGRP-2065
> URL: https://issues.jboss.org/browse/JGRP-2065
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.2
>
>
> {{RoundTrip}} is a simple test between 2 members measuring round-trip latency. The sender continually sends a message, the receiver receives it and sends the response, and the sender unblocks when the response is received. Then the sender sends the next message.
> The time for the request is then logged at the sender and a min/avg/max value is computed (probably changed to histograms later).
> {{RoundTrip}} uses a JGroups channel, configured with {{-props}}, e.g. {{-props ~/tcp.xml}}.
> {{RoundTripTcp}} does the same, but uses direct TCP sockets (no JGroups) for communication.
> {{RoundTripServer}} uses the client-server classes of JGroups for communication, but no channel is used.
> Round trip times (both processes on the same box, a Mac mini):
> * {{RoundTrip}} (with {{tcp.xml}} shipped with JGroups): *110 us*
> * {{RoundTripTcp}}: *46 us*
> * {{RoundTripServer}}: *49 us*
> Note that the client/server classes used by {{RoundTripServer}} are also used by the TCP transport (configured in {{tcp.xml}}.
> {{RoundTripServer}} is ~6% slower than {{RoundTripTcp}}, but that can be attributed to the additional work the former has to do (e.g. connection reaping etc). This is something we can focus on later.
> The big difference are the 110 us for {{RoundTrip}}. The goal is to find out what causes this and eliminate it. Since {{RoundTrip}} and {{RoundTripServer}} use the same underlying client/server classes in JGroups, let's compare these 2.
> Tasks:
> * Remove all protocols other than TCP in the running stack: (e.g. {{probe.sh remove-protocol=MFC}}). I already did this and the diff was negligible, but let's run this again
> * Try various bundlers (e.g. NoBundler)
> * Reduce threads in the threadpools, possibly disable (regular and OOB) thread pools (replace with DirectExecutor)
> * The default is 1 sender thread, but try with multiple threads
> * Measure perf between sending a message (in the bundler) and receiving it
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (JGRP-1911) Use consensus for some subsystems
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-1911?page=com.atlassian.jira.plugin.... ]
Bela Ban closed JGRP-1911.
--------------------------
Resolution: Won't Do
This is a feature of jgroups-raft
> Use consensus for some subsystems
> ---------------------------------
>
> Key: JGRP-1911
> URL: https://issues.jboss.org/browse/JGRP-1911
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0
>
>
> Provide options for several subsystems to run with consensus, e.g.
> * {{SEQUENCER}}
> * {{CENTRAL_LOCK}}
> * {{COUNTER}}
> * {{TOA}}
> * Clustered singletons etc
> For example, with the current impl of distributed counters ({{COUNTER}}), the same counter can be available multiple times if we have a split brain. It is currently up to the user to merge counters with different values after a split brain heals.
> This is OK, but we should provide a second implementation, based on jgroups-raft, which uses consensus to determine the counter maintainer in a split brain scenario. This will forfeit availability in favor of consistency.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months