[JBoss JIRA] (WFLY-3428) HC should remember the 'run' state of the server instances after crash or shutdown
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3428?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-3428:
-----------------------------------
Labels: EAP todo (was: todo)
> HC should remember the 'run' state of the server instances after crash or shutdown
> ----------------------------------------------------------------------------------
>
> Key: WFLY-3428
> URL: https://issues.jboss.org/browse/WFLY-3428
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Wolf-Dieter Fink
> Assignee: Brian Stansberry
> Labels: EAP, todo
>
> The host controller should save which server is currently up and running. This would allow the host controller to bring up all previously running instances on a restart.
> The idea is to support the same behavior that other application server (i.e WebLogic) supports.
> If a server is started or stopped during the lifetime of the DC/HC it should be in the same state after shutdown the DC/HC or a system crash.
> This can be achieved by an optional flag 'set-auto-start-on-start-stop' where the default is false which is the current behaviour.
> If set to true, a start of the server instance will set auto-start=true and a stop auto-start=false.
> If the server should not be started after a crash for any reason, this can be simple done by setting auto-start=false within the configuration, after starting the server the flag will be set b/c of the 'set-auto-start-on-start-stop' flag.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 11 months
[JBoss JIRA] (WFLY-3428) HC should remember the 'run' state of the server instances after crash or shutdown
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3428?page=com.atlassian.jira.plugin.... ]
Brian Stansberry moved PRODMGT-847 to WFLY-3428:
------------------------------------------------
Project: WildFly (was: Product Management)
Key: WFLY-3428 (was: PRODMGT-847)
Workflow: GIT Pull Request workflow (was: JBoss Platforms RFE Workflow v2)
Affects Version/s: (was: 6)
Component/s: Domain Management
(was: Enterprise Application Platform (EAP))
Security: Public
> HC should remember the 'run' state of the server instances after crash or shutdown
> ----------------------------------------------------------------------------------
>
> Key: WFLY-3428
> URL: https://issues.jboss.org/browse/WFLY-3428
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Wolf-Dieter Fink
> Assignee: Brian Stansberry
> Labels: EAP, todo
>
> The host controller should save which server is currently up and running. This would allow the host controller to bring up all previously running instances on a restart.
> The idea is to support the same behavior that other application server (i.e WebLogic) supports.
> If a server is started or stopped during the lifetime of the DC/HC it should be in the same state after shutdown the DC/HC or a system crash.
> This can be achieved by an optional flag 'set-auto-start-on-start-stop' where the default is false which is the current behaviour.
> If set to true, a start of the server instance will set auto-start=true and a stop auto-start=false.
> If the server should not be started after a crash for any reason, this can be simple done by setting auto-start=false within the configuration, after starting the server the flag will be set b/c of the 'set-auto-start-on-start-stop' flag.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 11 months
[JBoss JIRA] (WFLY-3427) Upgrade Narayana to 5.0.2.Final
by Tom Jenkinson (JIRA)
Tom Jenkinson created WFLY-3427:
-----------------------------------
Summary: Upgrade Narayana to 5.0.2.Final
Key: WFLY-3427
URL: https://issues.jboss.org/browse/WFLY-3427
Project: WildFly
Issue Type: Component Upgrade
Security Level: Public (Everyone can see)
Components: Transactions
Reporter: Tom Jenkinson
Assignee: Tom Jenkinson
Fix For: 9.0.0.Alpha1
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 11 months
[JBoss JIRA] (WFLY-3421) Rehashing on view change can result in premature session/ejb expiration
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-3421?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-3421:
------------------------------------
PR against master was merged. The 8.x PR was not, for whatever reason.
> Rehashing on view change can result in premature session/ejb expiration
> -----------------------------------------------------------------------
>
> Key: WFLY-3421
> URL: https://issues.jboss.org/browse/WFLY-3421
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.1.0.CR2
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Critical
> Fix For: 8.2.0.CR1, 9.0.0.Alpha1
>
>
> Session/ejb expiration is scheduled only the the owning node of a given session/ejb. When a node leaves each node that assumes ownership of the sessions/ejbs that were previously owned by the leaving node schedules expiration of those sessions. However, view change can also lead to ownership changes for any session/ejb. We are currently handling this properly. If a session/ejb changes ownership, the expiration scheduling is never cancelled, and that session/ejb will expire prematurely, unless the node reacquires ownership. When using sticky sessions, this issue is not apparent, since subsequent requests will direct to the previous owner, who will cancel expiration on the old owner and reschedule expiration on the new owner properly. However, this will be a problem for web sessions if sticky sessions is disabled - and for @Stateful EJBs, if the ejb client receives updated affinity information prior to subsequent requests.
> There are at least 2 ways to address this:
> # When a request arrives for an existing session/ejb, we immediately cancel any scheduled expiration/eviction. This is currently a unicast, which typically results in a local call - but can go remote if the ownership has changed. Making this a cluster-wide broadcast would fix the issue.
> # We can allow the scheduler to expose the set of keys that are currently schedule, and, on topology change, cancel those sessions/ejbs for which the current node is no longer the owner - and reschedule on the new owner.
> Option 1 adds an additional cluster-wide RPC per request.
> Option 2 adds N*(N-1) unicast RPCs per view change, where N is the cluster size (i.e. each node sends 1 rpc to every other node containing the set of session/ejb IDs to schedule for expiration),
> Option 2 is the least invasive solution of the two.
> EDIT: There is a 3rd options, i.e. modify the expiration tasks such that they skip expiration if the session/ejb is not owned by the current node. This is prevents the premature expiration issue, but we need some additional strategy to reschedule the session/ejb expiration on the node on the current owner.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 11 months
[JBoss JIRA] (WFLY-3421) Rehashing on view change can result in premature session/ejb expiration
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-3421?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-3421:
-------------------------------
Fix Version/s: 9.0.0.Alpha1
> Rehashing on view change can result in premature session/ejb expiration
> -----------------------------------------------------------------------
>
> Key: WFLY-3421
> URL: https://issues.jboss.org/browse/WFLY-3421
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.1.0.CR2
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Critical
> Fix For: 8.2.0.CR1, 9.0.0.Alpha1
>
>
> Session/ejb expiration is scheduled only the the owning node of a given session/ejb. When a node leaves each node that assumes ownership of the sessions/ejbs that were previously owned by the leaving node schedules expiration of those sessions. However, view change can also lead to ownership changes for any session/ejb. We are currently handling this properly. If a session/ejb changes ownership, the expiration scheduling is never cancelled, and that session/ejb will expire prematurely, unless the node reacquires ownership. When using sticky sessions, this issue is not apparent, since subsequent requests will direct to the previous owner, who will cancel expiration on the old owner and reschedule expiration on the new owner properly. However, this will be a problem for web sessions if sticky sessions is disabled - and for @Stateful EJBs, if the ejb client receives updated affinity information prior to subsequent requests.
> There are at least 2 ways to address this:
> # When a request arrives for an existing session/ejb, we immediately cancel any scheduled expiration/eviction. This is currently a unicast, which typically results in a local call - but can go remote if the ownership has changed. Making this a cluster-wide broadcast would fix the issue.
> # We can allow the scheduler to expose the set of keys that are currently schedule, and, on topology change, cancel those sessions/ejbs for which the current node is no longer the owner - and reschedule on the new owner.
> Option 1 adds an additional cluster-wide RPC per request.
> Option 2 adds N*(N-1) unicast RPCs per view change, where N is the cluster size (i.e. each node sends 1 rpc to every other node containing the set of session/ejb IDs to schedule for expiration),
> Option 2 is the least invasive solution of the two.
> EDIT: There is a 3rd options, i.e. modify the expiration tasks such that they skip expiration if the session/ejb is not owned by the current node. This is prevents the premature expiration issue, but we need some additional strategy to reschedule the session/ejb expiration on the node on the current owner.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 11 months
[JBoss JIRA] (WFLY-1197) Port the legacy jmx-console to AS7
by Rico Neubauer (JIRA)
[ https://issues.jboss.org/browse/WFLY-1197?page=com.atlassian.jira.plugin.... ]
Rico Neubauer commented on WFLY-1197:
-------------------------------------
[~sebastian.laskawiec] tried your version on JBoss 7.1.1, however results in the same "JBAS019905: Should not get called", that is posted above.
> Port the legacy jmx-console to AS7
> ----------------------------------
>
> Key: WFLY-1197
> URL: https://issues.jboss.org/browse/WFLY-1197
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JMX
> Reporter: Dimitris Andreadis
> Assignee: Darran Lofthouse
> Labels: JMX, as7, jmx-console, management_security,, management_sso
> Attachments: jmx-console.war, jmx-console.war
>
>
> I've seen a few people asking for a port of the old jmx-console to AS7, for monitoring purposes, until equivalent functionality is available through the new GWT-based console.
> I've ported the old console in this branch:
> https://github.com/dandreadis/jboss-as/commits/jmx-console
> It only includes a new top-level directory 'jmx-console'. The directory is not build by default, and when you build it manually it does not alter the server configuration in any way, you need to manually copy the resulting target/jboss-as-jmx-console-VERSION.war to the server deployment directory (and rename it to jmx-console.war)
> If there is interest, it could be included in the AS7 distro in some top level 'legacy' directory so it is not deployed by default?
> The resulting .war is attached on this JIRA, in case someone wants to use it. It work just as well on AS 7.0.2 and the latest AS 7.1.x development branch.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
9 years, 11 months