[JBoss JIRA] (MODCLUSTER-465) CMake: build expat, apr, apru, zlib, iconv, openssl, httpd, jk and mod_cluster
by Michal Karm (Jira)
[ https://issues.jboss.org/browse/MODCLUSTER-465?page=com.atlassian.jira.pl... ]
Michal Karm commented on MODCLUSTER-465:
----------------------------------------
Leaving the topic.
If [~jfclere] is interested; he might find someone to look into it or close it.
> CMake: build expat, apr, apru, zlib, iconv, openssl, httpd, jk and mod_cluster
> ------------------------------------------------------------------------------
>
> Key: MODCLUSTER-465
> URL: https://issues.jboss.org/browse/MODCLUSTER-465
> Project: mod_cluster
> Issue Type: Task
> Components: Native (httpd modules)
> Reporter: Michal Karm
> Assignee: Jean-Frederic Clere
> Priority: Major
> Original Estimate: 24 weeks
> Remaining Estimate: 24 weeks
>
> This is a long-term pet project dedicated to translating Autotools to CMake. The first two target platforms are Windows and Fedora, x86_64. Various flavours of Solaris, HP-UX, FreeBSD and Mac will follow.
> I'll use this JIRA for tracking notes and progress. It is noteworthy that the current upstream expat, apr and httpd use CMake to generate MSVC projects, so translating those to generating Linux make files shouldn't be that nightmareish. One Autotools directive at a time...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 8 months
[JBoss JIRA] (MODCLUSTER-465) CMake: build expat, apr, apru, zlib, iconv, openssl, httpd, jk and mod_cluster
by Michal Karm (Jira)
[ https://issues.jboss.org/browse/MODCLUSTER-465?page=com.atlassian.jira.pl... ]
Michal Karm reassigned MODCLUSTER-465:
--------------------------------------
Assignee: Jean-Frederic Clere (was: Michal Karm)
> CMake: build expat, apr, apru, zlib, iconv, openssl, httpd, jk and mod_cluster
> ------------------------------------------------------------------------------
>
> Key: MODCLUSTER-465
> URL: https://issues.jboss.org/browse/MODCLUSTER-465
> Project: mod_cluster
> Issue Type: Task
> Components: Native (httpd modules)
> Reporter: Michal Karm
> Assignee: Jean-Frederic Clere
> Priority: Major
> Original Estimate: 24 weeks
> Remaining Estimate: 24 weeks
>
> This is a long-term pet project dedicated to translating Autotools to CMake. The first two target platforms are Windows and Fedora, x86_64. Various flavours of Solaris, HP-UX, FreeBSD and Mac will follow.
> I'll use this JIRA for tracking notes and progress. It is noteworthy that the current upstream expat, apr and httpd use CMake to generate MSVC projects, so translating those to generating Linux make files shouldn't be that nightmareish. One Autotools directive at a time...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 8 months
[JBoss JIRA] (MODCLUSTER-475) Automate built artifacts release to GitHub Releases
by Michal Karm (Jira)
[ https://issues.jboss.org/browse/MODCLUSTER-475?page=com.atlassian.jira.pl... ]
Michal Karm commented on MODCLUSTER-475:
----------------------------------------
Leaving the topic.
If [~jfclere] is interested; he might find someone to look into it or close it.
> Automate built artifacts release to GitHub Releases
> ---------------------------------------------------
>
> Key: MODCLUSTER-475
> URL: https://issues.jboss.org/browse/MODCLUSTER-475
> Project: mod_cluster
> Issue Type: Task
> Reporter: Michal Karm
> Assignee: Jean-Frederic Clere
> Priority: Major
>
> The current setup of the suite of our multi-platform Jenkins jobs builds all the release artifacts without pushing them anywhere.
> The person doing the release has to download all these built artifacts and upload them to the jboss.org. Next, one has to adjust Magnolia Release pages, Release notes and links. It is tedious, it involves extensive Magnolia and Docbook hacking and we should get rid of it in order to streamline the release process.
> MODCLUSTER-474 introduced GitHub Releases, e.g. [1.3.1.Final on GitHub|http://modcluster.io/change_log/#final-6-may-2015]. This particular "demo" was uploaded manually, although it could be nicely automated either with [ghr|https://github.com/tcnksm/ghr] or [github-release|https://github.com/aktau/github-release]. The only possible downside is the exposure of our GitHub keys to the build environment. It could be easily addressed by having the mod_cluster-release Jenkins job tied to a one and only one specific private slave. Other suggestions are welcome though.
> Also, let's avoid https://xkcd.com/1319/
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 8 months
[JBoss JIRA] (MODCLUSTER-475) Automate built artifacts release to GitHub Releases
by Michal Karm (Jira)
[ https://issues.jboss.org/browse/MODCLUSTER-475?page=com.atlassian.jira.pl... ]
Michal Karm reassigned MODCLUSTER-475:
--------------------------------------
Assignee: Jean-Frederic Clere (was: Michal Karm)
> Automate built artifacts release to GitHub Releases
> ---------------------------------------------------
>
> Key: MODCLUSTER-475
> URL: https://issues.jboss.org/browse/MODCLUSTER-475
> Project: mod_cluster
> Issue Type: Task
> Reporter: Michal Karm
> Assignee: Jean-Frederic Clere
> Priority: Major
>
> The current setup of the suite of our multi-platform Jenkins jobs builds all the release artifacts without pushing them anywhere.
> The person doing the release has to download all these built artifacts and upload them to the jboss.org. Next, one has to adjust Magnolia Release pages, Release notes and links. It is tedious, it involves extensive Magnolia and Docbook hacking and we should get rid of it in order to streamline the release process.
> MODCLUSTER-474 introduced GitHub Releases, e.g. [1.3.1.Final on GitHub|http://modcluster.io/change_log/#final-6-may-2015]. This particular "demo" was uploaded manually, although it could be nicely automated either with [ghr|https://github.com/tcnksm/ghr] or [github-release|https://github.com/aktau/github-release]. The only possible downside is the exposure of our GitHub keys to the build environment. It could be easily addressed by having the mod_cluster-release Jenkins job tied to a one and only one specific private slave. Other suggestions are welcome though.
> Also, let's avoid https://xkcd.com/1319/
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 8 months
[JBoss JIRA] (MODCLUSTER-487) Default AdvertiseBindAddress value should not be NULL (UDP Multicast on Linux systems with more NICs)
by Michal Karm (Jira)
[ https://issues.jboss.org/browse/MODCLUSTER-487?page=com.atlassian.jira.pl... ]
Michal Karm commented on MODCLUSTER-487:
----------------------------------------
Leaving the topic.
If [~jfclere] is interested; he might find someone to look into it or close it.
> Default AdvertiseBindAddress value should not be NULL (UDP Multicast on Linux systems with more NICs)
> -----------------------------------------------------------------------------------------------------
>
> Key: MODCLUSTER-487
> URL: https://issues.jboss.org/browse/MODCLUSTER-487
> Project: mod_cluster
> Issue Type: Bug
> Components: Native (httpd modules)
> Affects Versions: 1.2.11.Final, 1.3.1.Final
> Environment: Linux, multiple NICs environment
> Reporter: Michal Karm
> Assignee: Jean-Frederic Clere
> Priority: Critical
> Fix For: 2.0.0.Alpha1
>
> Attachments: Advertize.class, advertise-linux3_x86_64.zip, advertise-windows_x86.zip
>
>
> Credit where it's due: the issue was first spotted by [~rhatlapa].
> h3. Problem
> It appears that trying to send to all interfaces with {{NULL}} or {{"0.0.0.0"}} -- the default {{bindaddr}} when no {{AdvertiseBindAddress}} is set -- in the following statement actually picks the first non-loopback interface and sends to it.
> {code}
> if ((rv = apr_sockaddr_info_get(&ma_listen_sa, bindaddr,
> ma_mgroup_sa->family, bindport,
> APR_UNSPEC, pool)) != APR_SUCCESS) {
> ap_log_error(APLOG_MARK, APLOG_ERR, rv, s,
> "mod_advertise: ma_group_join apr_sockaddr_info_get(%s:%d) failed", bindaddr, bindport);
> {code}
> The result is that there is no datagram on other interfaces. Surprisingly, this is not deterministic though: After dozens or hundreds of messages, eventually one datagram reaches another interface.
> h3. Impact
> Picture this simple scenario: There are two interfaces, e.g.
> {noformat}
> enp1s0 10.16.88.187
> enp2s0 172.18.0.1
> {noformat}
> listed in this exact order with {{ip addr show}}.
> One has an EAP 7 (Wildfly 10) instance with mod_cluster bound to {{172.18.0.1}} IP address, which implies {{enp2s0}} interface.
> Furthermore, one has an Apache HTTP Server instance with mod_cluster bound to {{172.18.0.1}} IP address, i.e. MCMP VirtualHost and main VirtualHost all Listen on this IP address.
> Result: Without advertising, using an explicit {{proxy-list}}, all is well. MCMP works, requests work, balancing works.
> On the other hand, relying on advertisement, it could take EAP 7 (Wildfly 10) *minutes* to register with the balancer.
> The reason is that a vast majority of UDP Multicast datagrams arrives at enp1s0 and EAP 7 (Wildfly 10) doesn't see them.
> h3. Reproducer
> Lemme demonstrate with a recently refactored [advertise.c|https://github.com/Karm/mod_cluster/tree/advertise-native-tes...] utility for sending datagrams and the well known [Advertize.java|https://raw.githubusercontent.com/modcluster/mod_cluster/m...] utility for receiving them.
> Your your convenience, here are binaries built from the aforementioned sources:
> * Advertize java utility: [^Advertize.class]
> * advertise native utility (Linux3 x86_64): [^advertise-linux3_x86_64.zip]
> * advertise native utility (WIndows x86): [^advertise-windows_x86.zip]
> h3. Demonstration on Linux
> h4. System
> {noformat}
> [mbabacek@perf09 ~]$ ip addr show
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> valid_lft forever preferred_lft forever
> 2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> link/ether 00:18:8b:7a:46:04 brd ff:ff:ff:ff:ff:ff
> inet 10.16.88.187/21 brd 10.16.95.255 scope global enp1s0
> valid_lft forever preferred_lft forever
> inet 10.16.93.253/21 brd 10.16.95.255 scope global secondary enp1s0
> valid_lft forever preferred_lft forever
> 3: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> link/ether 00:18:8b:7a:46:05 brd ff:ff:ff:ff:ff:ff
> inet 172.17.72.254/19 brd 172.17.95.255 scope global enp2s0
> valid_lft forever preferred_lft forever
> 4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
> link/ether 02:42:07:ab:74:f9 brd ff:ff:ff:ff:ff:ff
> inet 172.18.0.1/16 scope global docker0
> valid_lft forever preferred_lft forever
> {noformat}
> h4. Java
> {noformat}
> [mbabacek@perf09 ~]$ java -version
> openjdk version "1.8.0_71"
> OpenJDK Runtime Environment (build 1.8.0_71-b15)
> OpenJDK 64-Bit Server VM (build 25.71-b15, mixed mode)
> {noformat}
> h4.Advertise SENT
> {noformat}
> [mbabacek@perf09 ~]$ date;./advertise -a 224.0.1.102 -p 33364
> Mon Mar 21 12:39:51 EDT 2016
> UDP Multicast address to send datagrams to. Value: 224.0.1.102
> UDP Multicast port. Value: 33364
> IP address of the NIC to bound to. Value: NULL
> apr_socket_bind on 0.0.0.0:0
> apr_mcast_join on 0.0.0.0:0
> apr_socket_sendto to 224.0.1.102:33364
> {noformat}
> h4. Advertize RECEIVED
> YES (/)
> {noformat}
> [mbabacek@perf09 ~]$ java Advertize 224.0.1.102 33364
> Linux like OS
> ready waiting...
> received: Advertize !!! Mon, 21 Mar 2016 16:39:51 GMT
> received from /10.16.88.187:38907
> {noformat}
> YES (/)
> {noformat}
> [mbabacek@perf09 ~]$ java Advertize 224.0.1.102 33364 10.16.88.187
> Linux like OS
> ready waiting...
> received: Advertize !!! Mon, 21 Mar 2016 16:39:51 GMT
> received from /10.16.88.187:38907
> {noformat}
> NO (x)
> {noformat}
> [mbabacek@perf09 ~]$ java Advertize 224.0.1.102 33364 172.17.72.254
> Linux like OS
> ready waiting...
> {noformat}
> YES (/)
> {noformat}
> [mbabacek@perf09 ~]$ java Advertize 224.0.1.102 33364 0.0.0.0
> Linux like OS
> ready waiting...
> received: Advertize !!! Mon, 21 Mar 2016 16:39:51 GMT
> received from /10.16.88.187:38907
> {noformat}
> And now let's take a look at {{172.17.72.254}}, i.e. {{enp2s0}}
> h4. Advertise SENT
> {noformat}
> [mbabacek@perf09 ~]$ date;./advertise -a 224.0.1.102 -p 33364 -n 172.17.72.254
> Mon Mar 21 12:42:57 EDT 2016
> UDP Multicast address to send datagrams to. Value: 224.0.1.102
> UDP Multicast port. Value: 33364
> IP address of the NIC to bound to. Value: 172.17.72.254
> apr_socket_bind on 172.17.72.254:0
> apr_mcast_join on 172.17.72.254:0
> apr_socket_sendto to 224.0.1.102:33364
> {noformat}
> h4. Advertize RECEIVED
> NO (x)
> {noformat}
> [mbabacek@perf09 ~]$ java Advertize 224.0.1.102 33364
> Linux like OS
> ready waiting...
> {noformat}
> NO (x)
> {noformat}
> [mbabacek@perf09 ~]$ java Advertize 224.0.1.102 33364 10.16.88.187
> Linux like OS
> ready waiting...
> {noformat}
> YES (/)
> {noformat}
> [mbabacek@perf09 ~]$ java Advertize 224.0.1.102 33364 172.17.72.254
> Linux like OS
> ready waiting...
> received: Advertize !!! Mon, 21 Mar 2016 16:42:57 GMT
> received from /172.17.72.254:35452
> {noformat}
> NO (x)
> {noformat}
> [mbabacek@perf09 ~]$ java Advertize 224.0.1.102 33364 0.0.0.0
> Linux like OS
> ready waiting...
> {noformat}
> h3. Demonstration on Windows
> One could note that the problem doesn't exist on Windows. All interfaces receive advertising.
> h4. Advertise SENT
> {noformat}
> C:\Users\karm\advertise-build
> λ advertise.exe -a 224.0.1.102 -p 33364
> UDP Multicast address to send datagrams to. Value: 224.0.1.102
> UDP Multicast port. Value: 33364
> IP address of the NIC to bound to. Value: NULL
> apr_socket_bind on 0.0.0.0:0
> apr_mcast_join on 0.0.0.0:0
> apr_socket_sendto to 224.0.1.102:33364
> {noformat}
> h4. Advertize RECEIVED
> YES (/)
> {noformat}
> C:\Users\karm\WORKSPACE
> λ "C:\Program Files\Java\jdk1.8.0_74\bin\java" Advertize 224.0.1.102 33364
> ready waiting...
> received: Advertize !!! Mon, 21 Mar 2016 18:07:50 GMT
> received from /192.168.122.52:61805
> {noformat}
> YES (/)
> {noformat}
> C:\Users\karm\WORKSPACE
> λ "C:\Program Files\Java\jdk1.8.0_74\bin\java" Advertize 224.0.1.102 33364 192.168.122.52
> ready waiting...
> received: Advertize !!! Mon, 21 Mar 2016 18:07:50 GMT
> received from /192.168.122.52:61805
> {noformat}
> YES (/)
> {noformat}
> C:\Users\karm\WORKSPACE
> λ "C:\Program Files\Java\jdk1.8.0_74\bin\java" Advertize 224.0.1.102 33364 192.168.122.199
> ready waiting...
> received: Advertize !!! Mon, 21 Mar 2016 18:07:50 GMT
> received from /192.168.122.52:61805
> {noformat}
> h4. Advertise SENT
> {noformat}
> C:\Users\karm\advertise-build
> λ advertise.exe -a 224.0.1.102 -p 33364 -n 192.168.122.199
> UDP Multicast address to send datagrams to. Value: 224.0.1.102
> UDP Multicast port. Value: 33364
> IP address of the NIC to bound to. Value: 192.168.122.199
> apr_socket_bind on 192.168.122.199:0
> apr_mcast_join on 192.168.122.199:0
> apr_socket_sendto to 224.0.1.102:33364
> {noformat}
> h4. Advertize RECEIVED
> YES (/)
> {noformat}
> C:\Users\karm\WORKSPACE
> λ "C:\Program Files\Java\jdk1.8.0_74\bin\java" Advertize 224.0.1.102 33364
> ready waiting...
> received: Advertize !!! Mon, 21 Mar 2016 18:09:55 GMT
> received from /192.168.122.199:52781
> {noformat}
> YES (/)
> {noformat}
> C:\Users\karm\WORKSPACE
> λ "C:\Program Files\Java\jdk1.8.0_74\bin\java" Advertize 224.0.1.102 33364 192.168.122.52
> ready waiting...
> received: Advertize !!! Mon, 21 Mar 2016 18:09:55 GMT
> received from /192.168.122.199:52781
> {noformat}
> YES (/)
> {noformat}
> C:\Users\karm\WORKSPACE
> λ "C:\Program Files\Java\jdk1.8.0_74\bin\java" Advertize 224.0.1.102 33364 192.168.122.199
> ready waiting...
> received: Advertize !!! Mon, 21 Mar 2016 18:09:55 GMT
> received from /192.168.122.199:52781
> {noformat}
> h3. Suggestion
> Ideas? :) [~jfclere], [~rhusar]
> I suggest setting {{bindaddr}} (AdvertiseBindAddress) default to main_server's address or MCMP enabled vhost instead of NULL. I'll post a PR for evaluation.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 8 months
[JBoss JIRA] (MODCLUSTER-487) Default AdvertiseBindAddress value should not be NULL (UDP Multicast on Linux systems with more NICs)
by Michal Karm (Jira)
[ https://issues.jboss.org/browse/MODCLUSTER-487?page=com.atlassian.jira.pl... ]
Michal Karm reassigned MODCLUSTER-487:
--------------------------------------
Assignee: Jean-Frederic Clere (was: Michal Karm)
> Default AdvertiseBindAddress value should not be NULL (UDP Multicast on Linux systems with more NICs)
> -----------------------------------------------------------------------------------------------------
>
> Key: MODCLUSTER-487
> URL: https://issues.jboss.org/browse/MODCLUSTER-487
> Project: mod_cluster
> Issue Type: Bug
> Components: Native (httpd modules)
> Affects Versions: 1.2.11.Final, 1.3.1.Final
> Environment: Linux, multiple NICs environment
> Reporter: Michal Karm
> Assignee: Jean-Frederic Clere
> Priority: Critical
> Fix For: 2.0.0.Alpha1
>
> Attachments: Advertize.class, advertise-linux3_x86_64.zip, advertise-windows_x86.zip
>
>
> Credit where it's due: the issue was first spotted by [~rhatlapa].
> h3. Problem
> It appears that trying to send to all interfaces with {{NULL}} or {{"0.0.0.0"}} -- the default {{bindaddr}} when no {{AdvertiseBindAddress}} is set -- in the following statement actually picks the first non-loopback interface and sends to it.
> {code}
> if ((rv = apr_sockaddr_info_get(&ma_listen_sa, bindaddr,
> ma_mgroup_sa->family, bindport,
> APR_UNSPEC, pool)) != APR_SUCCESS) {
> ap_log_error(APLOG_MARK, APLOG_ERR, rv, s,
> "mod_advertise: ma_group_join apr_sockaddr_info_get(%s:%d) failed", bindaddr, bindport);
> {code}
> The result is that there is no datagram on other interfaces. Surprisingly, this is not deterministic though: After dozens or hundreds of messages, eventually one datagram reaches another interface.
> h3. Impact
> Picture this simple scenario: There are two interfaces, e.g.
> {noformat}
> enp1s0 10.16.88.187
> enp2s0 172.18.0.1
> {noformat}
> listed in this exact order with {{ip addr show}}.
> One has an EAP 7 (Wildfly 10) instance with mod_cluster bound to {{172.18.0.1}} IP address, which implies {{enp2s0}} interface.
> Furthermore, one has an Apache HTTP Server instance with mod_cluster bound to {{172.18.0.1}} IP address, i.e. MCMP VirtualHost and main VirtualHost all Listen on this IP address.
> Result: Without advertising, using an explicit {{proxy-list}}, all is well. MCMP works, requests work, balancing works.
> On the other hand, relying on advertisement, it could take EAP 7 (Wildfly 10) *minutes* to register with the balancer.
> The reason is that a vast majority of UDP Multicast datagrams arrives at enp1s0 and EAP 7 (Wildfly 10) doesn't see them.
> h3. Reproducer
> Lemme demonstrate with a recently refactored [advertise.c|https://github.com/Karm/mod_cluster/tree/advertise-native-tes...] utility for sending datagrams and the well known [Advertize.java|https://raw.githubusercontent.com/modcluster/mod_cluster/m...] utility for receiving them.
> Your your convenience, here are binaries built from the aforementioned sources:
> * Advertize java utility: [^Advertize.class]
> * advertise native utility (Linux3 x86_64): [^advertise-linux3_x86_64.zip]
> * advertise native utility (WIndows x86): [^advertise-windows_x86.zip]
> h3. Demonstration on Linux
> h4. System
> {noformat}
> [mbabacek@perf09 ~]$ ip addr show
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> valid_lft forever preferred_lft forever
> 2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> link/ether 00:18:8b:7a:46:04 brd ff:ff:ff:ff:ff:ff
> inet 10.16.88.187/21 brd 10.16.95.255 scope global enp1s0
> valid_lft forever preferred_lft forever
> inet 10.16.93.253/21 brd 10.16.95.255 scope global secondary enp1s0
> valid_lft forever preferred_lft forever
> 3: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> link/ether 00:18:8b:7a:46:05 brd ff:ff:ff:ff:ff:ff
> inet 172.17.72.254/19 brd 172.17.95.255 scope global enp2s0
> valid_lft forever preferred_lft forever
> 4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
> link/ether 02:42:07:ab:74:f9 brd ff:ff:ff:ff:ff:ff
> inet 172.18.0.1/16 scope global docker0
> valid_lft forever preferred_lft forever
> {noformat}
> h4. Java
> {noformat}
> [mbabacek@perf09 ~]$ java -version
> openjdk version "1.8.0_71"
> OpenJDK Runtime Environment (build 1.8.0_71-b15)
> OpenJDK 64-Bit Server VM (build 25.71-b15, mixed mode)
> {noformat}
> h4.Advertise SENT
> {noformat}
> [mbabacek@perf09 ~]$ date;./advertise -a 224.0.1.102 -p 33364
> Mon Mar 21 12:39:51 EDT 2016
> UDP Multicast address to send datagrams to. Value: 224.0.1.102
> UDP Multicast port. Value: 33364
> IP address of the NIC to bound to. Value: NULL
> apr_socket_bind on 0.0.0.0:0
> apr_mcast_join on 0.0.0.0:0
> apr_socket_sendto to 224.0.1.102:33364
> {noformat}
> h4. Advertize RECEIVED
> YES (/)
> {noformat}
> [mbabacek@perf09 ~]$ java Advertize 224.0.1.102 33364
> Linux like OS
> ready waiting...
> received: Advertize !!! Mon, 21 Mar 2016 16:39:51 GMT
> received from /10.16.88.187:38907
> {noformat}
> YES (/)
> {noformat}
> [mbabacek@perf09 ~]$ java Advertize 224.0.1.102 33364 10.16.88.187
> Linux like OS
> ready waiting...
> received: Advertize !!! Mon, 21 Mar 2016 16:39:51 GMT
> received from /10.16.88.187:38907
> {noformat}
> NO (x)
> {noformat}
> [mbabacek@perf09 ~]$ java Advertize 224.0.1.102 33364 172.17.72.254
> Linux like OS
> ready waiting...
> {noformat}
> YES (/)
> {noformat}
> [mbabacek@perf09 ~]$ java Advertize 224.0.1.102 33364 0.0.0.0
> Linux like OS
> ready waiting...
> received: Advertize !!! Mon, 21 Mar 2016 16:39:51 GMT
> received from /10.16.88.187:38907
> {noformat}
> And now let's take a look at {{172.17.72.254}}, i.e. {{enp2s0}}
> h4. Advertise SENT
> {noformat}
> [mbabacek@perf09 ~]$ date;./advertise -a 224.0.1.102 -p 33364 -n 172.17.72.254
> Mon Mar 21 12:42:57 EDT 2016
> UDP Multicast address to send datagrams to. Value: 224.0.1.102
> UDP Multicast port. Value: 33364
> IP address of the NIC to bound to. Value: 172.17.72.254
> apr_socket_bind on 172.17.72.254:0
> apr_mcast_join on 172.17.72.254:0
> apr_socket_sendto to 224.0.1.102:33364
> {noformat}
> h4. Advertize RECEIVED
> NO (x)
> {noformat}
> [mbabacek@perf09 ~]$ java Advertize 224.0.1.102 33364
> Linux like OS
> ready waiting...
> {noformat}
> NO (x)
> {noformat}
> [mbabacek@perf09 ~]$ java Advertize 224.0.1.102 33364 10.16.88.187
> Linux like OS
> ready waiting...
> {noformat}
> YES (/)
> {noformat}
> [mbabacek@perf09 ~]$ java Advertize 224.0.1.102 33364 172.17.72.254
> Linux like OS
> ready waiting...
> received: Advertize !!! Mon, 21 Mar 2016 16:42:57 GMT
> received from /172.17.72.254:35452
> {noformat}
> NO (x)
> {noformat}
> [mbabacek@perf09 ~]$ java Advertize 224.0.1.102 33364 0.0.0.0
> Linux like OS
> ready waiting...
> {noformat}
> h3. Demonstration on Windows
> One could note that the problem doesn't exist on Windows. All interfaces receive advertising.
> h4. Advertise SENT
> {noformat}
> C:\Users\karm\advertise-build
> λ advertise.exe -a 224.0.1.102 -p 33364
> UDP Multicast address to send datagrams to. Value: 224.0.1.102
> UDP Multicast port. Value: 33364
> IP address of the NIC to bound to. Value: NULL
> apr_socket_bind on 0.0.0.0:0
> apr_mcast_join on 0.0.0.0:0
> apr_socket_sendto to 224.0.1.102:33364
> {noformat}
> h4. Advertize RECEIVED
> YES (/)
> {noformat}
> C:\Users\karm\WORKSPACE
> λ "C:\Program Files\Java\jdk1.8.0_74\bin\java" Advertize 224.0.1.102 33364
> ready waiting...
> received: Advertize !!! Mon, 21 Mar 2016 18:07:50 GMT
> received from /192.168.122.52:61805
> {noformat}
> YES (/)
> {noformat}
> C:\Users\karm\WORKSPACE
> λ "C:\Program Files\Java\jdk1.8.0_74\bin\java" Advertize 224.0.1.102 33364 192.168.122.52
> ready waiting...
> received: Advertize !!! Mon, 21 Mar 2016 18:07:50 GMT
> received from /192.168.122.52:61805
> {noformat}
> YES (/)
> {noformat}
> C:\Users\karm\WORKSPACE
> λ "C:\Program Files\Java\jdk1.8.0_74\bin\java" Advertize 224.0.1.102 33364 192.168.122.199
> ready waiting...
> received: Advertize !!! Mon, 21 Mar 2016 18:07:50 GMT
> received from /192.168.122.52:61805
> {noformat}
> h4. Advertise SENT
> {noformat}
> C:\Users\karm\advertise-build
> λ advertise.exe -a 224.0.1.102 -p 33364 -n 192.168.122.199
> UDP Multicast address to send datagrams to. Value: 224.0.1.102
> UDP Multicast port. Value: 33364
> IP address of the NIC to bound to. Value: 192.168.122.199
> apr_socket_bind on 192.168.122.199:0
> apr_mcast_join on 192.168.122.199:0
> apr_socket_sendto to 224.0.1.102:33364
> {noformat}
> h4. Advertize RECEIVED
> YES (/)
> {noformat}
> C:\Users\karm\WORKSPACE
> λ "C:\Program Files\Java\jdk1.8.0_74\bin\java" Advertize 224.0.1.102 33364
> ready waiting...
> received: Advertize !!! Mon, 21 Mar 2016 18:09:55 GMT
> received from /192.168.122.199:52781
> {noformat}
> YES (/)
> {noformat}
> C:\Users\karm\WORKSPACE
> λ "C:\Program Files\Java\jdk1.8.0_74\bin\java" Advertize 224.0.1.102 33364 192.168.122.52
> ready waiting...
> received: Advertize !!! Mon, 21 Mar 2016 18:09:55 GMT
> received from /192.168.122.199:52781
> {noformat}
> YES (/)
> {noformat}
> C:\Users\karm\WORKSPACE
> λ "C:\Program Files\Java\jdk1.8.0_74\bin\java" Advertize 224.0.1.102 33364 192.168.122.199
> ready waiting...
> received: Advertize !!! Mon, 21 Mar 2016 18:09:55 GMT
> received from /192.168.122.199:52781
> {noformat}
> h3. Suggestion
> Ideas? :) [~jfclere], [~rhusar]
> I suggest setting {{bindaddr}} (AdvertiseBindAddress) default to main_server's address or MCMP enabled vhost instead of NULL. I'll post a PR for evaluation.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 8 months