Why the bump to a new minor version?
I had to make some API changes and - as I'm trying to avoid that in micro releases - I decided to bump the version to 4.1.0. The changes involve removing a few (rather exotic) JChannel constructors, but chances are you've never used any of them anyway. The other change is a signature change in Streamable, where I now throw IOExceptions and ClassNotFoundExceptions instead of simple Exceptions.
Here's a list of the major changes:
GraalVM / Quarkus support
- JGroups can now be compiled into a native executable using GraalVM's native-image. This is a very cool feature; I've used ProgrammaticUPerf2 to start a member in ~1 millisecond!
- This means JGroups can now be used by other applications to create native binaries. Not yet very polished, and I'll write a Quarkus extension next, but usable by folks who know GraalVM...
- I'll blog about the port to GraalVM and the Quarkus extension (once it's ready) next, so stay tuned!
- https://issues.jboss.org/browse/JGRP-2332
- https://issues.jboss.org/browse/JGRP-2341
Parsing of network packets
- When using network sniffers, such as wireshark, tshark or tcpdump, the resulting PCAP files can be parsed by JGroups, displaying the contents of network packets as JGroups messages
- This can be done offline (e.g. reading a previously recorded PCAP file) or online (e.g. by piping the output of tshark into JGroups).
- I'll write a separate blog post about this shortly
- https://issues.jboss.org/browse/JGRP-2311
- Documentation: http://www.jgroups.org/manual4/index.html#_analyzing_wire_format_packets
Diagnostics handler without reflection
- This is related to the GraalVM port: the default DiagnosticsHandler (used by probe.sh) uses reflection, which is not allowed in GraalVM
- This additional DiagnosticsHandler can be used instead of the default one when creating a native binary of an application. The advantage is that probe.sh still works, even in a native binary.
- https://issues.jboss.org/browse/JGRP-2337
RpcDispatcher without reflection
- This is similar to the above bullet item: since reflection is not allowed in the GraalVM at runtime, reflective calls by RpcDispatcher would have to be defined in a config file passed to native-image, when creating a native binary.
- I therefore added a way to invoke methods, without the need to use reflection
- For details see https://issues.jboss.org/browse/JGRP-2338 or the documentation at http://www.jgroups.org/manual4/index.html#_methodlookup_and_methoddispatcher
Probe: support when running under TCP
- Also required when running on GraalVM: since JGroups currently only supports TCP (MulticastSockets don't currently work on GraalVM), probe.sh needs to be given the address of *one* member, to fetch information about all members
- https://issues.jboss.org/browse/JGRP-2336
Change in how IPv4/IPv6 addresses are picked
- The new algorithm centers around bind_addr defined in the transport (UDP, TCP, TCP_NIO2); the value of this address determines how other addresses (such as loopback, site_local, global, localhost or default values) are resolved.
- Example: if bind_addr=::1, then all other addresses that are not explicitly defined will be IPv6. If bind_addr=127.0.0.1, the all other addresses will be IPv4 addresses.
- The advantage of this is that you can run a JGroups stack using IPv4 and another one using IPv6 in the same process!
- https://issues.jboss.org/browse/JGRP-2343
Please post questions/issues to the mailing list at https://groups.google.com/forum/#!forum/jgroups-dev.
Enjoy!
