[JBoss JIRA] (DROOLS-3406) [DMN Designer] Decision Service splitter should be movable
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3406?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-3406:
--------------------------------
Description:
The _splitter_ within a Decision Service is static.
It needs to be movable (vertically) maintaining it's alignment with the Decision Service bounds. At this point we need to either decide to add _result_ decision(s) and _encapsulated_ decisions to the Decision Service by Command (depending on where the node is dropped) or update the Marshaller to determine the type of decision based on its vertical positioning and location of the _splitter_.
h2. Acceptance test
Decision state is updated according to _splitter_ movement. Example if area of result decision expanded so some decision belongs there now, this decision should have state _rusult decision_
was:
The _splitter_ within a Decision Service is static.
It needs to be movable (vertically) maintaining it's alignment with the Decision Service bounds. At this point we need to either decide to add _result_ decision(s) and _encapsulated_ decisions to the Decision Service by Command (depending on where the node is dropped) or update the Marshaller to determine the type of decision based on its vertical positioning and location of the _splitter_.
> [DMN Designer] Decision Service splitter should be movable
> ----------------------------------------------------------
>
> Key: DROOLS-3406
> URL: https://issues.jboss.org/browse/DROOLS-3406
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Affects Versions: 7.15.0.Final
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
>
> The _splitter_ within a Decision Service is static.
> It needs to be movable (vertically) maintaining it's alignment with the Decision Service bounds. At this point we need to either decide to add _result_ decision(s) and _encapsulated_ decisions to the Decision Service by Command (depending on where the node is dropped) or update the Marshaller to determine the type of decision based on its vertical positioning and location of the _splitter_.
> h2. Acceptance test
> Decision state is updated according to _splitter_ movement. Example if area of result decision expanded so some decision belongs there now, this decision should have state _rusult decision_
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (DROOLS-3405) [DMN Designer] Add support for collapsing Decision Services
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3405?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-3405:
--------------------------------
Description:
Decision Services are shown _expanded_ by default.
We need to add the ability to collapse Decision Services hiding their content.
h2. Acceptance test
Collapsed/Expanded state saved between saving and reopening
was:
Decision Services are shown _expanded_ by default.
We need to add the ability to collapse Decision Services hiding their content.
> [DMN Designer] Add support for collapsing Decision Services
> -----------------------------------------------------------
>
> Key: DROOLS-3405
> URL: https://issues.jboss.org/browse/DROOLS-3405
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Affects Versions: 7.16.0.Final
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
>
> Decision Services are shown _expanded_ by default.
> We need to add the ability to collapse Decision Services hiding their content.
> h2. Acceptance test
> Collapsed/Expanded state saved between saving and reopening
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (JGRP-2316) DNS_PING is not using correct ports with SRV based service discovery
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2316?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2316 at 12/5/18 4:59 AM:
---------------------------------------------------------
Hmm, still testing SRV records, and dig returns different information some time, e.g.:
{noformat}
bash-4.4$ dig _ping._tcp.jgrp.default.svc.cluster.local SRV
; <<>> DiG 9.12.3 <<>> _ping._tcp.jgrp.default.svc.cluster.local SRV
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35492
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 4
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 8295af9d7f7effee (echoed)
;; QUESTION SECTION:
;_ping._tcp.jgrp.default.svc.cluster.local. IN SRV
;; ANSWER SECTION:
_ping._tcp.jgrp.default.svc.cluster.local. 5 IN SRV 0 33 7800 172-17-0-5.jgrp.default.svc.cluster.local.
_ping._tcp.jgrp.default.svc.cluster.local. 5 IN SRV 0 33 7800 172-17-0-6.jgrp.default.svc.cluster.local.
_ping._tcp.jgrp.default.svc.cluster.local. 5 IN SRV 0 33 7800 172-17-0-7.jgrp.default.svc.cluster.local.
;; ADDITIONAL SECTION:
172-17-0-5.jgrp.default.svc.cluster.local. 5 IN A 172.17.0.5
172-17-0-7.jgrp.default.svc.cluster.local. 5 IN A 172.17.0.7
172-17-0-6.jgrp.default.svc.cluster.local. 5 IN A 172.17.0.6
;; Query time: 0 msec
;; SERVER: 10.96.0.10#53(10.96.0.10)
;; WHEN: Wed Dec 05 09:52:13 UTC 2018
;; MSG SIZE rcvd: 559
{noformat}
{noformat}
bash-4.4$ dig _ping._tcp.jgrp.default.svc.cluster.local SRV
; <<>> DiG 9.12.3 <<>> _ping._tcp.jgrp.default.svc.cluster.local SRV
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25639
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3
;; QUESTION SECTION:
;_ping._tcp.jgrp.default.svc.cluster.local. IN SRV
;; ANSWER SECTION:
_ping._tcp.jgrp.default.svc.cluster.local. 30 IN SRV 10 33 7800 3139376166613530.jgrp.default.svc.cluster.local.
_ping._tcp.jgrp.default.svc.cluster.local. 30 IN SRV 10 33 7800 3939363536326462.jgrp.default.svc.cluster.local.
_ping._tcp.jgrp.default.svc.cluster.local. 30 IN SRV 10 33 7800 36393633363232.jgrp.default.svc.cluster.local.
;; ADDITIONAL SECTION:
3139376166613530.jgrp.default.svc.cluster.local. 30 IN A 172.17.0.5
3939363536326462.jgrp.default.svc.cluster.local. 30 IN A 172.17.0.6
36393633363232.jgrp.default.svc.cluster.local. 30 IN A 172.17.0.7
;; Query time: 0 msec
;; SERVER: 10.96.0.10#53(10.96.0.10)
;; WHEN: Wed Dec 05 09:52:35 UTC 2018
;; MSG SIZE rcvd: 216
{noformat}
So, some time the ANSWER section returns the dotted-decimal address connected via dashes, e.g. {{172-17-0-5.jgrp.default.svc.cluster.local.}}, and sometimes it returns {{3139376166613530.jgrp.default.svc.cluster.local.}}.
Pinging the returned addresses from the {{ANSWER}} section fails 50% of the times. We need to investigate why. Q: would it be possible to get the answers from the {{ADDITIONAL}} section, because it always seems to return the correct IP addresses?
was (Author: belaban):
Hmm, still testing SRV records, and dig returns different information some time, e.g.:
{noformat}
bash-4.4$ dig _ping._tcp.jgrp.default.svc.cluster.local SRV
; <<>> DiG 9.12.3 <<>> _ping._tcp.jgrp.default.svc.cluster.local SRV
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35492
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 4
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 8295af9d7f7effee (echoed)
;; QUESTION SECTION:
;_ping._tcp.jgrp.default.svc.cluster.local. IN SRV
;; ANSWER SECTION:
_ping._tcp.jgrp.default.svc.cluster.local. 5 IN SRV 0 33 7800 172-17-0-5.jgrp.default.svc.cluster.local.
_ping._tcp.jgrp.default.svc.cluster.local. 5 IN SRV 0 33 7800 172-17-0-6.jgrp.default.svc.cluster.local.
_ping._tcp.jgrp.default.svc.cluster.local. 5 IN SRV 0 33 7800 172-17-0-7.jgrp.default.svc.cluster.local.
;; ADDITIONAL SECTION:
172-17-0-5.jgrp.default.svc.cluster.local. 5 IN A 172.17.0.5
172-17-0-7.jgrp.default.svc.cluster.local. 5 IN A 172.17.0.7
172-17-0-6.jgrp.default.svc.cluster.local. 5 IN A 172.17.0.6
;; Query time: 0 msec
;; SERVER: 10.96.0.10#53(10.96.0.10)
;; WHEN: Wed Dec 05 09:52:13 UTC 2018
;; MSG SIZE rcvd: 559
{noformat}
{noformat}
bash-4.4$ dig _ping._tcp.jgrp.default.svc.cluster.local SRV
; <<>> DiG 9.12.3 <<>> _ping._tcp.jgrp.default.svc.cluster.local SRV
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25639
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3
;; QUESTION SECTION:
;_ping._tcp.jgrp.default.svc.cluster.local. IN SRV
;; ANSWER SECTION:
_ping._tcp.jgrp.default.svc.cluster.local. 30 IN SRV 10 33 7800 3139376166613530.jgrp.default.svc.cluster.local.
_ping._tcp.jgrp.default.svc.cluster.local. 30 IN SRV 10 33 7800 3939363536326462.jgrp.default.svc.cluster.local.
_ping._tcp.jgrp.default.svc.cluster.local. 30 IN SRV 10 33 7800 36393633363232.jgrp.default.svc.cluster.local.
;; ADDITIONAL SECTION:
3139376166613530.jgrp.default.svc.cluster.local. 30 IN A 172.17.0.5
3939363536326462.jgrp.default.svc.cluster.local. 30 IN A 172.17.0.6
36393633363232.jgrp.default.svc.cluster.local. 30 IN A 172.17.0.7
;; Query time: 0 msec
;; SERVER: 10.96.0.10#53(10.96.0.10)
;; WHEN: Wed Dec 05 09:52:35 UTC 2018
;; MSG SIZE rcvd: 216
{noformat}
So, some time the ANSWER section returns the dotted-decimal address connected via dashes, e.g. {{172-17-0-5.jgrp.default.svc.cluster.local.}}, and sometimes it returns {{3139376166613530.jgrp.default.svc.cluster.local.}}.
> DNS_PING is not using correct ports with SRV based service discovery
> --------------------------------------------------------------------
>
> Key: JGRP-2316
> URL: https://issues.jboss.org/browse/JGRP-2316
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Reporter: dmcnair
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.16
>
>
> This is a follow-up to JGRP-2296 - which changed `DefaultDNSResolver.java` to preserve the port for SRV records. While that change is working as desired, `DNS_PING.java` is not using the port when doing member discovery.
> Here are the log entries using *4.0.15*
> {noformat}
> 2018-11-29 21:37:41,561 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) Entries collected from DNS (in 5 ms): [172.29.11.50:27106, 172.29.11.50:27105]
> 2018-11-29 21:37:41,562 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) 982d38761cba: sending discovery requests to hosts [172.29.11.50:27106, 172.29.11.50:27105] on ports [7600 .. 7600]
> {noformat}
> Since the port was found via the SRV record, it should be used instead of the *transportPort* port.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (JGRP-2316) DNS_PING is not using correct ports with SRV based service discovery
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2316?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2316 at 12/5/18 4:58 AM:
---------------------------------------------------------
Hmm, still testing SRV records, and dig returns different information some time, e.g.:
{noformat}
bash-4.4$ dig _ping._tcp.jgrp.default.svc.cluster.local SRV
; <<>> DiG 9.12.3 <<>> _ping._tcp.jgrp.default.svc.cluster.local SRV
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35492
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 4
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 8295af9d7f7effee (echoed)
;; QUESTION SECTION:
;_ping._tcp.jgrp.default.svc.cluster.local. IN SRV
;; ANSWER SECTION:
_ping._tcp.jgrp.default.svc.cluster.local. 5 IN SRV 0 33 7800 172-17-0-5.jgrp.default.svc.cluster.local.
_ping._tcp.jgrp.default.svc.cluster.local. 5 IN SRV 0 33 7800 172-17-0-6.jgrp.default.svc.cluster.local.
_ping._tcp.jgrp.default.svc.cluster.local. 5 IN SRV 0 33 7800 172-17-0-7.jgrp.default.svc.cluster.local.
;; ADDITIONAL SECTION:
172-17-0-5.jgrp.default.svc.cluster.local. 5 IN A 172.17.0.5
172-17-0-7.jgrp.default.svc.cluster.local. 5 IN A 172.17.0.7
172-17-0-6.jgrp.default.svc.cluster.local. 5 IN A 172.17.0.6
;; Query time: 0 msec
;; SERVER: 10.96.0.10#53(10.96.0.10)
;; WHEN: Wed Dec 05 09:52:13 UTC 2018
;; MSG SIZE rcvd: 559
{noformat}
{noformat}
bash-4.4$ dig _ping._tcp.jgrp.default.svc.cluster.local SRV
; <<>> DiG 9.12.3 <<>> _ping._tcp.jgrp.default.svc.cluster.local SRV
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25639
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3
;; QUESTION SECTION:
;_ping._tcp.jgrp.default.svc.cluster.local. IN SRV
;; ANSWER SECTION:
_ping._tcp.jgrp.default.svc.cluster.local. 30 IN SRV 10 33 7800 3139376166613530.jgrp.default.svc.cluster.local.
_ping._tcp.jgrp.default.svc.cluster.local. 30 IN SRV 10 33 7800 3939363536326462.jgrp.default.svc.cluster.local.
_ping._tcp.jgrp.default.svc.cluster.local. 30 IN SRV 10 33 7800 36393633363232.jgrp.default.svc.cluster.local.
;; ADDITIONAL SECTION:
3139376166613530.jgrp.default.svc.cluster.local. 30 IN A 172.17.0.5
3939363536326462.jgrp.default.svc.cluster.local. 30 IN A 172.17.0.6
36393633363232.jgrp.default.svc.cluster.local. 30 IN A 172.17.0.7
;; Query time: 0 msec
;; SERVER: 10.96.0.10#53(10.96.0.10)
;; WHEN: Wed Dec 05 09:52:35 UTC 2018
;; MSG SIZE rcvd: 216
{noformat}
So, some time the ANSWER section returns the dotted-decimal address connected via dashes, e.g. {{172-17-0-5.jgrp.default.svc.cluster.local.}}, and sometimes it returns {{3139376166613530.jgrp.default.svc.cluster.local.}}.
was (Author: belaban):
Hmm, still testing SRV records, and dig returns different information some time, e.g.:
{noformat}
bash-4.4$ dig _ping._tcp.jgrp.default.svc.cluster.local SRV
; <<>> DiG 9.12.3 <<>> _ping._tcp.jgrp.default.svc.cluster.local SRV
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35492
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 4
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 8295af9d7f7effee (echoed)
;; QUESTION SECTION:
;_ping._tcp.jgrp.default.svc.cluster.local. IN SRV
;; ANSWER SECTION:
_ping._tcp.jgrp.default.svc.cluster.local. 5 IN SRV 0 33 7800 172-17-0-5.jgrp.default.svc.cluster.local.
_ping._tcp.jgrp.default.svc.cluster.local. 5 IN SRV 0 33 7800 172-17-0-6.jgrp.default.svc.cluster.local.
_ping._tcp.jgrp.default.svc.cluster.local. 5 IN SRV 0 33 7800 172-17-0-7.jgrp.default.svc.cluster.local.
;; ADDITIONAL SECTION:
172-17-0-5.jgrp.default.svc.cluster.local. 5 IN A 172.17.0.5
172-17-0-7.jgrp.default.svc.cluster.local. 5 IN A 172.17.0.7
172-17-0-6.jgrp.default.svc.cluster.local. 5 IN A 172.17.0.6
;; Query time: 0 msec
;; SERVER: 10.96.0.10#53(10.96.0.10)
;; WHEN: Wed Dec 05 09:52:13 UTC 2018
;; MSG SIZE rcvd: 559
{noformat}
bash-4.4$ dig _ping._tcp.jgrp.default.svc.cluster.local SRV
; <<>> DiG 9.12.3 <<>> _ping._tcp.jgrp.default.svc.cluster.local SRV
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25639
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3
;; QUESTION SECTION:
;_ping._tcp.jgrp.default.svc.cluster.local. IN SRV
;; ANSWER SECTION:
_ping._tcp.jgrp.default.svc.cluster.local. 30 IN SRV 10 33 7800 3139376166613530.jgrp.default.svc.cluster.local.
_ping._tcp.jgrp.default.svc.cluster.local. 30 IN SRV 10 33 7800 3939363536326462.jgrp.default.svc.cluster.local.
_ping._tcp.jgrp.default.svc.cluster.local. 30 IN SRV 10 33 7800 36393633363232.jgrp.default.svc.cluster.local.
;; ADDITIONAL SECTION:
3139376166613530.jgrp.default.svc.cluster.local. 30 IN A 172.17.0.5
3939363536326462.jgrp.default.svc.cluster.local. 30 IN A 172.17.0.6
36393633363232.jgrp.default.svc.cluster.local. 30 IN A 172.17.0.7
;; Query time: 0 msec
;; SERVER: 10.96.0.10#53(10.96.0.10)
;; WHEN: Wed Dec 05 09:52:35 UTC 2018
;; MSG SIZE rcvd: 216
{noformat}
So, some time the ANSWER section returns the dotted-decimal address connected via dashes, e.g. {{172-17-0-5.jgrp.default.svc.cluster.local.}}, and sometimes it returns {{3139376166613530.jgrp.default.svc.cluster.local.}}.
{noformat}
> DNS_PING is not using correct ports with SRV based service discovery
> --------------------------------------------------------------------
>
> Key: JGRP-2316
> URL: https://issues.jboss.org/browse/JGRP-2316
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Reporter: dmcnair
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.16
>
>
> This is a follow-up to JGRP-2296 - which changed `DefaultDNSResolver.java` to preserve the port for SRV records. While that change is working as desired, `DNS_PING.java` is not using the port when doing member discovery.
> Here are the log entries using *4.0.15*
> {noformat}
> 2018-11-29 21:37:41,561 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) Entries collected from DNS (in 5 ms): [172.29.11.50:27106, 172.29.11.50:27105]
> 2018-11-29 21:37:41,562 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) 982d38761cba: sending discovery requests to hosts [172.29.11.50:27106, 172.29.11.50:27105] on ports [7600 .. 7600]
> {noformat}
> Since the port was found via the SRV record, it should be used instead of the *transportPort* port.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (JGRP-2316) DNS_PING is not using correct ports with SRV based service discovery
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2316?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2316:
--------------------------------
Hmm, still testing SRV records, and dig returns different information some time, e.g.:
{noformat}
bash-4.4$ dig _ping._tcp.jgrp.default.svc.cluster.local SRV
; <<>> DiG 9.12.3 <<>> _ping._tcp.jgrp.default.svc.cluster.local SRV
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35492
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 4
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 8295af9d7f7effee (echoed)
;; QUESTION SECTION:
;_ping._tcp.jgrp.default.svc.cluster.local. IN SRV
;; ANSWER SECTION:
_ping._tcp.jgrp.default.svc.cluster.local. 5 IN SRV 0 33 7800 172-17-0-5.jgrp.default.svc.cluster.local.
_ping._tcp.jgrp.default.svc.cluster.local. 5 IN SRV 0 33 7800 172-17-0-6.jgrp.default.svc.cluster.local.
_ping._tcp.jgrp.default.svc.cluster.local. 5 IN SRV 0 33 7800 172-17-0-7.jgrp.default.svc.cluster.local.
;; ADDITIONAL SECTION:
172-17-0-5.jgrp.default.svc.cluster.local. 5 IN A 172.17.0.5
172-17-0-7.jgrp.default.svc.cluster.local. 5 IN A 172.17.0.7
172-17-0-6.jgrp.default.svc.cluster.local. 5 IN A 172.17.0.6
;; Query time: 0 msec
;; SERVER: 10.96.0.10#53(10.96.0.10)
;; WHEN: Wed Dec 05 09:52:13 UTC 2018
;; MSG SIZE rcvd: 559
{noformat}
bash-4.4$ dig _ping._tcp.jgrp.default.svc.cluster.local SRV
; <<>> DiG 9.12.3 <<>> _ping._tcp.jgrp.default.svc.cluster.local SRV
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25639
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3
;; QUESTION SECTION:
;_ping._tcp.jgrp.default.svc.cluster.local. IN SRV
;; ANSWER SECTION:
_ping._tcp.jgrp.default.svc.cluster.local. 30 IN SRV 10 33 7800 3139376166613530.jgrp.default.svc.cluster.local.
_ping._tcp.jgrp.default.svc.cluster.local. 30 IN SRV 10 33 7800 3939363536326462.jgrp.default.svc.cluster.local.
_ping._tcp.jgrp.default.svc.cluster.local. 30 IN SRV 10 33 7800 36393633363232.jgrp.default.svc.cluster.local.
;; ADDITIONAL SECTION:
3139376166613530.jgrp.default.svc.cluster.local. 30 IN A 172.17.0.5
3939363536326462.jgrp.default.svc.cluster.local. 30 IN A 172.17.0.6
36393633363232.jgrp.default.svc.cluster.local. 30 IN A 172.17.0.7
;; Query time: 0 msec
;; SERVER: 10.96.0.10#53(10.96.0.10)
;; WHEN: Wed Dec 05 09:52:35 UTC 2018
;; MSG SIZE rcvd: 216
{noformat}
So, some time the ANSWER section returns the dotted-decimal address connected via dashes, e.g. {{172-17-0-5.jgrp.default.svc.cluster.local.}}, and sometimes it returns {{3139376166613530.jgrp.default.svc.cluster.local.}}.
{noformat}
> DNS_PING is not using correct ports with SRV based service discovery
> --------------------------------------------------------------------
>
> Key: JGRP-2316
> URL: https://issues.jboss.org/browse/JGRP-2316
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Reporter: dmcnair
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.16
>
>
> This is a follow-up to JGRP-2296 - which changed `DefaultDNSResolver.java` to preserve the port for SRV records. While that change is working as desired, `DNS_PING.java` is not using the port when doing member discovery.
> Here are the log entries using *4.0.15*
> {noformat}
> 2018-11-29 21:37:41,561 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) Entries collected from DNS (in 5 ms): [172.29.11.50:27106, 172.29.11.50:27105]
> 2018-11-29 21:37:41,562 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) 982d38761cba: sending discovery requests to hosts [172.29.11.50:27106, 172.29.11.50:27105] on ports [7600 .. 7600]
> {noformat}
> Since the port was found via the SRV record, it should be used instead of the *transportPort* port.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months