[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/4/18 9:43 AM:
---------------------------------------------------------
The 8888 port was added to my YAML by Ken, to make SRV based discovery work at all. Agreed, it's not needed when using A records.
So based on your conclusion, how about the following:
* I add a new attribute {{use_dns_ports}} to DNS_PING. It is ignored when A records are used.
* When SRV records are used: when true and the ports are not 0, then we'll use the ports returned by the SRV DNS query, otherwise we'll use the transport ports (plus port_range)
WDYT?
was (Author: belaban):
The 8888 port was added to my YAML by Ken, to make SRV based discovery work at all. Agreed, it's not needed when using A records.
So based on your conclusion, how about the following:
* I add a new attribute {{use_dns_ports}} to DNS_PING. It is ignored when A records are used.
* When SRV records are used: when true and the ports are not 0, then we'll use the ported returned by the SRV DNS query, otherwise we'll use the transport ports (plus port_range)
WDYT?
> 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
>
> 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:
--------------------------------
The 8888 port was added to my YAML by Ken, to make SRV based discovery work at all. Agreed, it's not needed when using A records.
So based on your conclusion, how about the following:
* I add a new attribute {{use_dns_ports}} to DNS_PING. It is ignored when A records are used.
* When SRV records are used: when true and the ports are not 0, then we'll use the ported returned by the SRV DNS query, otherwise we'll use the transport ports (plus port_range)
WDYT?
> 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
>
> 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] (LOGMGR-218) JBoss Logmanager is incompatibile with -Xbootclasspath and JDK 11
by James Perkins (Jira)
[ https://issues.jboss.org/browse/LOGMGR-218?page=com.atlassian.jira.plugin... ]
James Perkins updated LOGMGR-218:
---------------------------------
Git Pull Request: https://github.com/jboss-logging/jboss-logmanager/pull/216, https://github.com/jboss-logging/jboss-logmanager/pull/217, https://github.com/jboss-logging/jboss-logmanager/pull/218 (was: https://github.com/jboss-logging/jboss-logmanager/pull/216, https://github.com/jboss-logging/jboss-logmanager/pull/217)
> JBoss Logmanager is incompatibile with -Xbootclasspath and JDK 11
> -----------------------------------------------------------------
>
> Key: LOGMGR-218
> URL: https://issues.jboss.org/browse/LOGMGR-218
> Project: JBoss Log Manager
> Issue Type: Bug
> Reporter: Brian Stansberry
> Priority: Critical
>
> The current logmanager implementation is incompatible with use with the -Xbootclasspath/a option on JDK 11. The is because it is a multi-release jar which is incompatible with -Xbootclasspath/a. This is problematic because to allow Java Agents to work with JBoss Modules based applications (i.e. WildFly and derivatives) often it is necessary to include logmanager in -Xbootclasspath/a .
> Here's me starting WildFly with a -Xbootclasspath/a setting and JDK 11:
> {code}
> $ build/target/wildfly-core-7.0.0.CR2-SNAPSHOT/bin/standalone.sh
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /Users/bstansberry/dev/wildfly/wildfly-core/build/target/wildfly-core-7.0.0.CR2-SNAPSHOT
> JAVA: /Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java
> JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman,org.jboss.logmanager -Djava.awt.headless=true -Xbootclasspath/a:/Users/bstansberry/dev/wildfly/wildfly-core/dist/target/wildfly-core-7.0.0.CR2-SNAPSHOT/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-2.1.5.Final.jar -Djava.util.logging.manager=org.jboss.logmanager.LogManager --add-exports=java.base/sun.nio.ch=ALL-UNNAMED --add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED --add-exports=jdk.unsupported/sun.reflect=ALL-UNNAMED --add-modules=java.se
> =========================================================================
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.jboss.logmanager.LogLevelInitTask to constructor java.util.logging.Level$KnownLevel(java.util.logging.Level)
> WARNING: Please consider reporting this to the maintainers of org.jboss.logmanager.LogLevelInitTask
> WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
> at org.jboss.logmanager.Logger.getLogger(Logger.java:57)
> at org.jboss.as.server@7.0.0.CR2-SNAPSHOT//org.jboss.as.server.Main.main(Main.java:89)
> at org.jboss.modules.Module.run(Module.java:352)
> at org.jboss.modules.Module.run(Module.java:320)
> at org.jboss.modules.Main.main(Main.java:593)
> {code}
> Right now jboss-logmanager is a multi-release jar. But, per the MR jar spec (https://openjdk.java.net/jeps/238) that is incompatible with -Xbootclasspath:
> {quote}
> Multi-release jars and the boot loader
> Multi-release JARs are not supported by the boot loader (for example, when a multi-release JAR file is declared with the -Xbootclasspath/a option). Such support would complicate the boot loader implementation for what is considered a rare use-case.
> {quote}
> At this point I've identified two java agents that are commonly used with WildFly derived apps that cannot be installed in a JDK 11 environment: Hawkular and the Prometheus jmx-exporter. The former I could perhaps work around (i.e. don't install it with JDK 11) as it's use is deprecated. But being able to use of jmx-exporter is quite important.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (LOGMGR-218) JBoss Logmanager is incompatibile with -Xbootclasspath and JDK 11
by James Perkins (Jira)
[ https://issues.jboss.org/browse/LOGMGR-218?page=com.atlassian.jira.plugin... ]
James Perkins reassigned LOGMGR-218:
------------------------------------
Assignee: James Perkins
> JBoss Logmanager is incompatibile with -Xbootclasspath and JDK 11
> -----------------------------------------------------------------
>
> Key: LOGMGR-218
> URL: https://issues.jboss.org/browse/LOGMGR-218
> Project: JBoss Log Manager
> Issue Type: Bug
> Reporter: Brian Stansberry
> Assignee: James Perkins
> Priority: Critical
>
> The current logmanager implementation is incompatible with use with the -Xbootclasspath/a option on JDK 11. The is because it is a multi-release jar which is incompatible with -Xbootclasspath/a. This is problematic because to allow Java Agents to work with JBoss Modules based applications (i.e. WildFly and derivatives) often it is necessary to include logmanager in -Xbootclasspath/a .
> Here's me starting WildFly with a -Xbootclasspath/a setting and JDK 11:
> {code}
> $ build/target/wildfly-core-7.0.0.CR2-SNAPSHOT/bin/standalone.sh
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /Users/bstansberry/dev/wildfly/wildfly-core/build/target/wildfly-core-7.0.0.CR2-SNAPSHOT
> JAVA: /Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java
> JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman,org.jboss.logmanager -Djava.awt.headless=true -Xbootclasspath/a:/Users/bstansberry/dev/wildfly/wildfly-core/dist/target/wildfly-core-7.0.0.CR2-SNAPSHOT/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-2.1.5.Final.jar -Djava.util.logging.manager=org.jboss.logmanager.LogManager --add-exports=java.base/sun.nio.ch=ALL-UNNAMED --add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED --add-exports=jdk.unsupported/sun.reflect=ALL-UNNAMED --add-modules=java.se
> =========================================================================
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.jboss.logmanager.LogLevelInitTask to constructor java.util.logging.Level$KnownLevel(java.util.logging.Level)
> WARNING: Please consider reporting this to the maintainers of org.jboss.logmanager.LogLevelInitTask
> WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
> at org.jboss.logmanager.Logger.getLogger(Logger.java:57)
> at org.jboss.as.server@7.0.0.CR2-SNAPSHOT//org.jboss.as.server.Main.main(Main.java:89)
> at org.jboss.modules.Module.run(Module.java:352)
> at org.jboss.modules.Module.run(Module.java:320)
> at org.jboss.modules.Main.main(Main.java:593)
> {code}
> Right now jboss-logmanager is a multi-release jar. But, per the MR jar spec (https://openjdk.java.net/jeps/238) that is incompatible with -Xbootclasspath:
> {quote}
> Multi-release jars and the boot loader
> Multi-release JARs are not supported by the boot loader (for example, when a multi-release JAR file is declared with the -Xbootclasspath/a option). Such support would complicate the boot loader implementation for what is considered a rare use-case.
> {quote}
> At this point I've identified two java agents that are commonly used with WildFly derived apps that cannot be installed in a JDK 11 environment: Hawkular and the Prometheus jmx-exporter. The former I could perhaps work around (i.e. don't install it with JDK 11) as it's use is deprecated. But being able to use of jmx-exporter is quite important.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-7232) Add support for Elytron provided SSLContexts in Artemis
by ehsavoie Hugonnet (Jira)
[ https://issues.jboss.org/browse/WFLY-7232?page=com.atlassian.jira.plugin.... ]
ehsavoie Hugonnet reassigned WFLY-7232:
---------------------------------------
Assignee: ehsavoie Hugonnet (was: Jeff Mesnil)
> Add support for Elytron provided SSLContexts in Artemis
> -------------------------------------------------------
>
> Key: WFLY-7232
> URL: https://issues.jboss.org/browse/WFLY-7232
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS
> Reporter: Stefan Guilhen
> Assignee: ehsavoie Hugonnet
> Priority: Major
> Labels: affects_elytron
>
> SSL in messaging is handled by Artemis and it is enabled by a set of properties inserted into the acceptor/connector configuration. Ideally we should be able to change Artemis so that it would obtain an SSLContext that is ready to use from Elytron instead of relying on a set of properties to set up an SSLContext itself. This would help keep all SSL related configuration centralized in the Elytron subsystem and should simplify the configuration for SSL.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-7036) Add MQTT protocol support for JMS
by ehsavoie Hugonnet (Jira)
[ https://issues.jboss.org/browse/WFLY-7036?page=com.atlassian.jira.plugin.... ]
ehsavoie Hugonnet reassigned WFLY-7036:
---------------------------------------
Assignee: ehsavoie Hugonnet (was: Jeff Mesnil)
> Add MQTT protocol support for JMS
> ---------------------------------
>
> Key: WFLY-7036
> URL: https://issues.jboss.org/browse/WFLY-7036
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS
> Affects Versions: 10.1.0.Final
> Reporter: Juraj Veverka
> Assignee: ehsavoie Hugonnet
> Priority: Major
>
> It would be great if MQTT protocol is supported by JMS subsystem in WildFly AS. As of WildFly 10, ActiveMQ is used as JMS implementation in WildFly AS. ActiveMQ supports MQTT protocol, but if I try to add remote-acceptor in <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
> <remote-acceptor name="netty-acceptor-mqtt" socket-binding="messaging-mqtt">
> <param name="protocols" value="MQTT,CORE"/>
> </remote-acceptor>
> When WildFly is started, I can see following log statement:
> 22:55:48,487 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 64) AMQ221020: Started Acceptor at 127.0.0.1:7998 for protocols [CORE,AMQP,HORNETQ,STOMP]
> which means that MQTT protocol is not supportred, instead CORE,AMQP,HORNETQ,STOMP are activated.
> MQTT is used by IoT devices, it would be nice if WildFly 10.2.0 AS has out-of-the-box support.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-8579) Topic messages are sent to all shared non-durable subscription participants
by ehsavoie Hugonnet (Jira)
[ https://issues.jboss.org/browse/WFLY-8579?page=com.atlassian.jira.plugin.... ]
ehsavoie Hugonnet reassigned WFLY-8579:
---------------------------------------
Assignee: ehsavoie Hugonnet (was: Jeff Mesnil)
> Topic messages are sent to all shared non-durable subscription participants
> ---------------------------------------------------------------------------
>
> Key: WFLY-8579
> URL: https://issues.jboss.org/browse/WFLY-8579
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.1.0.Final
> Reporter: Scott Van Wart
> Assignee: ehsavoie Hugonnet
> Priority: Major
> Attachments: duplicate-shared.zip
>
>
> I have two MDBs with a subscription to a topic. The same clientId and a subscriptionName are specified in the activation config properties for each MDB. subscriptionDurability is omitted (defaulted to NonDurable).
> When I send a single message to this topic, both MDBs receive the message. According to JSR 343, 8.3.2 Shared non-durable subscriptions:
> bq. A non-durable shared subscription is used by a client that needs to be able to
> share the work of receiving messages from a non-durable topic subscription
> amongst multiple consumers. A non-durable shared subscription may
> therefore have more than one consumer. *Each message from the subscription will be delivered to only one of the consumers on that
> subscription.*
> Setting the subscriptionDurability property to Durable works as expected (each message is delivered to only one consumer in that subscription).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months