[JBoss JIRA] (WFLY-6858) read-resource should return the job file name
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-6858?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFLY-6858:
-------------------------------------
Perfect. I'll keep the attribute on both the job and the root subsystem then.
> read-resource should return the job file name
> ---------------------------------------------
>
> Key: WFLY-6858
> URL: https://issues.jboss.org/browse/WFLY-6858
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Reporter: Claudio Miranda
> Assignee: James Perkins
>
> The start-job operation must pass the job file name as parameter,
> /deployment=*/subsystem=batch-jberet:read-operation-description(name=start-job)
> however the jon attribute below, returns the job-id name, not the job file name
> /deployment=*/subsystem=batch-jberet/job=*
> So there is no way to know at runtime, the job file name. Is it possible to return the job xml file name ?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6858) read-resource should return the job file name
by Claudio Miranda (JIRA)
[ https://issues.jboss.org/browse/WFLY-6858?page=com.atlassian.jira.plugin.... ]
Claudio Miranda commented on WFLY-6858:
---------------------------------------
> If it helps too we could have a list of all the valid XML files on the base /deployment=*/subsystem=batch-jberet resource too.
If all these xml files may be parameter job-xml-name of start-job operation, that is fine for me. Because on HAL, all valid xml files will be listed, then the user will choose one to start the job.
> read-resource should return the job file name
> ---------------------------------------------
>
> Key: WFLY-6858
> URL: https://issues.jboss.org/browse/WFLY-6858
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Reporter: Claudio Miranda
> Assignee: James Perkins
>
> The start-job operation must pass the job file name as parameter,
> /deployment=*/subsystem=batch-jberet:read-operation-description(name=start-job)
> however the jon attribute below, returns the job-id name, not the job file name
> /deployment=*/subsystem=batch-jberet/job=*
> So there is no way to know at runtime, the job file name. Is it possible to return the job xml file name ?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1703) JVM resource handling of jvm-options should detect -D options and integrate with system-property logic
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1703?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1703:
-------------------------------------
Summary: JVM resource handling of jvm-options should detect -D options and integrate with system-property logic (was: It is not possible to set jboss.modules.system.pkgs per server in domain mode)
> JVM resource handling of jvm-options should detect -D options and integrate with system-property logic
> ------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1703
> URL: https://issues.jboss.org/browse/WFCORE-1703
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.2.0.Final
> Reporter: Bogdan Ilchyshyn
> Priority: Minor
>
> It is not possible to set {{jboss.modules.system.pkgs}} property per server / server group in domain configuration. Even when the following configuration is added to {{host.xml}}:
> {code:xml}
> <server name="server-one" group="main-server-group">
> <jvm name="default">
> <jvm-options>
> <option value="-Djboss.modules.system.pkgs=my.package"/>
> ...
> {code}
> It is overridden by configuration in {{domain.conf}}:
> {noformat}
> JAVA_OPTS="$JAVA_OPTS -Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless=true"
> {noformat}
> This is an issue for configuring third-party java agents per-server. A problem described in WFLY-895 adds to this. One should either add a whole bunch of things to _all_ jvms in domain in order to make agent work, or remove config from {{domain.conf}} to avoid overrides.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (DROOLS-431) Score Cards: Duplicate Rule and Declarative Types when generating DRL
by Tugba Kulahcioglu (JIRA)
[ https://issues.jboss.org/browse/DROOLS-431?page=com.atlassian.jira.plugin... ]
Tugba Kulahcioglu updated DROOLS-431:
-------------------------------------
Attachment: ScoreCardTest-1.0.jar
Thanks for your response Davide. I am not sure how to share it with you since it cannot be compiled when the second guided scorecard is created. Attached is the project with only one guided scorecard. If you create another guided scorecard, it will start giving duplicate errors. I am using 6.4.0.Final but I had the same problem with 6.3.0.Final as well.
Let me know if any other information I could share to help you with it.. Thanks!
(Restricted to jira-users group)
> Score Cards: Duplicate Rule and Declarative Types when generating DRL
> ---------------------------------------------------------------------
>
> Key: DROOLS-431
> URL: https://issues.jboss.org/browse/DROOLS-431
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.0.0.Final
> Reporter: Michael Anstis
> Assignee: Davide Sottara
> Attachments: ScoreCardTest-1.0.jar
>
>
> See test droolsjbpm/drools/drools-workbench-models/drools-workbench-models-guided-scorecard/GuidedScoreCardIntegrationTest.java
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JGRP-2014) FILE_PING destination file name can include File.separator characters
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-2014?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-2014:
-----------------------------------------------
Alan Field <afield(a)redhat.com> changed the Status of [bug 1306389|https://bugzilla.redhat.com/show_bug.cgi?id=1306389] from ON_QA to VERIFIED
> FILE_PING destination file name can include File.separator characters
> ---------------------------------------------------------------------
>
> Key: JGRP-2014
> URL: https://issues.jboss.org/browse/JGRP-2014
> Project: JGroups
> Issue Type: Bug
> Reporter: Alan Field
> Assignee: Bela Ban
> Fix For: 3.6.8, 4.0
>
>
> I was attempting to use FILE_PING as the discovery protocol with Infinispan server and the following configuration:
> {noformat}
> <protocol type="FILE_PING">
> <property name="location">${jgroups.file.dir:/Users/afield/Documents}</property>
> </protocol>
> {noformat}
> However, the following exceptions occur when I try to start the server:
> {noformat}
> 15:34:41,662 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-11) ISPN000078: Starting JGroups Channel
> 15:34:41,675 ERROR [org.jgroups.protocols.FILE_PING] (MSC service thread 1-11) attempt to write data failed at clustered : clustered.list: java.io.FileNotFoundException: /Users/afield/Documents/clustered/3e5f03c6-c297-474a-cb72-1ca0841f8e5c.afield-osx/clustered.list (No such file or directory)
> at java.io.FileOutputStream.open0(Native Method) [rt.jar:1.8.0_72]
> at java.io.FileOutputStream.open(FileOutputStream.java:270) [rt.jar:1.8.0_72]
> at java.io.FileOutputStream.<init>(FileOutputStream.java:213) [rt.jar:1.8.0_72]
> at java.io.FileOutputStream.<init>(FileOutputStream.java:162) [rt.jar:1.8.0_72]
> at org.jgroups.protocols.FILE_PING.write(FILE_PING.java:294) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.FILE_PING.findMembers(FILE_PING.java:116) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.Discovery.findMembers(Discovery.java:240) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.Discovery.down(Discovery.java:380) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.FILE_PING.down(FILE_PING.java:107) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.MERGE3.down(MERGE3.java:255) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:360) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.FD_ALL.down(FD_ALL.java:233) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:92) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.pbcast.NAKACK2.down(NAKACK2.java:589) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:669) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:347) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:76) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:41) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1087) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:353) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.protocols.FRAG2.down(FRAG2.java:136) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1038) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.JChannel.down(JChannel.java:791) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.JChannel._connect(JChannel.java:564) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.JChannel.connect(JChannel.java:294) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.jgroups.JChannel.connect(JChannel.java:279) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:208) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:199) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_72]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_72]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_72]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_72]
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:176) [infinispan-commons-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:870) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:639) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:628) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:531) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:238) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:583) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:549) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:420) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:434) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:89) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:80) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.server.infinispan.SecurityActions$4.run(SecurityActions.java:105) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.server.infinispan.SecurityActions$4.run(SecurityActions.java:102) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.security.Security.doPrivileged(Security.java:76) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.server.infinispan.SecurityActions.doPrivileged(SecurityActions.java:49) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.infinispan.server.infinispan.SecurityActions.startCache(SecurityActions.java:110) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:85) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_72]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_72]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_72]
> {noformat}
> From looking at the code, FILE_PING creates the {{/Users/afield/Documents/clustered}} directory, but the problem is that the {{local_addr}} for the host is {{afield-osx/clustered}}, so {{destination}} is defined as {{75b5c5b8-014d-26ff-c400-5398a96ad3f4.afield-osx/clustered.list}} when {{addressToFilename()}} is called and then the subsequent write fails. File.separator need to be removed or replaced in the {{destination}} variable.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1560) Cli calls leak resources in Host Controller when repeatedly calling jboss-cli.sh
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1560?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1560:
------------------------------------------
Is this still a problem with 10.1.0.CR1?
> Cli calls leak resources in Host Controller when repeatedly calling jboss-cli.sh
> --------------------------------------------------------------------------------
>
> Key: WFCORE-1560
> URL: https://issues.jboss.org/browse/WFCORE-1560
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.8.Final
> Environment: OS: CentOS 7.2
> Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)
> Wildfly-10.0.0-Final
> Reporter: Michael Noack
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Beta1
>
> Attachments: console-dc.log, host-controller.log, JVM-DC.png, process-controller.log
>
>
> When executing management commands using jboss-cli.sh against the domain controller of a cluster repeatedly the host controller uses up more and more memory in oldgen. After several thousands of runs of jboss-cli the host controller eventually becomes unresponsive (see attached picture for memory consumption, dc became entirely unresponsive at roughly 6:30am):
> [root@dc broken]# /opt/wildfly-10.0.0.Final-DC/bin/./jboss-cli.sh --connect --user="username" --password="password" --command=":read-children-names(child-type=host)"
> Failed to connect to the controller: The controller is not available at xx.xx.xx.xx:9993: java.net.ConnectException: WFLYPRT0023: Could not connect to https-remoting://xx.xx.xx.xx:9993. The connection timed out: WFLYPRT0023: Could not connect to https-remoting://xx.xx.xx.xx:9993. The connection timed out
> I discovered the issue when testing whether https://issues.jboss.org/browse/WFCORE-974 was actually resolved in wildfly-10.0.0.Final as advertised. I can confirm that the issue is different, since no OOM-Exceptions are thrown. However the DC still becomes useless, since it won't accept any connections anymore. -I will check whether the work-around from WFCORE-974 applies to this issue as well.- However the work-around from WFCORE-974 doesn't fix this issue.
> Please note that the attached logs are UTC, while the monitoring is UTC+2. Also the collection values are misleading since I haven't adapted my monitoring to the new output of jstat in JDK8. PU and PC are thus MU and MC.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1560) Cli calls leak resources in Host Controller when repeatedly calling jboss-cli.sh
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1560?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1560:
-------------------------------------
Priority: Critical (was: Major)
> Cli calls leak resources in Host Controller when repeatedly calling jboss-cli.sh
> --------------------------------------------------------------------------------
>
> Key: WFCORE-1560
> URL: https://issues.jboss.org/browse/WFCORE-1560
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.8.Final
> Environment: OS: CentOS 7.2
> Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)
> Wildfly-10.0.0-Final
> Reporter: Michael Noack
> Assignee: Brian Stansberry
> Priority: Critical
> Fix For: 3.0.0.Beta1
>
> Attachments: console-dc.log, host-controller.log, JVM-DC.png, process-controller.log
>
>
> When executing management commands using jboss-cli.sh against the domain controller of a cluster repeatedly the host controller uses up more and more memory in oldgen. After several thousands of runs of jboss-cli the host controller eventually becomes unresponsive (see attached picture for memory consumption, dc became entirely unresponsive at roughly 6:30am):
> [root@dc broken]# /opt/wildfly-10.0.0.Final-DC/bin/./jboss-cli.sh --connect --user="username" --password="password" --command=":read-children-names(child-type=host)"
> Failed to connect to the controller: The controller is not available at xx.xx.xx.xx:9993: java.net.ConnectException: WFLYPRT0023: Could not connect to https-remoting://xx.xx.xx.xx:9993. The connection timed out: WFLYPRT0023: Could not connect to https-remoting://xx.xx.xx.xx:9993. The connection timed out
> I discovered the issue when testing whether https://issues.jboss.org/browse/WFCORE-974 was actually resolved in wildfly-10.0.0.Final as advertised. I can confirm that the issue is different, since no OOM-Exceptions are thrown. However the DC still becomes useless, since it won't accept any connections anymore. -I will check whether the work-around from WFCORE-974 applies to this issue as well.- However the work-around from WFCORE-974 doesn't fix this issue.
> Please note that the attached logs are UTC, while the monitoring is UTC+2. Also the collection values are misleading since I haven't adapted my monitoring to the new output of jstat in JDK8. PU and PC are thus MU and MC.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1560) Cli calls leak resources in Host Controller when repeatedly calling jboss-cli.sh
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1560?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1560:
-------------------------------------
Fix Version/s: 3.0.0.Beta1
> Cli calls leak resources in Host Controller when repeatedly calling jboss-cli.sh
> --------------------------------------------------------------------------------
>
> Key: WFCORE-1560
> URL: https://issues.jboss.org/browse/WFCORE-1560
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.8.Final
> Environment: OS: CentOS 7.2
> Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)
> Wildfly-10.0.0-Final
> Reporter: Michael Noack
> Assignee: Brian Stansberry
> Priority: Critical
> Fix For: 3.0.0.Beta1
>
> Attachments: console-dc.log, host-controller.log, JVM-DC.png, process-controller.log
>
>
> When executing management commands using jboss-cli.sh against the domain controller of a cluster repeatedly the host controller uses up more and more memory in oldgen. After several thousands of runs of jboss-cli the host controller eventually becomes unresponsive (see attached picture for memory consumption, dc became entirely unresponsive at roughly 6:30am):
> [root@dc broken]# /opt/wildfly-10.0.0.Final-DC/bin/./jboss-cli.sh --connect --user="username" --password="password" --command=":read-children-names(child-type=host)"
> Failed to connect to the controller: The controller is not available at xx.xx.xx.xx:9993: java.net.ConnectException: WFLYPRT0023: Could not connect to https-remoting://xx.xx.xx.xx:9993. The connection timed out: WFLYPRT0023: Could not connect to https-remoting://xx.xx.xx.xx:9993. The connection timed out
> I discovered the issue when testing whether https://issues.jboss.org/browse/WFCORE-974 was actually resolved in wildfly-10.0.0.Final as advertised. I can confirm that the issue is different, since no OOM-Exceptions are thrown. However the DC still becomes useless, since it won't accept any connections anymore. -I will check whether the work-around from WFCORE-974 applies to this issue as well.- However the work-around from WFCORE-974 doesn't fix this issue.
> Please note that the attached logs are UTC, while the monitoring is UTC+2. Also the collection values are misleading since I haven't adapted my monitoring to the new output of jstat in JDK8. PU and PC are thus MU and MC.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months