[JBoss JIRA] (WFLY-6774) Provide ability to start/stop Resource Adapter creation/deletion without restart of server
by Ramesh Reddy (JIRA)
Ramesh Reddy created WFLY-6774:
----------------------------------
Summary: Provide ability to start/stop Resource Adapter creation/deletion without restart of server
Key: WFLY-6774
URL: https://issues.jboss.org/browse/WFLY-6774
Project: WildFly
Issue Type: Enhancement
Components: JCA
Affects Versions: 10.0.0.Final, 9.0.0.Final
Reporter: Ramesh Reddy
Assignee: Jesper Pedersen
Currently in WF 10, when a resource adapter is created / deleted using the CLI the "reload-status" is set to "requires restart", based how the resource is expected to be managed in WF. We need ability *avoid* the restart of the server
h3. Why We need it?
In Teiid, it is common practice to add/remove resource adapters dynamically and restarting server will affect performance and usability severely.
* Because delete/re-add is in Teiid's workflow to manage a resource adapters and when we have to restart we loose the whole state of the virtual database. That means we need re-establish runtime status. For example, all the existing sessions will be killed.
* Runtime environment are often shared, that could kill other person's tasks in flight leaving them hanging with errors.
* Every time resource adapter starts we fetch metadata from the source, this is very expensive operation.
* With multi-source feature, it is a feature that user dynamically brings in/out sources as they show up on their dashboard, it would be not possible to support this feature.
* This is a change of behavior from earlier versions of the EAP, our users and customers rely on this feature
As per Teiid project is concerned, we consider this is regression on WF and thus a bug.
h3. Proposed Solution
[~brian.stansberry] suggested the WF management practices here in this document https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-Apply...
Based on this the conclusion is that resource adapters, is developed under "all-services" paradigm, not under "resource-services" paradigm, where a explicit header from client to whether to restart or not can avoid having to "reload" the server when a new RA is added or removed. We understand the nature of service dependencies in WF, and how this can affect the other dependent services, but we verified that Teiid will not have those side effects as we designed. Since these sources are effectively exclusively defined for Teiid should not interfere with others. Also, since the request is explicit, should not affect current behavior.
h3. Workarounds Considered
Teiid currently deploy the RAR files in module format (due to product requirements) if allowed this can be changed to deploy .rar files, which is suggested as alternative. This does require lot of code changes and not approved path. Aslo, only half solution as WFLY-6773 we would still need.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6773) Provide ability to start/stop Data Source creation without restart of server
by Ramesh Reddy (JIRA)
Ramesh Reddy created WFLY-6773:
----------------------------------
Summary: Provide ability to start/stop Data Source creation without restart of server
Key: WFLY-6773
URL: https://issues.jboss.org/browse/WFLY-6773
Project: WildFly
Issue Type: Enhancement
Components: JCA
Affects Versions: 10.0.0.Final
Reporter: Ramesh Reddy
Assignee: Jesper Pedersen
Currently in WF 10, where a data source is created / removed using the CLI the "reload-status" is set to "requires restart", based how the resource is expected to be managed in WF.
h3. Why We need it?
In Teiid, it is common practice to add/remove data sources dynamically and restarting server will affect performance and usability severely.
* Because delete/re-add is in Teiid's workflow to manage a data sources and when we have to restart we loose the whole state of the virtual database. That means we need re-establish runtime status. For example, all the existing sessions will be killed.
* Runtime environment are often shared, that could kill other person's tasks in flight leaving them hanging with errors.
* Every time data source starts we fetch metadata from the source, this is very expensive operation.
* With multi-source feature, it is a feature that user dynamically brings in/out sources as they show up on their dashboard, it would be not possible to support this feature.
* This is a change of behavior from earlier versions of the EAP, our users and customers rely on this feature
As per Teiid project is concerned, we consider this is regression on WF and thus a bug.
h3. Proposed Solution
[~brian.stansberry] suggested the WF management practices here in this document https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-Apply...
Based on this the conclusion is that Data Sources, is developed under "all-services" paradigm, not under "resource-services" paradigm, where a explicit header from client to whether to restart or not can avoid having to "reload" the server when a new DS is added or removed. We understand the nature of service dependencies in WF, and how this can affect the other dependent services, but we verified that Teiid will not have those side effects as we designed. Since these sources are effectively exclusively defined for Teiid should not interfere with others. Also, since the request is explicit, should not affect current behavior.
h3. Workarounds Considered
Since this highly dependent on configuration based data source creation, we can opt to a deployment based data source creation (-ds.xml), however GSS is quick to dismiss this as this not supported feature.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6772) Intermittent failures in ConcurrentFineWebFailoverTestCase(SYNC-tcp).testGracefulUndeployFailover
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6772?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-6772:
---------------------------------
Priority: Minor (was: Major)
> Intermittent failures in ConcurrentFineWebFailoverTestCase(SYNC-tcp).testGracefulUndeployFailover
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-6772
> URL: https://issues.jboss.org/browse/WFLY-6772
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
> Fix For: 10.1.0.Final
>
>
> 172 runs / 5 failures / 0 ignored Success rate: 97.1%
> org.jboss.as.test.clustering.cluster.web (1)
> ConcurrentFineWebFailoverTestCase(SYNC-tcp).testGracefulUndeployFailover — Muted on 07 Jun 16 14:48 by Tomaz Cerar
>
> First failure: pull/1628 #2988 Changes (73) 22 Jun 16 16:47
> java.lang.AssertionError: Session failed to replicate after container 1 was shutdown. expected:<7> but was:<6>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.jboss.as.test.clustering.cluster.web.AbstractWebFailoverTestCase.testFailover(AbstractWebFailoverTestCase.java:207)
> at org.jboss.as.test.clustering.cluster.web.AbstractWebFailoverTestCase.testGracefulUndeployFailover(AbstractWebFailoverTestCase.java:103)
> https://ci.wildfly.org/viewLog.html?buildId=19454&tab=buildResultsDiv&bui...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6772) Intermittent failures in ConcurrentFineWebFailoverTestCase(SYNC-tcp).testGracefulUndeployFailover
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6772?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-6772:
---------------------------------
Affects Version/s: 10.0.0.Final
> Intermittent failures in ConcurrentFineWebFailoverTestCase(SYNC-tcp).testGracefulUndeployFailover
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-6772
> URL: https://issues.jboss.org/browse/WFLY-6772
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 10.1.0.Final
>
>
> 172 runs / 5 failures / 0 ignored Success rate: 97.1%
> org.jboss.as.test.clustering.cluster.web (1)
> ConcurrentFineWebFailoverTestCase(SYNC-tcp).testGracefulUndeployFailover — Muted on 07 Jun 16 14:48 by Tomaz Cerar
>
> First failure: pull/1628 #2988 Changes (73) 22 Jun 16 16:47
> java.lang.AssertionError: Session failed to replicate after container 1 was shutdown. expected:<7> but was:<6>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.jboss.as.test.clustering.cluster.web.AbstractWebFailoverTestCase.testFailover(AbstractWebFailoverTestCase.java:207)
> at org.jboss.as.test.clustering.cluster.web.AbstractWebFailoverTestCase.testGracefulUndeployFailover(AbstractWebFailoverTestCase.java:103)
> https://ci.wildfly.org/viewLog.html?buildId=19454&tab=buildResultsDiv&bui...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6772) Intermittent failures in ConcurrentFineWebFailoverTestCase(SYNC-tcp).testGracefulUndeployFailover
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6772?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-6772:
---------------------------------
Fix Version/s: 10.1.0.Final
> Intermittent failures in ConcurrentFineWebFailoverTestCase(SYNC-tcp).testGracefulUndeployFailover
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-6772
> URL: https://issues.jboss.org/browse/WFLY-6772
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 10.1.0.Final
>
>
> 172 runs / 5 failures / 0 ignored Success rate: 97.1%
> org.jboss.as.test.clustering.cluster.web (1)
> ConcurrentFineWebFailoverTestCase(SYNC-tcp).testGracefulUndeployFailover — Muted on 07 Jun 16 14:48 by Tomaz Cerar
>
> First failure: pull/1628 #2988 Changes (73) 22 Jun 16 16:47
> java.lang.AssertionError: Session failed to replicate after container 1 was shutdown. expected:<7> but was:<6>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.jboss.as.test.clustering.cluster.web.AbstractWebFailoverTestCase.testFailover(AbstractWebFailoverTestCase.java:207)
> at org.jboss.as.test.clustering.cluster.web.AbstractWebFailoverTestCase.testGracefulUndeployFailover(AbstractWebFailoverTestCase.java:103)
> https://ci.wildfly.org/viewLog.html?buildId=19454&tab=buildResultsDiv&bui...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6771) Add suspend/resume utility for the test suite
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-6771?page=com.atlassian.jira.plugin.... ]
James Perkins updated WFLY-6771:
--------------------------------
Description: Currently all suspend/resume tests just use the {{suspend}} and {{resume}} operations. A utility would be helpful to keep the suspend and resume functionality consistent. -There should also be a way to wait for the server to fully suspend and/or wait for the server to fully resume.- (was: Currently all suspend/resume tests just use the {{suspend}} and {{resume}} operations. A utility would be helpful to keep the suspend and resume functionality consistent. There should also be a way to wait for the server to fully suspend and/or wait for the server to fully resume.)
> Add suspend/resume utility for the test suite
> ---------------------------------------------
>
> Key: WFLY-6771
> URL: https://issues.jboss.org/browse/WFLY-6771
> Project: WildFly
> Issue Type: Task
> Components: Test Suite
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Optional
>
> Currently all suspend/resume tests just use the {{suspend}} and {{resume}} operations. A utility would be helpful to keep the suspend and resume functionality consistent. -There should also be a way to wait for the server to fully suspend and/or wait for the server to fully resume.-
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6772) Intermittent failures in ConcurrentFineWebFailoverTestCase(SYNC-tcp).testGracefulUndeployFailover
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6772?page=com.atlassian.jira.plugin.... ]
Radoslav Husar moved JIRAPLAY-155 to WFLY-6772:
-----------------------------------------------
Project: WildFly (was: JIRA Playground)
Key: WFLY-6772 (was: JIRAPLAY-155)
Workflow: GIT Pull Request workflow (was: classic default workflow)
> Intermittent failures in ConcurrentFineWebFailoverTestCase(SYNC-tcp).testGracefulUndeployFailover
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-6772
> URL: https://issues.jboss.org/browse/WFLY-6772
> Project: WildFly
> Issue Type: Bug
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> 172 runs / 5 failures / 0 ignored Success rate: 97.1%
> org.jboss.as.test.clustering.cluster.web (1)
> ConcurrentFineWebFailoverTestCase(SYNC-tcp).testGracefulUndeployFailover — Muted on 07 Jun 16 14:48 by Tomaz Cerar
>
> First failure: pull/1628 #2988 Changes (73) 22 Jun 16 16:47
> java.lang.AssertionError: Session failed to replicate after container 1 was shutdown. expected:<7> but was:<6>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.jboss.as.test.clustering.cluster.web.AbstractWebFailoverTestCase.testFailover(AbstractWebFailoverTestCase.java:207)
> at org.jboss.as.test.clustering.cluster.web.AbstractWebFailoverTestCase.testGracefulUndeployFailover(AbstractWebFailoverTestCase.java:103)
> https://ci.wildfly.org/viewLog.html?buildId=19454&tab=buildResultsDiv&bui...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1614) Requesting CLI Equivalent of Remote Echo / set -x in non-interactive mode (from within scripts)
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1614?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1614:
------------------------------------------
[~aloubyansky][~jdenise] This is already merged but EAP7-525 needs to move through the Kanban process.
> Requesting CLI Equivalent of Remote Echo / set -x in non-interactive mode (from within scripts)
> -----------------------------------------------------------------------------------------------
>
> Key: WFCORE-1614
> URL: https://issues.jboss.org/browse/WFCORE-1614
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
> Fix For: 3.0.0.Alpha3
>
>
> We are proposing here to add a Cli option (command line option and an XML element) to make the CLI to echo the command and its options in non interactive mode. This will help to match a given command and its output.
> For example, the "ls -l" command output would be:
> [standalone@localhost:9990 /] ls -l
> ATTRIBUTE VALUE TYPE
> launch-type STANDALONE STRING
> management-major-version 5 INT
> management-micro-version 0 INT
> management-minor-version 0 INT
> ...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6771) Add suspend/resume utility for the test suite
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-6771?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFLY-6771:
-------------------------------------
Ah okay thanks. I wasn't aware of that. I made the assumption since there were different {{suspend-state}} values that the {{suspend}} operation would return immediately. It does look like {{resume}} waits for everything to be resumed before it changes the {{suspend-state}} back to running so it looks good. I'll remove all the waiting I have which just makes it easier.
> Add suspend/resume utility for the test suite
> ---------------------------------------------
>
> Key: WFLY-6771
> URL: https://issues.jboss.org/browse/WFLY-6771
> Project: WildFly
> Issue Type: Task
> Components: Test Suite
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Optional
>
> Currently all suspend/resume tests just use the {{suspend}} and {{resume}} operations. A utility would be helpful to keep the suspend and resume functionality consistent. There should also be a way to wait for the server to fully suspend and/or wait for the server to fully resume.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6769) Intermittent failures in ConcurrentFineWebFailoverTestCase(SYNC-tcp).testGracefulUndeployFailover
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6769?page=com.atlassian.jira.plugin.... ]
Radoslav Husar reassigned WFLY-6769:
------------------------------------
Assignee: Radoslav Husar (was: Paul Ferraro)
> Intermittent failures in ConcurrentFineWebFailoverTestCase(SYNC-tcp).testGracefulUndeployFailover
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-6769
> URL: https://issues.jboss.org/browse/WFLY-6769
> Project: WildFly
> Issue Type: Quality Risk
> Components: Clustering
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> 172 runs / 5 failures / 0 ignored Success rate: 97.1%
> org.jboss.as.test.clustering.cluster.web (1)
> ConcurrentFineWebFailoverTestCase(SYNC-tcp).testGracefulUndeployFailover — Muted on 07 Jun 16 14:48 by Tomaz Cerar
>
> First failure: pull/1628 #2988 Changes (73) 22 Jun 16 16:47
> java.lang.AssertionError: Session failed to replicate after container 1 was shutdown. expected:<7> but was:<6>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.jboss.as.test.clustering.cluster.web.AbstractWebFailoverTestCase.testFailover(AbstractWebFailoverTestCase.java:207)
> at org.jboss.as.test.clustering.cluster.web.AbstractWebFailoverTestCase.testGracefulUndeployFailover(AbstractWebFailoverTestCase.java:103)
> https://ci.wildfly.org/viewLog.html?buildId=19454&tab=buildResultsDiv&bui...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months