[infinispan-dev] Fwd: [jgroups-users] Event.MSG and JGRP-2067

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[infinispan-dev] Fwd: [jgroups-users] Event.MSG and JGRP-2067

Bela Ban

-------- Forwarded Message --------
Subject: [jgroups-users] Event.MSG and JGRP-2067
Date: Tue, 26 Jul 2016 13:44:47 +0200
From: Questions/problems related to using JGroups
<[hidden email]>
Reply-To: [hidden email]
To: jg-users <[hidden email]>

so far, all messages to be sent and all received messages have always
been wrapped in an Event, e.g. when calling JChannel.send(Message msg):

Event evt=new Event(Event.MSG, msg);

This caused the creation of an Event instance for every sent and
received message.

In [1], I changed this and added 2 methods to Protocol:

public Object down(Message msg);
public Object up(Message msg)

These callbacks are now called instead of down(Event) and up(Event)
whenever a message is sent or received. Since messages make up 99.9% of
all traffic up and down a stack, this change should reduce the memory
allocation rate even more, although Event instances are very short-lived
and usually die in eden.

The downside is that this breaks code and devs who've handled messages
and events in the same method (up(Event) / down(Event)) now have to
break out the message handling code into separate methods (up(Message) /

This change is quite big (111 files changed, 2552 insertions(+), 2796
deletions(-)), but only affects protocol developers (and devs who
implement UpHandler directly).

This is for 4.0; 3.6.x is unaffected.

Let me know (via the mailing list) if you encounter any problems.

[1] https://issues.jboss.org/browse/JGRP-2067

Bela Ban, JGroups lead (http://www.jgroups.org)

What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
javagroups-users mailing list
[hidden email]

infinispan-dev mailing list
[hidden email]