[JBoss JIRA] (JGRP-2457) Make time and byte values more legible
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2457?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2457:
---------------------------
Fix Version/s: 5.0.0.Alpha4
Affects Version/s: (was: 5.0.0.Alpha4)
> Make time and byte values more legible
> --------------------------------------
>
> Key: JGRP-2457
> URL: https://issues.redhat.com/browse/JGRP-2457
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.0.0.Alpha4
>
>
> In an XML configuration, we can already define {{send_buf_size=20M}}, but when printing protocol attribute values, we'll print {{20000000}} instead.
> Change this to print time and bytes values in a more readable format, for all protocol attributes.
> Examples:
> * {{max_credits=3000000}} -> {{max_credits=3m}} // bytes
> * {{time=45000}} -> {{time=45s}} // time
> * {{avg_delivery_time=250.09us}} (note the suffix) // time
> * {{number_of_blockings=234986}} -> {{number_of_blockings=234'986}} // scalar
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (JGRP-815) Scatter/Gather to avoid copying
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-815?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-815:
--------------------------
Fix Version/s: 5.0.0.Alpha4
Affects Version/s: (was: 5.0.0.Alpha4)
> Scatter/Gather to avoid copying
> -------------------------------
>
> Key: JGRP-815
> URL: https://issues.redhat.com/browse/JGRP-815
> Project: JGroups
> Issue Type: Sub-task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0.0.Alpha4
>
> Attachments: bla10.java, bla9.java
>
>
> When we invoke Channel.send(), we pass a bufffer to JGroups. At the transport level, JGroups marshals the sender and destination address, plus all headers and the buffer into a new byte[] buffer, which is then passed to the socket (DatagramSocket, MulticastSocket, Socket).
> We cannot do gathering writes on a DatagramSocket because DatagramSocket doesn't expose this functionality, contrary to a DatagramChannel.
> We could avoid having to copy the user's buffer by using gathering writes: effectively passing to the socket NIO ByteBuffers containing:
> 1: Src and dest address plus flags, plus possibly size
> 2: The marshalled headers
> 3: The buffer passed to JGroups by the user
> We can obtain a gathering-write channel as follows:
> ByteBuffer[] buffers; // contains the 3 byte buffers above
> DatagramSocket sock;
> DatagramChannel ch=sock.getChannel();
> ch.write(buffers, 0, length); // length is the number of bytes of the total marshalled message
> This is supported by a GatheringByteChannel.
> I don't think there's currently a need to do scattered reads, but this needs to get investigated more. Also investigate whether MulticastSockets support gathering writes (whether they expose the correct DatagramChannel).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (JGRP-2402) SOS report
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2402?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2402:
---------------------------
Fix Version/s: 4.2.2
5.0.0.Alpha4
Affects Version/s: (was: 5.0.0.Alpha4)
> SOS report
> ----------
>
> Key: JGRP-2402
> URL: https://issues.redhat.com/browse/JGRP-2402
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.2.2, 5.0.0.Alpha4
>
>
> Add the ability to dump the most important attributes to a file / log (configurable), e.g.:
> * Max threads
> * Number of rejected messages
> * Size of retransmission tables (NAKACK2, UNICAST3)
> This can be used to diagnose issues by telling the customer to invoke this command and attach the resulting file to a ticket
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (JGRP-809) Copyless stack
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-809?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-809:
--------------------------
Fix Version/s: 5.0.0.Alpha4
Affects Version/s: (was: 5.0.0.Alpha4)
> Copyless stack
> --------------
>
> Key: JGRP-809
> URL: https://issues.redhat.com/browse/JGRP-809
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0.0.Alpha4
>
> Attachments: Buf.java, BufAllocator.java, Message.java
>
>
> Currently (as of 2.7), the transport reads the contents of a received packet into a buffer, then passes a *copy* of the buffer to a thread from the OOB or incoming thread pools. To prevent this copy, we can
> - have the receiver read only the version and OOB flag (to see which thread pool to dispatch the packet to)
> - pass a ref to the socket to a thread from the incoming of OOB pool, have that thread read the packet and return
> - each thread in the pool has its own buffer into which the buffer is read from the socket
> Possibly use NIO: we can install a selector and get woken up whenever data to be read is present. At that point, we can pass the ref to the socket to the handler thread and return immediately. NIO with channels for multicast sockets is available only in JDK 7 (or 8?), so this is a bit off... However, we can already implement this with reading the version and flags bytes and then passing the socket to the handler
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (JGRP-2430) GossipRouter: more efficient routing
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2430?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2430:
---------------------------
Fix Version/s: 4.2.2
5.0.0.Alpha4
Affects Version/s: (was: 5.0.0.Alpha4)
> GossipRouter: more efficient routing
> ------------------------------------
>
> Key: JGRP-2430
> URL: https://issues.redhat.com/browse/JGRP-2430
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.2.2, 5.0.0.Alpha4
>
>
> GossipRouter supports both NIO (ByteBuffer) and TCP (stream-based) connections. In both cases, however, the entire message is read and then routed to the destination address.
> It would be better to only read the cluster name and target address, and then use efficient stream-to-stream (or channel-to-channel) _transfer mechanisms_, which avoids temporary copies of data and the full reading of messages.
> Also look into routing of entire message _batches_.
> Investigate whether this is possible.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (JGRP-2412) GMS: reduce likelihood of merges on concurrent new member startup
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2412?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2412:
---------------------------
Fix Version/s: 4.2.2
5.0.0.Alpha4
Affects Version/s: (was: 5.0.0.Alpha4)
> GMS: reduce likelihood of merges on concurrent new member startup
> -----------------------------------------------------------------
>
> Key: JGRP-2412
> URL: https://issues.redhat.com/browse/JGRP-2412
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.2.2, 5.0.0.Alpha4
>
>
> When multiple new members are started concurrently, and no coord is present yet, different clients get different discovery results, and this may lead to merging.
> If we have no coord, we could run the discovery protocol multiple time, *with the current members list being cached*, and then might end up with a more similar list of new members.
> This could be governed by an additional attribute in {{Discovery}} ({{num_discovery_runs}}?)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months