[JBoss JIRA] (DROOLS-1182) KieServiesClient.completeConversation() won't unset all conversationIds
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1182?page=com.atlassian.jira.plugi... ]
Edson Tirelli reassigned DROOLS-1182:
-------------------------------------
Assignee: Maciej Swiderski (was: Edson Tirelli)
> KieServiesClient.completeConversation() won't unset all conversationIds
> -----------------------------------------------------------------------
>
> Key: DROOLS-1182
> URL: https://issues.jboss.org/browse/DROOLS-1182
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.4.0.Final
> Reporter: Slavomir Krupa
> Assignee: Maciej Swiderski
>
> {noformat}
> KieServiesClient.completeConversation()
> {noformat}
> will unset *conversationId* just from +KieServiesClient+ instance. It won't delete *conversationId* from other clients instances (ProcessServicesClient,UserTaskServicesClient...)
> Kie server client stores *conversationId* as class attribute. It means that it is possible to have more *conversationIds* for one +KieServiesClient+ (one for every client implementing +AbstractKieServicesClientImpl+) and it is not possible to unset conversationId for most of the clients (just +KieServiesClient+ has *completeConversation* method).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1481) list-add operation doesn't work on login-modules attribute
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1481?page=com.atlassian.jira.plugi... ]
Tomas Hofman commented on WFCORE-1481:
--------------------------------------
Status update
I committed my current version here: https://github.com/TomasHofman/wildfly-core/commit/7f370a4a6ea1e8c48abc93...
I. Storage.RUNTIME
I think this case is working fine. The only issue is that even if one uses AbstractWriteAttributeHandler as writing OSH, the handler doesn't validates the operation correctly. That is because validation is performed in MODEL stage when the final value is not yet determined, so the validation passes even if it shouldn't. It could be solved by performing the validation in RUNTIME stage manually like:
{code}
.addReadWriteAttribute(LIST_ATTRIBUTE, readerOSH,
new OperationStepHandler() {
@Override
public void execute(OperationContext context, ModelNode operation) throws OperationFailedException {
context.addStep(operation, (context1, operation1) -> {
// validate
final ModelNode syntheticOp = new ModelNode();
syntheticOp.get(LIST_ATTRIBUTE.getName()).set(operation.get(VALUE));
LIST_ATTRIBUTE.validateOperation(syntheticOp);
// set
runtimeListAttributeValue = operation.get(VALUE);
}, OperationContext.Stage.RUNTIME);
}
})
{code}
So the person implementing the attribute has to be aware that:
* he must add RUNTIME steps in his reader/writer OSHs,
* he must perform validation manually, if he wants it.
II. Storage.Configuration
I still little bit struggle with composite operations, particularly in that test case which you were looking at.
Lets have Storage.CONFIGURATION attribute with reader OSH like the one in the test case:
{code}
StringListAttributeDefinition LIST_ATTRIBUTE = new StringListAttributeDefinition.Builder("my-list-attribute")
.setAllowNull(true)
.build();
ResourceBuilder.Factory.create(...)
.addReadWriteAttribute(LIST_ATTRIBUTE, new OperationStepHandler() {
@Override
public void execute(OperationContext context, ModelNode operation) throws OperationFailedException {
context.getResult().set(runtimeListAttributeValue);
}
}, new AbstractWriteAttributeHandler(LIST_ATTRIBUTE) {
@Override
protected boolean applyUpdateToRuntime(OperationContext context, ModelNode operation, String attributeName, ModelNode resolvedValue, ModelNode currentValue, HandbackHolder handbackHolder) throws OperationFailedException {
runtimeListAttributeValue = operation.get(VALUE);
return false;
}
});
{code}
and execute composite operation containing two list-adds:
{code}
{
"operation" => "composite",
"address" => [],
"steps" => [
{
"operation" => "list-add",
"address" => [("subsystem" => "test")],
"name" => "my-list-attribute",
"value" => "value1"
},
{
"operation" => "list-add",
"address" => [("subsystem" => "test")],
"name" => "my-list-attribute",
"value" => "value2"
}
]
}
{code}
Problem is that the second list-add reads before the first one writes. The step sequence would go:
1) begin operation
M0 PrepareStepHandler
2) M0 executes
M1 CompositeOperationHandler
3) M1 executes
M2 ListAddHandler "value1"
M3 ListAddHandler "value2"
4) M2 executes
M4 ReadAttributeHandler
M5 handler that modifies the value and adds write handler
M3 ListAddHandler "value2"
5) M4 executes - which executes ReadOST, which in this case effectively reads from runtime
M5 handler that modifies the value and adds write handler
M3 ListAddHandler "value2"
6) M5 executes
M6 WriteAttributeHandler - executes AbstractWriteAttributeHandler instance defined as WriteOST
M3 ListAddHandler "value2"
7) M6 executes - resource model is updated
M3 ListAddHandler "value2"
R1 handler that updates runtime with \["value1"]
8) M3 ListAddHandler for "value2" executes, and is about to read from runtime again, but runtime still wasn't updated, so it reads \[] instead of \["value1"].
Then, after second ListAddHandler processes, we are left with:
R1 handler that updates runtime with \["value1"]
R2 handler that updates runtime with \["value2"] (instead of \["value1", "value2"])
I mean to me the test case seams like reader OST is reading from RUNTIME in stage MODEL, and writer OSH is writing to RUNTIME in stage RUNTIME, so they can never meet. I think the reader OST should either not be there, or should not read from a variable that is only updated in RUNTIME stage.
> list-add operation doesn't work on login-modules attribute
> ----------------------------------------------------------
>
> Key: WFCORE-1481
> URL: https://issues.jboss.org/browse/WFCORE-1481
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.1.0.Final
> Reporter: Bartosz Spyrko-Śmietanko
> Assignee: Tomas Hofman
>
> Executing list-add operation on login-modules results in the modules being replaced instead of appending new module.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1495) server instances cannot find keytab during domain startup
by Vlado Pakan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1495?page=com.atlassian.jira.plugi... ]
Vlado Pakan reassigned WFCORE-1495:
-----------------------------------
Assignee: Vlado Pakan
> server instances cannot find keytab during domain startup
> ---------------------------------------------------------
>
> Key: WFCORE-1495
> URL: https://issues.jboss.org/browse/WFCORE-1495
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Reporter: Derek Horton
> Assignee: Vlado Pakan
>
> In domain mode, the server instances cannot find the keytab if the ApplicationRealm is configured to use kerberos as the server-identity:
> {code}
> <security-realm name="ApplicationRealm">
> <server-identities>
> <kerberos>
> <keytab principal="remote/imahost.imadomain.net@VM29" path="/path/to/keytab"/>
> </kerberos>
> </server-identities>
> <authentication>
> <kerberos remove-realm="true"/>
> </authentication>
> <authorization>
> <properties path="application-roles.properties" relative-to="jboss.domain.config.dir"/>
> </authorization>
> </security-realm>
> {code}
> This results in the following error and the server instances fail to start:
> [Server:server-one] 15:10:35,360 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("validate-authentication") failed - address: ([
> [Server:server-one] ("core-service" => "management"),
> [Server:server-one] ("security-realm" => "ApplicationRealm")
> [Server:server-one] ]) - failure description: "WFLYDM0094: Kerberos is enabled for authentication on security realm 'ApplicationRealm' but no Keytab has been added to the server-identity."
> [Server:server-one] 15:10:35,376 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1560) Cli calls leak resources in Host Controller when repeatedly calling jboss-cli.sh
by Michael Noack (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1560?page=com.atlassian.jira.plugi... ]
Michael Noack updated WFCORE-1560:
----------------------------------
Description:
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.
Please note that the attached logs are UTC, while the monitoring is UTC+2.
was:
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 64.30.129.5:9993: java.net.ConnectException: WFLYPRT0023: Could not connect to https-remoting://64.30.129.5:9993. The connection timed out: WFLYPRT0023: Could not connect to https-remoting://64.30.129.5: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.
Please note that the attached logs are UTC, while the monitoring is UTC+2.
> 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: CLI
> 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: Alexey Loubyansky
> 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.
> Please note that the attached logs are UTC, while the monitoring is UTC+2.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JGRP-2065) RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2065?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2065:
--------------------------------
Investigate behavior for 1, 10 and 100 sender threads
> RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer
> -------------------------------------------------------------------
>
> Key: JGRP-2065
> URL: https://issues.jboss.org/browse/JGRP-2065
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> {{RoundTrip}} is a simple test between 2 members measuring round-trip latency. The sender continually sends a message, the receiver receives it and sends the response, and the sender unblocks when the response is received. Then the sender sends the next message.
> The time for the request is then logged at the sender and a min/avg/max value is computed (probably changed to histograms later).
> {{RoundTrip}} uses a JGroups channel, configured with {{-props}}, e.g. {{-props ~/tcp.xml}}.
> {{RoundTripTcp}} does the same, but uses direct TCP sockets (no JGroups) for communication.
> {{RoundTripServer}} uses the client-server classes of JGroups for communication, but no channel is used.
> Round trip times (both processes on the same box, a Mac mini):
> * {{RoundTrip}} (with {{tcp.xml}} shipped with JGroups): *110 us*
> * {{RoundTripTcp}}: *46 us*
> * {{RoundTripServer}}: *49 us*
> Note that the client/server classes used by {{RoundTripServer}} are also used by the TCP transport (configured in {{tcp.xml}}.
> {{RoundTripServer}} is ~6% slower than {{RoundTripTcp}}, but that can be attributed to the additional work the former has to do (e.g. connection reaping etc). This is something we can focus on later.
> The big difference are the 110 us for {{RoundTrip}}. The goal is to find out what causes this and eliminate it. Since {{RoundTrip}} and {{RoundTripServer}} use the same underlying client/server classes in JGroups, let's compare these 2.
> Tasks:
> * Remove all protocols other than TCP in the running stack: (e.g. {{probe.sh remove-protocol=MFC}}). I already did this and the diff was negligible, but let's run this again
> * Try various bundlers (e.g. NoBundler)
> * Reduce threads in the threadpools, possibly disable (regular and OOB) thread pools (replace with DirectExecutor)
> * The default is 1 sender thread, but try with multiple threads
> * Measure perf between sending a message (in the bundler) and receiving it
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6628) read-resource responds with incorrect address when going through host controller
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFLY-6628?page=com.atlassian.jira.plugin.... ]
Alexey Loubyansky reassigned WFLY-6628:
---------------------------------------
Component/s: Domain Management
(was: CLI)
Assignee: Brian Stansberry (was: Alexey Loubyansky)
> read-resource responds with incorrect address when going through host controller
> --------------------------------------------------------------------------------
>
> Key: WFLY-6628
> URL: https://issues.jboss.org/browse/WFLY-6628
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 10.0.0.Final
> Reporter: John Mazzitelli
> Assignee: Brian Stansberry
>
> I have a typical small domain setup: one master host controller (aka domain controller) and one slave host controller with "server-one" and "server-two" servers.
> I need to discover things running in those two servers (server-one and server-two). As part of the discovery, I invoke read-resource operations via the management interface - for example, to discover all the datasources in server-one:
> /host=slave/server=server-one/subsystem=datasources/data-source=*/:read-resource(include-runtime=true)
> For each returned datasource, I need to know that datasource's full address. The problem is, I do not get the full address. Instead, the CLI returns the following partial address:
> {
> "outcome" => "success",
> "result" => [{
> "address" => [
> ("subsystem" => "datasources"),
> ("data-source" => "ExampleDS")
> ],
> "outcome" => "success",
> "result" => {
> "allocation-retry" => undefined,
> ...and the rest of the properties for the ExampleDS datasource...
> }
> }
> }]
> }
> The address should be the full address of:
> "address" => [
> ("host" => "slave"),
> ("server" => "server-one"),
> ("subsystem" => "datasources"),
> ("data-source" => "ExampleDS")
> ],
> NOTE! This problem occurs both when I connect to the domain controller and when I connect to the slave host controller - it doesn't matter, the CLI returns the same erroneous address if connected to either one.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1560) Cli calls leak resources in Host Controller when repeatedly calling jboss-cli.sh
by Michael Noack (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1560?page=com.atlassian.jira.plugi... ]
Michael Noack updated WFCORE-1560:
----------------------------------
Description:
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 64.30.129.5:9993: java.net.ConnectException: WFLYPRT0023: Could not connect to https-remoting://64.30.129.5:9993. The connection timed out: WFLYPRT0023: Could not connect to https-remoting://64.30.129.5: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.
Please note that the attached logs are UTC, while the monitoring is UTC+2.
was:
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:
[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 64.30.129.5:9993: java.net.ConnectException: WFLYPRT0023: Could not connect to https-remoting://64.30.129.5:9993. The connection timed out: WFLYPRT0023: Could not connect to https-remoting://64.30.129.5: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.
> 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: CLI
> 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: Alexey Loubyansky
> 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 64.30.129.5:9993: java.net.ConnectException: WFLYPRT0023: Could not connect to https-remoting://64.30.129.5:9993. The connection timed out: WFLYPRT0023: Could not connect to https-remoting://64.30.129.5: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.
> Please note that the attached logs are UTC, while the monitoring is UTC+2.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-761) Not possible to overlay non existing file in WAR
by Dimitris Andreadis (JIRA)
[ https://issues.jboss.org/browse/WFCORE-761?page=com.atlassian.jira.plugin... ]
Dimitris Andreadis reassigned WFCORE-761:
-----------------------------------------
Assignee: Jason Greene (was: Dimitris Andreadis)
> Not possible to overlay non existing file in WAR
> ------------------------------------------------
>
> Key: WFCORE-761
> URL: https://issues.jboss.org/browse/WFCORE-761
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Bartosz Baranowski
> Assignee: Jason Greene
> Priority: Critical
> Labels: downstream_dependency
>
> It is either bug in how deployments are treated or how overlay/vfs work.
> Steps to reproduce:
> 1. deploy undexploded war with jar inside
> 2. add overlay that will add non existing file in jar
> Result: exception:
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay WEB-INF/lib/overlayed.jar//META-INF/x/file.txt at WEB-INF/lib/overlayed.jar//META-INF/x/file.txt
> Caused by: java.io.FileNotFoundException: /content/shell.war/WEB-INF/lib/overlayed.jar/META-INF/x/file.txt"}}
> at org.jboss.as.test.integration.management.ManagementOperations.executeOperation(ManagementOperations.java:67)
> at org.jboss.as.test.integration.management.ManagementOperations.executeOperation(ManagementOperations.java:37)
> at org.jboss.as.test.integration.deployment.deploymentoverlay.jar.OverlayUtils.setupOverlay(OverlayUtils.java:76)
> at org.jboss.as.test.integration.deployment.deploymentoverlay.war.OverlayNonExistingResourceTestCase.testOverlay(OverlayNonExistingResourceTestCase.java:67)
> Expectation:
> should work. It actually does work, if war is really exploded or
> 'if(exploded)' part in overlay is removed from overlay processor and everything is handled via: https://github.com/stuartwdouglas/wildfly-core/blob/a75af9118c4062fafb899...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1560) Cli calls leak resources in Host Controller when repeatedly calling jboss-cli.sh
by Michael Noack (JIRA)
Michael Noack created WFCORE-1560:
-------------------------------------
Summary: 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: CLI
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: Alexey Loubyansky
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:
[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 64.30.129.5:9993: java.net.ConnectException: WFLYPRT0023: Could not connect to https-remoting://64.30.129.5:9993. The connection timed out: WFLYPRT0023: Could not connect to https-remoting://64.30.129.5: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.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months