JChannel startup optimization

[azus]

Hi,
i experience long start up delay (>30sec) when creating a JChannel with default values.

It boil down that i have many network interfaces on my Windows machine and the Util.getAllAvailableAddresses get called at least twice for each protocol.

• setDefaultAddressValues(List protocols, StackType ip_version)
• ProtocolStack.initComponents(Protocol p, ProtocolConfiguration cfg) ... down in the lambda Configurator.setDefaultAddressValues

It will be nice if the function Configurator.setDefaultAddressValues(Object obj, StackType ip_version) could reuse the last default address found.
(at least until the next JChannel creation)

Thanks to your open classes (all protected field and methods) i was able to have a working prototype by sub-classing JChannel, ProtocolStack and Configurator. But it will be nice to have this performance boost built-in (or a way to customize it).

[belaban]

Thanks for reporting this! I'll fix it next week; the corresponding JIRA is https://issues.redhat.com/browse/JGRP-2700

[belaban]

So am I correct to assume that iteration through all network interfaces (how many are we talking?) takes a long time? I wonder why this is the case, as there's no network resolution involved here...
Caching is definitely a good idea, but I wonder why this is talking so long.

[azus]

With further testing i found out that if i disconnect my VPN the time is cut in half.

Almost all the time (>95%) is spend in the Util.isUp method

cmd> ipconfig -all
this give me about 13 different nic
cmd> wmic nic get AdapterType, Name, Installed, MACAddress, PowerManagementSupported, Speed
this give me about 20 different nic
in the method Util.getAllAvailableAddresses(Predicate filter)
the interfaces list contain about 100 NetworkInterface objects (only 9 are up) (this take 900 ms for one call, half of that without VPN)

It's like each real interface is exploded in many sub interfaces like these (for one NIC):

• Zone Alarm Firewall Driver-0000)
• Npcap Packet Driver (NPCAP)-0000)
• VirtualBox NDIS Light-Weight Filter-0000)
• QoS Packet Scheduler-0000)
• WFP 802.3 MAC Layer LightWeight Filter-0000)
• WFP Native MAC Layer LightWeight Filter-0000)
• Native WiFi Filter Driver-0000)

[belaban]

Hmm, I'm starting to think that this is specific to your machine; I haven't heard complaints about slow startup times from anybody else. What happens if you explicitly set inet addresses, e.g. bind_addr in UDP/TCP/FD_SOCK etc?
I don't really want to pick (e.g.) a site-local address at init time, as they may change during run time, e.g. by an ifconfig eth0 down/up...

[capjoerg]

I can confirm this issue. Starting with version 5.2.0 the instantiation time for a JChannel grew from <1s to 12s. In our stack configuration we have all bind_addr and other address related fields explicitly set, but nevertheless a call to Util.getNonLoopbackAddress is performed in Configrator.setDefaultAddressValues. This call seems to be slow with certain network configurations on some machines.
It didn't hurt much in versions prior to 5.2.0, because Util.getNonLoopbackAddress was called only once for the whole stack, but now it is called once for each protocol in the stack, even if the particular protocol does not have any address related fields. I think a lazy computation of the non-loopback address only when needed, including caching, would speed this up significantly.

[belaban]

This looks like a reasonable cause; I created https://issues.redhat.com/browse/JGRP-2739 to investigate. If this is the cause, then - I agree - caching or lazy computation would help.

[azus]

First, thanks a lot for the time taken regarding this.
You may be right that my Windows Dev PC might be a worst case scenario.
I experimented with the bind_addr in UDP (either in the xml or as a JVM option...-Djgroups.bind_addr=127.0.0.1). But it is not changing the number of use of Util.getAllAvailableAddresses.

[belaban]

I fixed https://issues.redhat.com/browse/JGRP-2739 (JGRP-2700 is a duplicate) in the master and 5.2.x branches. I hope to release 5.3.1 and 5.2.20 within the first week of January 2024.
Sorry for the delay! Please let me know if this fixes your issues.
Cheers