[JBoss JIRA] (WFLY-11387) IllegalStateException when calling MetricsContextService.stop during shutdown sequence
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-11387?page=com.atlassian.jira.plugin... ]
Miroslav Novak updated WFLY-11387:
----------------------------------
Steps to Reproduce:
Steps to reproduce:
{code}
git clone git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-hornetq.git
cd eap-tests-hornetq/scripts/
git checkout master
groovy -DEAP_ZIP_URL=https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-messaging-testing-prepare/560/artifact/jboss-eap.zip PrepareServers7.groovy
export WORKSPACE=$PWD
export JBOSS_HOME_1=$WORKSPACE/server1/jboss-eap
export JBOSS_HOME_2=$WORKSPACE/server2/jboss-eap
export JBOSS_HOME_3=$WORKSPACE/server3/jboss-eap
export JBOSS_HOME_4=$WORKSPACE/server4/jboss-eap
cd ../jboss-hornetq-testsuite/
mvn clean test -Dtest=CliReloadTest#reloadServerTestWaitForFullReload -Deap7.org.jboss.qa.hornetq.apps.clients.version=7.1543611166-SNAPSHOT | tee log
{code}
> IllegalStateException when calling MetricsContextService.stop during shutdown sequence
> --------------------------------------------------------------------------------------
>
> Key: WFLY-11387
> URL: https://issues.jboss.org/browse/WFLY-11387
> Project: WildFly
> Issue Type: Bug
> Components: MP Metrics
> Affects Versions: 15.0.0.Beta1
> Reporter: Rostislav Svoboda
> Assignee: Jeff Mesnil
> Priority: Critical
> Fix For: 15.0.0.Final
>
>
> IllegalStateException when calling MetricsContextService.stop during shutdown sequence
> This doesn't happen regularly, it happened to me like once from 5 shutdowns. I saw the warning 3 times today.
> "not happening always" is because of parallelism in shutdown/boot of WF/EAP
> I did slight misconfiguration on purpose, but not sure if it's related or not
> {code}
> /subsystem=microprofile-metrics-smallrye/:write-attribute(name=exposed-subsystems, value=["batch_jberet"])
> {code}
> Stacktrace is this:
> {code}
> 09:53:23,883 WARN [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000004: Failure during stop of service jboss.extension.metrics.context: java.lang.IllegalStateException
> at org.jboss.as.domain-http-interface@7.0.0.Beta1//org.jboss.as.domain.http.server.ManagementHttpServer.removeContext(ManagementHttpServer.java:234)
> at org.jboss.as.server@7.0.0.Beta1//org.jboss.as.server.mgmt.UndertowHttpManagementService$1.removeContext(UndertowHttpManagementService.java:144)
> at org.wildfly.extension.microprofile.metrics-smallrye@15.0.0.CR1-SNAPSHOT//org.wildfly.extension.microprofile.metrics.MetricsContextService.stop(MetricsContextService.java:131)
> at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1794)
> at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$StopTask.execute(ServiceControllerImpl.java:1763)
> at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558)
> at org.jboss.threads@2.3.2.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1364)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 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:
--------------------------------
[~sebastian.laskawiec] So how does Kubernetes DNS even *know* of the JGroups ports? JGroups might even pick a completely random port, e.g. when {{FD_SOCK.bind_port =0}}.
Are you saying that the DNS maps *all* (UDP and TCP) ports of a process running in a container to other, random ports? Would that only happen with SRV records?
Can you confirm that this is *not* for the ports configured in the YAML, e.g.
{noformat}
publishNotReadyAddresses: true
clusterIP: None
ports:
- name: ping
port: 8888
protocol: TCP
targetPort: 8888
selector:
deploymentConfig: jgrp
{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
>
> 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)
6 years, 3 months
[JBoss JIRA] (WFLY-11374) Master Artemis in Wildfly 10.1.0.Final is not announcing backup when restarted
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-11374?page=com.atlassian.jira.plugin... ]
Miroslav Novak commented on WFLY-11374:
---------------------------------------
[~ev.srinivas] Nice catch :-)
$JBOSS_HOME/standalone/data contains Artemis journal. It seems the problem is that if it's deleted then live does not sync with backup and just starts. Could you create new WFLY jira for it, please?
> Master Artemis in Wildfly 10.1.0.Final is not announcing backup when restarted
> ------------------------------------------------------------------------------
>
> Key: WFLY-11374
> URL: https://issues.jboss.org/browse/WFLY-11374
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.1.0.Final
> Reporter: Srinivas ev
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: active standalone full ha.xml, master and slave log samples on startup.txt, master restart.txt, master shutdown.txt, master-server-linux.log, master-server-windows.log, master.xml, rotateserver_active.log, rotateserver_active.log, rotateserver_backup.log, rotateserver_slave.log, slave standalone full ha.xml, slave-server-linux.log, slave-server-windows.log, slave.xml
>
>
> I have 2 wildfly servers acting as artemis master and slave. I am expecting failback and replication and the related configurations are done for this to work.
> This is working as expected when I have the setup in Windows. Failing in linux RHEL 7.3 machine.
> master in standalone-full-ha.xml - refer master.xml
> slave in standalone-full-ha.xml - refer slave.xml
> In the startup script, I am passing all the values for placeholders of my server host ip's accordingly.
> Test scenario -
> 1. Bring master up.
> 2. Bring slave up.
> 3. slave will announce the backup. (AMQ221031: backup announced).
> 4. Make master down.
> 5. Replication is success.
> 6. Slave is acting as master/live.
> 7. Make master up.
> Issue - master is unable to announce the backup and starts normally as a standalone wildfly.
> This backup announcement works fine in windows and failover also works as expected.
> Please let me know if anything specific required along with this details.
> Artemis jar version - artemis-*****-1.1.0.wildfly-017.jar
> in path - /opt/aor/${my project}/wildfly/modules/system/layers/base/org/apache/activemq/artemis/main
> Few logs I found which may be impacting and I am not clear -
> 1.2018-11-21 14:28:07,238 TRACE [org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionBridge] (Thread-18 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2@38e819b6-2112524495)) Setting up bridge between TransportConfiguration(name=http-connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEnabled=true&httpPpgradeEndpoint=http-acceptor&port=12080&host=135-250-139-30 and ServerLocatorImpl [initialConnectors=[TransportConfiguration(name=http-connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEnabled=true&httpPpgradeEndpoint=http-acceptor&port=12080&host=135-250-139-41], discoveryGroupConfiguration=null]: java.lang.Exception: trace
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionBridge.<init>(ClusterConnectionBridge.java:129)
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl.createNewRecord(ClusterConnectionImpl.java:778)
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl.nodeUP(ClusterConnectionImpl.java:698)
> at org.apache.activemq.artemis.core.client.impl.Topology$1.run(Topology.java:264)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:103)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> 2.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (WFLY-11459) Histogram - registry.histogram(metadata) - IllegalArgumentException
by Rostislav Svoboda (Jira)
[ https://issues.jboss.org/browse/WFLY-11459?page=com.atlassian.jira.plugin... ]
Rostislav Svoboda updated WFLY-11459:
-------------------------------------
Description:
Histogram - registry.histogram(metadata) returns IllegalArgumentException on second invocation of the endpoint. The same app works fine on Open Liberty.
JavaDoc of public abstract Histogram histogram(Metadata metadata); says {{@return a new or pre-existing Histogram}} so on second invocation I should get the pre-existing histogram.
https://github.com/smallrye/smallrye-metrics/issues/42
was:
Histogram - registry.histogram(metadata) returns IllegalArgumentException on second invocation of the endpoint. The same app works fine on Open Liberty.
JavaDoc of public abstract Histogram histogram(Metadata metadata); says @return a new or pre-existing {@link Histogram} so on second invocation I should get the pre-existing histogram.
https://github.com/smallrye/smallrye-metrics/issues/42
> Histogram - registry.histogram(metadata) - IllegalArgumentException
> -------------------------------------------------------------------
>
> Key: WFLY-11459
> URL: https://issues.jboss.org/browse/WFLY-11459
> Project: WildFly
> Issue Type: Bug
> Components: MP Metrics
> Affects Versions: 15.0.0.Final
> Reporter: Rostislav Svoboda
> Priority: Critical
>
> Histogram - registry.histogram(metadata) returns IllegalArgumentException on second invocation of the endpoint. The same app works fine on Open Liberty.
> JavaDoc of public abstract Histogram histogram(Metadata metadata); says {{@return a new or pre-existing Histogram}} so on second invocation I should get the pre-existing histogram.
> https://github.com/smallrye/smallrye-metrics/issues/42
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months