July 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1639) Causing the process to terminate before subsystems are processed prevents management depending on subsystem provided capabilities.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1639?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1639: ------------------------------------------ [~ehugonnet] FYI. Let's talk about this one on today's bluejeans. > Causing the process to terminate before subsystems are processed prevents management depending on subsystem provided capabilities. > ---------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1639 > URL: https://issues.jboss.org/browse/WFCORE-1639 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Brian Stansberry > Priority: Blocker > Labels: affects_elytron > Fix For: 3.0.0.Alpha4 > > > I am raising this immediately as a Blocker as the changes made for WFCORE-307 effectively prevent us from referencing Elytron supplied capabilities to secure the management interfaces. > https://github.com/wildfly/wildfly-core/commit/13d8f51b79c8b976ec7a5489c9... > I think at this point it would be easier to revert WFCORE-307 and re-evaluate. > To provide consistency we have all been working along the path where Elytron can be configured using a subsystem and used in all modes of the server, this was even a big motivation for Kabir's work bringing subsystems to host controllers. > We could take the view that only subsystems can depend on subsystems but I think we would quickly reach the point where we discuss moving management into a subsystem which would immediately obsolete the changes for WFCORE-307 - this move is something that has been talked about a number of times already. > This will need discussion but as an alternative idea for the original issue reported in WFCORE-307, how about adding the ability to flag a select few capabilities as crtitical / core and those will always cause a failure in this first boot if their requirements are not satisfied. > Also I think WFCORE-307 may only be a partial solution, if we are really saying the server can only run if it is manageable there is still the possibility that at stage RUNTIME the services will fail to start. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1632) Server processing request isn't stopped immediately but waits for request processing to finish

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1632?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1632: ------------------------------------------ {code} I haven't looked closely at the link in the description, but I figure it's ultimately about using a shared thread pool that is depended upon but not controlled by the webserver instead of using one that the webserver itself shuts down.{code} This was wrong. The issue is the change results in the WorkerService MSC service not stopping until the task being handled by the worker task pool (i.e. the request) completes. The shutdown hook we install blocks until the MSC service container terminates, so this prevents that hook completing. > Server processing request isn't stopped immediately but waits for request processing to finish > ---------------------------------------------------------------------------------------------- > > Key: WFCORE-1632 > URL: https://issues.jboss.org/browse/WFCORE-1632 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, IO, Server > Reporter: Lin Gao > Assignee: Lin Gao > Priority: Critical > Original Estimate: 1 day > Remaining Estimate: 1 day > > When stopping server which is processing request, it terminates the connection from the client but doesn't stop the request processing as such. > After debugging and searching when the issue appeared I've found out that the issue was introduced with this commit: [https://github.com/wildfly/wildfly-core/commit/7304c019705c5f7ec0378e1c51...] > Steps to reproduce: > 1) start EAP server with deployed app from attachment > 2) create request to long running application: {{curl -i http://127.0.0.1:8080/long-running-servlet/HeavyProcessing?duration=25000}} > 3) stop server (you can do it even gracefully) using {{./jboss-cli.sh -c ":shutdown(timeout=1)"}} > See that server is stopped after 25 seconds since request from step 2 was issued, as that is duration of the request processing requested by param duration, instead of being terminated after 1 second. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-542) Expose more Commands through the KieCommands API