[JBoss JIRA] (WFLY-11691) Default no-request-timeout value on HTTP(s) listeners seems to be causing unexpected timeouts
by jaikiran pai (Jira)
[ https://issues.jboss.org/browse/WFLY-11691?page=com.atlassian.jira.plugin... ]
jaikiran pai resolved WFLY-11691.
---------------------------------
Fix Version/s: 16.0.0.Final
Resolution: Done
> Default no-request-timeout value on HTTP(s) listeners seems to be causing unexpected timeouts
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-11691
> URL: https://issues.jboss.org/browse/WFLY-11691
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 14.0.1.Final, 15.0.1.Final
> Reporter: jaikiran pai
> Assignee: Stuart Douglas
> Priority: Major
> Fix For: 16.0.0.Final
>
>
> More than one users[1][2] have reported that they are seeing odd timeout issues with HTTP(S) calls in their applications. Based on the discussion in those threads, I believe there are 2 issues here, one in Undertow and one in WildFly.
> In Undertow, I believe there's a bug which when using HTTP 1.1, in some cases, ends up marking an in-progress request as timed out (based on the value set for no-request-timeout). Thread[1] has more details on how to reproduce such a case, but like I note in that thread, I don't think the cipher suites is what's causing this. I haven't found the time to create a simpler reproducible application for that one yet and I haven't yet created a Undertow JIRA for it.
> In WildFly, I think the default value of 60 seconds for no-request-timeout on the HTTP(s) listeners, is arbitrary and even too low. IMO, this probably should default to -1 (i.e. no specific timeout) and let the users decide what value makes sense in their setup.
> [1] https://developer.jboss.org/thread/279379
> [2] https://developer.jboss.org/thread/279261
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (WFLY-11691) Default no-request-timeout value on HTTP(s) listeners seems to be causing unexpected timeouts
by jaikiran pai (Jira)
[ https://issues.jboss.org/browse/WFLY-11691?page=com.atlassian.jira.plugin... ]
jaikiran pai commented on WFLY-11691:
-------------------------------------
I have verified this against the recently released WildFly 16.0.0.Final and I can no longer reproduce this issue there. So it does appear to me that this got fixed as part of:
>>I highly suspect that the fix that Stuart Douglas did for https://issues.jboss.org/browse/UNDERTOW-1486 will solve this part of the problem. My minimal investigation into this issue had led me to suspect that the open listener was being triggered twice in this case.
> Default no-request-timeout value on HTTP(s) listeners seems to be causing unexpected timeouts
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-11691
> URL: https://issues.jboss.org/browse/WFLY-11691
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 14.0.1.Final, 15.0.1.Final
> Reporter: jaikiran pai
> Assignee: Stuart Douglas
> Priority: Major
>
> More than one users[1][2] have reported that they are seeing odd timeout issues with HTTP(S) calls in their applications. Based on the discussion in those threads, I believe there are 2 issues here, one in Undertow and one in WildFly.
> In Undertow, I believe there's a bug which when using HTTP 1.1, in some cases, ends up marking an in-progress request as timed out (based on the value set for no-request-timeout). Thread[1] has more details on how to reproduce such a case, but like I note in that thread, I don't think the cipher suites is what's causing this. I haven't found the time to create a simpler reproducible application for that one yet and I haven't yet created a Undertow JIRA for it.
> In WildFly, I think the default value of 60 seconds for no-request-timeout on the HTTP(s) listeners, is arbitrary and even too low. IMO, this probably should default to -1 (i.e. no specific timeout) and let the users decide what value makes sense in their setup.
> [1] https://developer.jboss.org/thread/279379
> [2] https://developer.jboss.org/thread/279261
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (WFCORE-4239) WARN if system-property is already set and is being overridden
by RH Bugzilla Integration (Jira)
[ https://issues.jboss.org/browse/WFCORE-4239?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-4239:
-------------------------------------------------
Chao Wang <chaowan(a)redhat.com> changed the Status of [bug 1654454|https://bugzilla.redhat.com/show_bug.cgi?id=1654454] from ASSIGNED to POST
> WARN if system-property is already set and is being overridden
> --------------------------------------------------------------
>
> Key: WFCORE-4239
> URL: https://issues.jboss.org/browse/WFCORE-4239
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Management
> Reporter: Brad Maxwell
> Assignee: Chao Wang
> Priority: Major
> Fix For: 8.0.0.Beta2, 8.0.0.Final
>
>
> WARN if system-property is already set and is being overridden
> If user sets a system property using the java opts or on the command line and the same system property is defined in the standalone.xml, then the standalone.xml value overrides that passed on the commandline/JAVA_OPTS, a warning would be useful as looking at the logs (and ps), it shows value1 passed on the command line and nothing indicating that the value was changed later.
> JAVA_OPTS="$JAVA_OPTS -Dmy.system.property=value1"
> {code}
> <system-properties>
> <property name="my.system.property" value="value2"/>
> </system-properties>
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (WFLY-11801) PrometheusCollector NPE while adding sample supplier
by Eduardo Martins (Jira)
Eduardo Martins created WFLY-11801:
--------------------------------------
Summary: PrometheusCollector NPE while adding sample supplier
Key: WFLY-11801
URL: https://issues.jboss.org/browse/WFLY-11801
Project: WildFly
Issue Type: Bug
Components: MP Metrics
Affects Versions: 16.0.0.Final
Reporter: Eduardo Martins
Assignee: Eduardo Martins
I see the following NPE frequently when migrating a server to WF16 with CMTOOL:
{code}
Eduardos-Mini:bin emmartins$ ./standalone.sh
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /Users/emmartins/wildfly/cmtool/test/migrations/wildfly-16.0.0.Final/wildfly-15.0.1.Final/target
JAVA: /Library/Java/JavaVirtualMachines/jdk1.8.0_181.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 -Djava.awt.headless=true
=========================================================================
08:47:19,267 INFO [org.jboss.modules] (main) JBoss Modules version 1.9.0.Final
08:47:19,695 INFO [org.jboss.msc] (main) JBoss MSC version 1.4.5.Final
08:47:19,706 INFO [org.jboss.threads] (main) JBoss Threads version 2.3.3.Final
08:47:19,871 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: WildFly Full 16.0.0.Final (WildFly Core 8.0.0.Final) starting
08:47:20,573 INFO [org.wildfly.security] (ServerService Thread Pool -- 23) ELY00001: WildFly Elytron version 1.8.0.Final
08:47:21,101 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
08:47:21,128 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 35) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
08:47:21,215 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
08:47:21,235 INFO [org.xnio] (MSC service thread 1-7) XNIO version 3.6.5.Final
08:47:21,243 INFO [org.xnio.nio] (MSC service thread 1-7) XNIO NIO Implementation Version 3.6.5.Final
08:47:21,284 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 49) WFLYCLINF0001: Activating Infinispan subsystem.
08:47:21,289 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 62) WFLYNAM0001: Activating Naming Subsystem
08:47:21,292 INFO [org.wildfly.extension.microprofile.opentracing] (ServerService Thread Pool -- 61) WFLYTRACEXT0001: Activating MicroProfile OpenTracing Subsystem
08:47:21,296 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 70) WFLYTX0013: The node-identifier attribute on the /subsystem=transactions is set to the default value. This is a danger for environments running multiple servers. Please make sure the attribute value is unique.
08:47:21,310 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 72) WFLYWS0002: Activating WebServices Extension
08:47:21,311 INFO [org.jboss.as.jaxrs] (ServerService Thread Pool -- 51) WFLYRS0016: RESTEasy version 3.6.3.Final
08:47:21,314 INFO [org.wildfly.extension.microprofile.config.smallrye._private] (ServerService Thread Pool -- 58) WFLYCONF0001: Activating WildFly MicroProfile Config Subsystem
08:47:21,315 INFO [org.jboss.as.security] (ServerService Thread Pool -- 68) WFLYSEC0002: Activating Security Subsystem
08:47:21,333 INFO [org.wildfly.extension.microprofile.health.smallrye] (ServerService Thread Pool -- 59) WFLYHEALTH0001: Activating Eclipse MicroProfile Health Subsystem
08:47:21,334 INFO [org.jboss.as.security] (MSC service thread 1-4) WFLYSEC0001: Current PicketBox version=5.0.3.Final
08:47:21,343 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 56) WFLYJSF0007: Activated the following JSF Implementations: [main]
08:47:21,342 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 50) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
08:47:21,349 INFO [org.jboss.as.connector] (MSC service thread 1-6) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.12.Final)
08:47:21,357 INFO [org.wildfly.extension.microprofile.metrics.smallrye] (ServerService Thread Pool -- 60) WFLYMETRICS0001: Activating Eclipse MicroProfile Metrics Subsystem
08:47:21,364 INFO [org.jboss.as.mail.extension] (MSC service thread 1-6) WFLYMAIL0002: Unbound mail session [java:jboss/mail/Default]
08:47:21,367 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0003: Undertow 2.0.19.Final starting
08:47:21,419 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 42) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.4)
08:47:21,429 INFO [io.smallrye.metrics] (MSC service thread 1-5) Converted [2] config entries and added [4] replacements
08:47:21,442 INFO [io.smallrye.metrics] (MSC service thread 1-5) Converted [3] config entries and added [14] replacements
08:47:21,443 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-6) WFLYJCA0018: Started Driver service with driver-name = h2
08:47:21,446 INFO [org.jboss.as.naming] (MSC service thread 1-1) WFLYNAM0003: Starting Naming Service
08:47:21,454 INFO [org.jboss.as.mail.extension] (MSC service thread 1-8) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
08:47:21,482 INFO [org.jboss.remoting] (MSC service thread 1-6) JBoss Remoting version 5.0.8.Final
08:47:21,672 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS]
08:47:21,753 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 71) WFLYUT0014: Creating file handler for path '/Users/emmartins/wildfly/cmtool/test/migrations/wildfly-16.0.0.Final/wildfly-15.0.1.Final/target/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
08:47:21,758 INFO [org.jboss.as.ejb3] (MSC service thread 1-8) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 32 (per class), which is derived from the number of CPUs on this host.
08:47:21,759 INFO [org.jboss.as.ejb3] (MSC service thread 1-3) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 128 (per class), which is derived from thread worker pool sizing.
08:47:21,778 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0012: Started server default-server.
08:47:21,781 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0018: Host default-host starting
08:47:21,885 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080
08:47:21,919 INFO [org.jboss.as.ejb3] (MSC service thread 1-3) WFLYEJB0493: EJB subsystem suspension complete
08:47:21,998 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-4) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
08:47:22,152 INFO [org.jboss.as.patching] (MSC service thread 1-8) WFLYPAT0050: WildFly Full cumulative patch ID is: base, one-off patches include: none
08:47:22,170 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-4) WFLYDM0111: Keystore /Users/emmartins/wildfly/cmtool/test/migrations/wildfly-16.0.0.Final/wildfly-15.0.1.Final/target/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost
08:47:22,173 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-7) WFLYDS0013: Started FileSystemDeploymentService for directory /Users/emmartins/wildfly/cmtool/test/migrations/wildfly-16.0.0.Final/wildfly-15.0.1.Final/target/standalone/deployments
08:47:22,183 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0027: Starting deployment of "cmtool-helloworld6.war" (runtime-name: "cmtool-helloworld6.war")
08:47:22,183 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) WFLYSRV0027: Starting deployment of "cmtool-helloworld5.war" (runtime-name: "cmtool-helloworld5.war")
08:47:22,332 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0006: Undertow HTTPS listener https listening on 127.0.0.1:8443
08:47:22,408 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBossWS 5.2.4.Final (Apache CXF 3.2.7)
08:47:22,932 INFO [org.jboss.weld.deployer] (MSC service thread 1-5) WFLYWELD0003: Processing weld deployment cmtool-helloworld6.war
08:47:22,932 INFO [org.jboss.weld.deployer] (MSC service thread 1-3) WFLYWELD0003: Processing weld deployment cmtool-helloworld5.war
08:47:23,058 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-5) HV000001: Hibernate Validator 6.0.15.Final
08:47:23,477 INFO [org.jboss.weld.Version] (MSC service thread 1-1) WELD-000900: 3.1.0 (Final)
08:47:23,573 INFO [org.infinispan.factories.GlobalComponentRegistry] (MSC service thread 1-2) ISPN000128: Infinispan version: Infinispan 'Infinity Minus ONE +2' 9.4.8.Final
08:47:23,948 INFO [io.smallrye.metrics] (MSC service thread 1-4) MicroProfile: Metrics activated
08:47:23,948 INFO [io.smallrye.metrics] (MSC service thread 1-3) MicroProfile: Metrics activated
08:47:24,086 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 74) WFLYCLINF0002: Started client-mappings cache from ejb container
08:47:24,698 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 74) WFLYUT0021: Registered web context: '/cmtool-helloworld5' for server 'default-server'
08:47:24,698 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 75) WFLYUT0021: Registered web context: '/cmtool-helloworld6' for server 'default-server'
08:47:24,717 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."cmtool-helloworld6.war".metrics: org.jboss.msc.service.StartException in service jboss.deployment.unit."cmtool-helloworld6.war".metrics: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1730)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.NullPointerException
at org.wildfly.extension.microprofile.metrics.PrometheusCollector.addMetricFamilySampleSupplier(PrometheusCollector.java:32)
at org.wildfly.extension.microprofile.metrics.MetricCollector.collectResourceMetrics0(MetricCollector.java:157)
at org.wildfly.extension.microprofile.metrics.MetricCollector.collectResourceMetrics0(MetricCollector.java:166)
at org.wildfly.extension.microprofile.metrics.MetricCollector.collectResourceMetrics0(MetricCollector.java:166)
at org.wildfly.extension.microprofile.metrics.MetricCollector.collectResourceMetrics(MetricCollector.java:92)
at org.wildfly.extension.microprofile.metrics.deployment.DeploymentMetricService.start(DeploymentMetricService.java:54)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1738)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1700)
... 6 more
08:47:24,953 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "cmtool-helloworld6.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"cmtool-helloworld6.war\".metrics" => "Failed to start service
Caused by: java.lang.NullPointerException"}}
08:47:24,966 INFO [org.jboss.as.server] (ServerService Thread Pool -- 43) WFLYSRV0010: Deployed "cmtool-helloworld5.war" (runtime-name : "cmtool-helloworld5.war")
08:47:24,967 INFO [org.jboss.as.server] (ServerService Thread Pool -- 43) WFLYSRV0010: Deployed "cmtool-helloworld6.war" (runtime-name : "cmtool-helloworld6.war")
08:47:24,969 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
WFLYCTL0186: Services which failed to start: service jboss.deployment.unit."cmtool-helloworld6.war".metrics: Failed to start service
08:47:25,032 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
08:47:25,036 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
08:47:25,037 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
08:47:25,037 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: WildFly Full 16.0.0.Final (WildFly Core 8.0.0.Final) started (with errors) in 6202ms - Started 521 of 711 services (1 services failed or missing dependencies, 334 services are lazy, passive or on-demand)
{code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (WFLY-11682) Clustered SLSB membership anomalies when all cluster members removed
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-11682?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz commented on WFLY-11682:
--------------------------------------------
On the server side, the old EJB client implementation classes EJBRemoteConnectorService and VersionOneProtocolChannelReceiver have been replaced by a number of classes which work together to do the same thing: EJBRemoteConnectorService, RemoteEJBService, AssociationService, AssociationImpl and EJBServerChannel.
The VersionOneProtocolChannelReceiver held an instance of RegistryCollector (which holds client mappings entries for each cluster the server is a member of), which allowed supporting membership of multiple clusters at the same time well as notifying the server when a cluster was being removed (registryAdded()/registryRemoved()). A call to registryRemoved() by the last node in the cluster would cause the server to send a message to the client indicating the cluster was removed entirely, and was a way for the last node to clear that cluster's information from the client.
The new arrangement only supports server membership of one cluster and AssociationImpl, rather than holding a reference to RegistryCollector, now only holds a single Registry to store the client mappings for the single cluster this server is a member of. Consequently, unlike before, we have no notification of the last node leaving via the RegistryCollector. We need to recreate this somehow.
We want to send out a CLUSTER_REMOVED message to all connected clients from the last node in the cluster when we are sure that the last node is in fact shutting down. Looking at the dependencies between the various services, we have EJBRemoteConnector -> AssociationService, so that the EJBRemoteConnector will shut down before the AssociationService. Also the EJBRemoteConnector, in its stop() method, shuts down the Endpoint for the Remoting connector, making all channel connections to clients inaccessible thereafter. So it seems the only reasonable place to send out this message is at the beginning of the stop() method of EJBRemoteConnector while the channel connections are still open.
I have implemented this and it works based on my limited testing. I'll push a PR for now so that I can get some feedback.
As Paul noted, this does not solve the problem in the case where the last node crashes (does not get a chance to cleanly shut down) and the only reasonable place to deal with this special case is on the client (somehow).. For now though, i'm making this change available to handle the case of clean shutdown.
Also, i'll implement the missing suspend/resume behavior in another issue. It's unrelated to this one. We should also probably revisit the limitation of single cluster membership at some time soon.
> Clustered SLSB membership anomalies when all cluster members removed
> --------------------------------------------------------------------
>
> Key: WFLY-11682
> URL: https://issues.jboss.org/browse/WFLY-11682
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 15.0.1.Final
> Environment: WildFly running in an n-node cluster with an EJB client sending requests even during the time the cluster is down.
> Reporter: Jörg Bäsner
> Assignee: Richard Achmatowicz
> Priority: Major
> Attachments: node1.txt, node12.txt, node2.txt, node3.txt, playground.zip
>
>
> This description will be based on a 3 node cluster. Cluster node 1 and 2 are configured in the {{PROVIDER_URL}}, node 3 is not.
> The client has a custom ClusterNodeSelector implementation that is printing the {{connectedNodes}} and the {{availableNodes}} and doing a random balancing.
> As long as all nodes are up and running the client is calling EJBs in a balanced way.
> When node1 is shut down, the client get the notification below:
> {code}...
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground
> DEBUG (XNIO-1 task-4) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground
> DEBUG (XNIO-1 task-4) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node1)
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node1)
> ...
> {code}
> Then node2 is shut down. Again the client get the information, see:
> {code}
> ...
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY_NODE_REMOVAL(18) message for (cluster, node) = (ejb, node2)
> ...
> {code}
> Finally node3 is being shut down. Now the client only get the following information:
> {code}
> ...
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_UNAVAILABLE(9) message for module /playground
> ...
> {code}
> This mean the _node3_ is not being informed about the fact that the last node of the cluster has been stopped.
> From this point on the client is always getting {{Caused by: java.net.ConnectException: Connection refused}}
> Now node1 is started again, resulting in the following output for {{connectedNodes}} and the {{availableNodes}}:
> {code}
> ...
> INFO (ThreadPoolTaskExecutor-1) [com.jboss.examples.ejb.CustomClusterNodeSelector] connectedNodes(1) '[node1]', availableNodes(2) '[node3, node1]'
> ...
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (WFLY-11793) JPA EntityManager merge infinite loop - java.lang.StackOverflowError
by Bruno Maioli Martins (Jira)
[ https://issues.jboss.org/browse/WFLY-11793?page=com.atlassian.jira.plugin... ]
Bruno Maioli Martins edited comment on WFLY-11793 at 3/2/19 11:20 AM:
----------------------------------------------------------------------
Scott Marlow, thanks for the response.
I did the steps you suggested, and I was also suspecting Hibernate ORM Core, but the interesting thing is that if I run the same application, but in desktop app, I get satisfactory result.
I added the server log and jstack generated after the failure.
I will investigate the failure better, and report back to the Hibernate ORM Core team.
Thank you
was (Author: brunomaioli):
Scott Marlow, thanks for the response.
I did the steps you suggested, and I was also suspecting Hibernate ORM Core, but the interesting thing is that if I run the same application, but in desktop app, I get satisfactory result.
I added the server log and jstack generated after the failure.
> JPA EntityManager merge infinite loop - java.lang.StackOverflowError
> --------------------------------------------------------------------
>
> Key: WFLY-11793
> URL: https://issues.jboss.org/browse/WFLY-11793
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 15.0.1.Final
> Environment: MAC OS Mojave
> Java 11
> Wildfly 15.0.1-Final
> Data Base Postgresql
> Reporter: Bruno Maioli Martins
> Assignee: Scott Marlow
> Priority: Critical
> Attachments: jstack.txt, server+querys.log, server-1.log, teste.zip
>
>
> Dear,
> When executing the update of a record invoking getEntityManager().merge(obj) the application goes into infinite loop. This behavior only occurs when there is a OneToMany bidirectional mapping of the entity Papel -> PermissaoAtribuida.
> If the same code runs outside of the Wildfly server context its execution occurs normally.
> Apparently the call getEntityManager.().merge(obj) attempts infinite selects to sync the object with transaction context before doing the merge.
> Attach the source code of my test classes.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (WFLY-11793) JPA EntityManager merge infinite loop - java.lang.StackOverflowError
by Bruno Maioli Martins (Jira)
[ https://issues.jboss.org/browse/WFLY-11793?page=com.atlassian.jira.plugin... ]
Bruno Maioli Martins updated WFLY-11793:
----------------------------------------
Attachment: server-1.log
server+querys.log
jstack.txt
> JPA EntityManager merge infinite loop - java.lang.StackOverflowError
> --------------------------------------------------------------------
>
> Key: WFLY-11793
> URL: https://issues.jboss.org/browse/WFLY-11793
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 15.0.1.Final
> Environment: MAC OS Mojave
> Java 11
> Wildfly 15.0.1-Final
> Data Base Postgresql
> Reporter: Bruno Maioli Martins
> Assignee: Scott Marlow
> Priority: Critical
> Attachments: jstack.txt, server+querys.log, server-1.log, teste.zip
>
>
> Dear,
> When executing the update of a record invoking getEntityManager().merge(obj) the application goes into infinite loop. This behavior only occurs when there is a OneToMany bidirectional mapping of the entity Papel -> PermissaoAtribuida.
> If the same code runs outside of the Wildfly server context its execution occurs normally.
> Apparently the call getEntityManager.().merge(obj) attempts infinite selects to sync the object with transaction context before doing the merge.
> Attach the source code of my test classes.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (WFLY-11793) JPA EntityManager merge infinite loop - java.lang.StackOverflowError
by Bruno Maioli Martins (Jira)
[ https://issues.jboss.org/browse/WFLY-11793?page=com.atlassian.jira.plugin... ]
Bruno Maioli Martins commented on WFLY-11793:
---------------------------------------------
Scott Marlow, thanks for the response.
I did the steps you suggested, and I was also suspecting Hibernate ORM Core, but the interesting thing is that if I run the same application, but in desktop app, I get satisfactory result.
I added the server log and jstack generated after the failure.
> JPA EntityManager merge infinite loop - java.lang.StackOverflowError
> --------------------------------------------------------------------
>
> Key: WFLY-11793
> URL: https://issues.jboss.org/browse/WFLY-11793
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 15.0.1.Final
> Environment: MAC OS Mojave
> Java 11
> Wildfly 15.0.1-Final
> Data Base Postgresql
> Reporter: Bruno Maioli Martins
> Assignee: Scott Marlow
> Priority: Critical
> Attachments: teste.zip
>
>
> Dear,
> When executing the update of a record invoking getEntityManager().merge(obj) the application goes into infinite loop. This behavior only occurs when there is a OneToMany bidirectional mapping of the entity Papel -> PermissaoAtribuida.
> If the same code runs outside of the Wildfly server context its execution occurs normally.
> Apparently the call getEntityManager.().merge(obj) attempts infinite selects to sync the object with transaction context before doing the merge.
> Attach the source code of my test classes.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months