[JBoss JIRA] (WFCORE-1562) Wildcard ops seem to drop the underlying error on failure
by Ken Wills (JIRA)
Ken Wills created WFCORE-1562:
---------------------------------
Summary: Wildcard ops seem to drop the underlying error on failure
Key: WFCORE-1562
URL: https://issues.jboss.org/browse/WFCORE-1562
Project: WildFly Core
Issue Type: Bug
Reporter: Ken Wills
Assignee: Ken Wills
[domain@localhost:9990 /] :read-resource(attributes-only=true, recursive=true)
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0275: Cannot define both 'attributes-only' and 'recursive'",
"rolled-back" => true
}
But using a wildcard:
[domain@localhost:9990 /] /host=*:read-resource(attributes-only=true, recursive=false)
{
"outcome" => "failed",
"result" => [],
"rolled-back" => true
}
The error is present up until the final response, then it's dropped somewhere.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1562) Wildcard ops seem to drop the underlying error on failure
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1562?page=com.atlassian.jira.plugi... ]
Ken Wills updated WFCORE-1562:
------------------------------
Description:
[domain@localhost:9990 /] :read-resource(attributes-only=true, recursive=true)
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0275: Cannot define both 'attributes-only' and 'recursive'",
"rolled-back" => true
}
But using a wildcard:
[domain@localhost:9990 /] /host=*:read-resource(attributes-only=true, recursive=true)
{
"outcome" => "failed",
"result" => [],
"rolled-back" => true
}
The error is present up until the final response, then it's dropped somewhere.
was:
[domain@localhost:9990 /] :read-resource(attributes-only=true, recursive=true)
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0275: Cannot define both 'attributes-only' and 'recursive'",
"rolled-back" => true
}
But using a wildcard:
[domain@localhost:9990 /] /host=*:read-resource(attributes-only=true, recursive=false)
{
"outcome" => "failed",
"result" => [],
"rolled-back" => true
}
The error is present up until the final response, then it's dropped somewhere.
> Wildcard ops seem to drop the underlying error on failure
> ---------------------------------------------------------
>
> Key: WFCORE-1562
> URL: https://issues.jboss.org/browse/WFCORE-1562
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Ken Wills
> Assignee: Ken Wills
>
> [domain@localhost:9990 /] :read-resource(attributes-only=true, recursive=true)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0275: Cannot define both 'attributes-only' and 'recursive'",
> "rolled-back" => true
> }
> But using a wildcard:
> [domain@localhost:9990 /] /host=*:read-resource(attributes-only=true, recursive=true)
> {
> "outcome" => "failed",
> "result" => [],
> "rolled-back" => true
> }
> The error is present up until the final response, then it's dropped somewhere.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1524) Scanner deployment failing at boot passes readiness/liveness checks
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1524?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet commented on WFCORE-1524:
-------------------------------------------
Other quick speculation : the deployment notification is sent because of rollback-on-runtime-failure set to false thus the file is created.
> Scanner deployment failing at boot passes readiness/liveness checks
> -------------------------------------------------------------------
>
> Key: WFCORE-1524
> URL: https://issues.jboss.org/browse/WFCORE-1524
> Project: WildFly Core
> Issue Type: Bug
> Components: Deployment Scanner, Domain Management
> Environment: brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/jboss-eap-7/eap70-openshift:1.3-11
> Reporter: Marek Schmidt
> Assignee: ehsavoie Hugonnet
>
> During larger scale-ups (e.g. from 1 to 6 on nodes under load) deployments sometimes fail with "org.infinispan.util.concurrent.TimeoutException: Replication timeout for foo-1-xxxxx".
> That by itself is expected with the default timeouts, however, the problem is that such failed deployments pass the default EAP readiness and liveness checks, which results in HTTP 404 responses.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1561) read-resource responds with incorrect address when going through host controller
by John Mazzitelli (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1561?page=com.atlassian.jira.plugi... ]
John Mazzitelli commented on WFCORE-1561:
-----------------------------------------
> it turns out that we've already "fixed" that in the console.
> The console tries to detect such operations and turns the relative into a fully qualified address.
I just wrote the same workaround code myself :-) Code is found here if anyone wants to see how I did it - HWKAGENT-92 - quick and dirty, but gets the job done. It requires that you know the request that was sent that resulted in the partial address response.
> read-resource responds with incorrect address when going through host controller
> --------------------------------------------------------------------------------
>
> Key: WFCORE-1561
> URL: https://issues.jboss.org/browse/WFCORE-1561
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.1.0.Final
> Reporter: John Mazzitelli
> Assignee: Ken Wills
>
> 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] (WFLY-6591) Expired/invalidated session meta-data entries not removed when using optimistic locking or READ_COMMITTED isolation
by Mathieu Lachance (JIRA)
[ https://issues.jboss.org/browse/WFLY-6591?page=com.atlassian.jira.plugin.... ]
Mathieu Lachance commented on WFLY-6591:
----------------------------------------
We applied your pull request yesterday and with it we saw the memory leak disappear; great news!
Any ETA when it will become mainstream in WF10.1?
> Expired/invalidated session meta-data entries not removed when using optimistic locking or READ_COMMITTED isolation
> -------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6591
> URL: https://issues.jboss.org/browse/WFLY-6591
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Reporter: Gabriel Lavoie
> Assignee: Paul Ferraro
>
> When using optimistic locking on the web cache, data from expired sessions is not removed from the web cache by the org.wildfly.clustering.web.infinispan.session.SessionExpirationScheduler and leaks forever.
> Session seems to be invalidated correctly and isn't accessible anymore.
> After tracing the code, org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove() doesn't remove the metadata entries when "this.properties.isLockOnWrite()" returns false (which is always the case for optimistic locking). Then in org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.remove(), the call to attributesFactory.remove(id) also gets skipped.
> We've tried to adjust the code of org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove() to the following:
> {code}
> private boolean remove(String id, Cache<SessionCreationMetaDataKey, SessionCreationMetaDataEntry<L>> creationMetaDataCache) {
> SessionCreationMetaDataKey key = new SessionCreationMetaDataKey(id);
> if (this.properties.isLockOnWrite()) {
> if (creationMetaDataCache.getAdvancedCache().withFlags(Flag.ZERO_LOCK_ACQUISITION_TIMEOUT, Flag.FAIL_SILENTLY).lock(key)) {
> creationMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(key);
> this.accessMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(new SessionAccessMetaDataKey(id));
> return true;
> }
> return false;
> } else {
> creationMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(key);
> this.accessMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(new SessionAccessMetaDataKey(id));
> return true;
> }
> }
> {code}
> With that change, the memory leaks disappears.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1561) read-resource responds with incorrect address when going through host controller
by Harald Pehl (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1561?page=com.atlassian.jira.plugi... ]
Harald Pehl commented on WFCORE-1561:
-------------------------------------
[~brian.stansberry] it turns out that we've already "fixed" that in the console. The console tries to detect such operations and turns the relative into a fully qualified address. Digging through that code I remember that I wanted to file an issue for that. Seems that I forgot to do so. So thanks [~mazz] for bringing this up.
I don't have any concerns fixing this. I only need to make sure the workaround still works with old servers w/o the fix and causes no harm otherwise.
> read-resource responds with incorrect address when going through host controller
> --------------------------------------------------------------------------------
>
> Key: WFCORE-1561
> URL: https://issues.jboss.org/browse/WFCORE-1561
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.1.0.Final
> Reporter: John Mazzitelli
> Assignee: Ken Wills
>
> 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-1561) read-resource responds with incorrect address when going through host controller
by John Mazzitelli (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1561?page=com.atlassian.jira.plugi... ]
John Mazzitelli commented on WFCORE-1561:
-----------------------------------------
> Did debugging lead you to that code as the reason for the problem?
No, it did not. I visually inspected the code and found that stuff that appears to strip host/server and just assumed that is where it was. You can ignore that if you think that is not relevant.
But the CLI commands and its response in my original description is what I see when I actually execute them. I'm getting a partial address when I was expecting the full address.
> read-resource responds with incorrect address when going through host controller
> --------------------------------------------------------------------------------
>
> Key: WFCORE-1561
> URL: https://issues.jboss.org/browse/WFCORE-1561
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.1.0.Final
> Reporter: John Mazzitelli
> Assignee: Ken Wills
>
> 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-1561) read-resource responds with incorrect address when going through host controller
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1561?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1561:
----------------------------------------
Assignee: Ken Wills (was: Brian Stansberry)
So, Ken AbstractMultiTargetHandler Wills, enjoy!
> read-resource responds with incorrect address when going through host controller
> --------------------------------------------------------------------------------
>
> Key: WFCORE-1561
> URL: https://issues.jboss.org/browse/WFCORE-1561
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.1.0.Final
> Reporter: John Mazzitelli
> Assignee: Ken Wills
>
> 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-1561) read-resource responds with incorrect address when going through host controller
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1561?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1561:
------------------------------------------
[~harald.pehl] I agree with John in that the return value should include the host data, but I'm concerned that fixing it might impact the console, so I wanted to give you an FYI. Do you have any concerns?
It looks like the problem relates to the fact that the host+server is fully specified. For example this analogous operation has the behavior John reports:
{code}
[domain@localhost:9990 /] /host=master/server=server-one/subsystem=logging/logger=*:read-resource(include-runtime=true)
{
"outcome" => "success",
"result" => [
{
"address" => [
("subsystem" => "logging"),
("logger" => "com.arjuna")
],
"outcome" => "success",
"result" => {
"category" => "com.arjuna",
"filter" => undefined,
"filter-spec" => undefined,
"handlers" => undefined,
"level" => "WARN",
"use-parent-handlers" => true
}
},
. . . .
{code}
But this one that uses server=* instead of server=server-one works as expected:
{code}
[domain@localhost:9990 /] /host=master/server=*/subsystem=logging/logger=*:read-resource(include-runtime=true)
{
"outcome" => "success",
"result" => [
{
"address" => [
("host" => "master"),
("server" => "server-one"),
("subsystem" => "logging"),
("logger" => "com.arjuna")
],
"outcome" => "success",
"result" => {
"category" => "com.arjuna",
"filter" => undefined,
"filter-spec" => undefined,
"handlers" => undefined,
"level" => "WARN",
"use-parent-handlers" => true
}
},
. . . .
{code}
> read-resource responds with incorrect address when going through host controller
> --------------------------------------------------------------------------------
>
> Key: WFCORE-1561
> URL: https://issues.jboss.org/browse/WFCORE-1561
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.1.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