[JBoss JIRA] (WFWIP-276) Boot time of application built via S2I is much longer than in before-Galleon times
by Jean Francois Denise (Jira)
[ https://issues.jboss.org/browse/WFWIP-276?page=com.atlassian.jira.plugin.... ]
Jean Francois Denise commented on WFWIP-276:
--------------------------------------------
[~jbliznak], I agree with the scope. That has the size of an RFE but should be treated as an implementation detail. I am not sure we want to document/support this feature outside the cloud context. We will need to document the main workflow (how a server reach the stabilized state), but should be short and hide a lot of the details.
> Boot time of application built via S2I is much longer than in before-Galleon times
> ----------------------------------------------------------------------------------
>
> Key: WFWIP-276
> URL: https://issues.jboss.org/browse/WFWIP-276
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Jan Blizňák
> Assignee: Jean Francois Denise
> Priority: Critical
> Attachments: test-app.zip
>
>
> As a consequence of Galleon RFEs EAP7-891 and mainly EAP7-1216 there is big difference in pod with EAP application start up time which requires S2I configuration.
> This is an overview of quick comparison of average boot times of the application pods of the attached test app (we are not interested in build/deploy pod times etc):
> ||17.0-6||pod time||EAP boot||config time
> |#1 | 8283|6128|2155
> |#2 | 9446|7548|1898
> |#3 | 8767|6871| 1896
> |#4 | 8568|6272| 2296
> |#5 | 8000 |6362|1638
> ||average ||8613ms||6636ms||1977ms
> ||18.0-7||pod time||EAP boot||config time
> |#1 |13769|5716|8053
> |#2 |13362|5952|7410
> |#3 |14261|6093|8168
> |#4 |14322|6135|8187
> |#5 |13921|6326|7595
> ||average||13927ms||6044ms||7883ms
> pod time = time from the pod start until EAP is fully booted (log contains {{started in ..}})
> EAP boot = time of boot EAP itself == {{started in ..}}
> config time = the difference of previou timess = anything before EAP boot begins
> Again we are talking here about the time needed for prepared application image to full start. We can clearly see the EAP boot times are comparable between 17 and 18 images but the configs times are almost 4 times longer with CD18 images.
> This is very unfortunate as in my point of view the pod boot time is the most critical time for our users - they would typically prepare the app images only once in a time but their application can scale up and down many times during its uptime.
> The cause of this that when S2I is needed with image 18.0+ the part of the configuration that was previously done during S2I build just once is now processed on *each* pod start.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (DROOLS-4799) Adding "expression" type handling for Collection type propereties
by Yeser Amer (Jira)
[ https://issues.jboss.org/browse/DROOLS-4799?page=com.atlassian.jira.plugi... ]
Yeser Amer commented on DROOLS-4799:
------------------------------------
[~uxdlc]
1) Correct. We need to define more in details the notification part. In my opinion, we should have a notification BEFORE switching the context.
2) The screenshot you provided is for NOT COLLECTION case. Here, an expression for a normal property is shown. What I should show in case of a Collection created with an expression?
> Adding "expression" type handling for Collection type propereties
> -----------------------------------------------------------------
>
> Key: DROOLS-4799
> URL: https://issues.jboss.org/browse/DROOLS-4799
> Project: Drools
> Issue Type: Feature Request
> Components: Scenario Simulation and Testing, Test Scenarios Editor
> Reporter: Yeser Amer
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: UX, UXTeam
> Attachments: Screen Shot 2019-11-26 at 1.26.54 PM.png
>
>
> I need a clarification regarding the behaviour of the updated Collection Editor, in particular for this section -->https://marvelapp.com/5ab248j/screen/62093042/layer/102496330.
> Considering the editor introduces a new way to handle a Collection ("Define List"), can you please give us detailed behaviour for the following case:
> - What happen if a user starts to input data inside a section (Define List/Create List) and then switch on the other one?
> eg. if I start to define a List using "Define List" option (i.e. an expression) and then I change to "Create List" case. What should happen?
> - Currently, after adding a Collection, the Grid cell will show "List (1)". It should be the same for "Define list" (i.e. Expression) case?
> In case of additional clarificaiton, I'll update this ticket.
> Hope it's clear, if not you can contact me anytime.
> Thanks
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (WFCORE-4768) WFLYIO001: Worker 'default' has auto-configured to 24 core threads should be IO threads
by Ricardo Martin Camarero (Jira)
[ https://issues.jboss.org/browse/WFCORE-4768?page=com.atlassian.jira.plugi... ]
Ricardo Martin Camarero commented on WFCORE-4768:
-------------------------------------------------
It seems the message is confusing for some users. The current options in the CLI interface are:
{noformat}
"io-threads" => {
"type" => INT,
"description" => "Specify the number of I/O threads to create for the worker. If not specified, a default will be chosen, which is calculated by cpuCount * 2",
"expressions-allowed" => true,
"required" => false,
"nillable" => true,
"min" => 0L,
"max" => 2147483647L,
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "all-services"
},
"task-max-threads" => {
"type" => INT,
"description" => "Specify the maximum number of threads for the worker task thread pool.If not set, default value used which is calculated by formula cpuCount * 16,as long as MaxFileDescriptorCount jmx property allows that number, otherwise calculation takes max into account to adjust it accordingly.",
"expressions-allowed" => true,
"required" => false,
"nillable" => true,
"min" => 0L,
"max" => 2147483647L,
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "all-services"
}
{noformat}
So we are going to change the messages (there are four messages for these two auto-configured values):
* "XX core threads" => "XX IO threads"
* "XX task threads" => "XX max task threads"
> WFLYIO001: Worker 'default' has auto-configured to 24 core threads should be IO threads
> ---------------------------------------------------------------------------------------
>
> Key: WFCORE-4768
> URL: https://issues.jboss.org/browse/WFCORE-4768
> Project: WildFly Core
> Issue Type: Bug
> Components: IO
> Affects Versions: 11.0.0.Beta3
> Reporter: Ricardo Martin Camarero
> Assignee: Ricardo Martin Camarero
> Priority: Minor
>
> [org.wildfly.extension.io] (ServerService Thread Pool -- 52) WFLYIO001: Worker 'default' has auto-configured to 24 core threads with 192 task threads based on your 12 available processors
> The IO subsystem by default picks values for the thread default sizes.
> The '24 core threads' is actually io-threads
> The '192 task threads' is the 'task-max-threads'
> The task-core-threads looks like it actually defaults to 2
> It would be better to change '24 core threads' to '24 IO threads' and 192 task threads' to 192 max task threads'
> {code}
> list-get map-put read-attribute-group read-children-types read-resource-description write-attribute
> [standalone@localhost:9990 /] /subsystem=io:read-resource(include-runtime=true,recursive=true)
> {
> "outcome" => "success",
> "result" => {
> "buffer-pool" => {"default" => {
> "buffer-size" => undefined,
> "buffers-per-slice" => undefined,
> "direct-buffers" => undefined
> }},
> "worker" => {"default" => {
> "busy-task-thread-count" => 0,
> "core-pool-size" => 2,
> "io-thread-count" => 24,
> "io-threads" => "24",
> "max-pool-size" => 192,
> "queue-size" => 0,
> "shutdown-requested" => false,
> "stack-size" => "0",
> "task-core-threads" => "2",
> "task-keepalive" => "60000",
> "task-max-threads" => "192",
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (WFCORE-4768) WFLYIO001: Worker 'default' has auto-configured to 24 core threads should be IO threads
by Ricardo Martin Camarero (Jira)
[ https://issues.jboss.org/browse/WFCORE-4768?page=com.atlassian.jira.plugi... ]
Ricardo Martin Camarero updated WFCORE-4768:
--------------------------------------------
Summary: WFLYIO001: Worker 'default' has auto-configured to 24 core threads should be IO threads (was: [GSS](7.2.z) WFLYIO001: Worker 'default' has auto-configured to 24 core threads should be IO threads)
> WFLYIO001: Worker 'default' has auto-configured to 24 core threads should be IO threads
> ---------------------------------------------------------------------------------------
>
> Key: WFCORE-4768
> URL: https://issues.jboss.org/browse/WFCORE-4768
> Project: WildFly Core
> Issue Type: Bug
> Components: IO
> Affects Versions: 11.0.0.Beta3
> Reporter: Ricardo Martin Camarero
> Assignee: Ricardo Martin Camarero
> Priority: Minor
>
> [org.wildfly.extension.io] (ServerService Thread Pool -- 52) WFLYIO001: Worker 'default' has auto-configured to 24 core threads with 192 task threads based on your 12 available processors
> The IO subsystem by default picks values for the thread default sizes.
> The '24 core threads' is actually io-threads
> The '192 task threads' is the 'task-max-threads'
> The task-core-threads looks like it actually defaults to 2
> It would be better to change '24 core threads' to '24 IO threads' and 192 task threads' to 192 max task threads'
> {code}
> list-get map-put read-attribute-group read-children-types read-resource-description write-attribute
> [standalone@localhost:9990 /] /subsystem=io:read-resource(include-runtime=true,recursive=true)
> {
> "outcome" => "success",
> "result" => {
> "buffer-pool" => {"default" => {
> "buffer-size" => undefined,
> "buffers-per-slice" => undefined,
> "direct-buffers" => undefined
> }},
> "worker" => {"default" => {
> "busy-task-thread-count" => 0,
> "core-pool-size" => 2,
> "io-thread-count" => 24,
> "io-threads" => "24",
> "max-pool-size" => 192,
> "queue-size" => 0,
> "shutdown-requested" => false,
> "stack-size" => "0",
> "task-core-threads" => "2",
> "task-keepalive" => "60000",
> "task-max-threads" => "192",
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (WFCORE-482) Add log4j2 support for WildFly
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFCORE-482?page=com.atlassian.jira.plugin... ]
James Perkins commented on WFCORE-482:
--------------------------------------
Thanks for the detailed information [~marlowa42]. That CVE is fixed in WildFly as well see https://github.com/jboss-logging/log4j-jboss-logmanager/pull/15.
For log4j we actually use a fork that routes through the JBoss Log Manager. The main reason for including log4j is for legacy applications. That said we should make adding log4j2 support higher priority. I do have an implementation that does work with the JBoss Log Manager, I just have had time to work on the integration and testing of it.
> Add log4j2 support for WildFly
> ------------------------------
>
> Key: WFCORE-482
> URL: https://issues.jboss.org/browse/WFCORE-482
> Project: WildFly Core
> Issue Type: Task
> Components: Logging
> Environment: Spring 3, Hibernate, Wicket, JBoss AS7
> Reporter: Amarkanth Ranganamayna
> Assignee: James Perkins
> Priority: Major
>
> I am trying to use Flume Appender which comes with Log4j2 (log4j 1.x doesn't support flume appender) (AND) inorder to acheive this, I am looking at how to configure JBoss AS7 to use log4j2.
> Looks like Jboss AS7 by default use log4j 1.x
> Are you guys already working on using log4j2 ?
> If NOT, can you please suggest how to configure Jboss AS7 such that it picks up "log4j2.xml" file and doesn't use its own logging.
> Thanks,
> Amar
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (WFCORE-4768) [GSS](7.2.z) WFLYIO001: Worker 'default' has auto-configured to 24 core threads should be IO threads
by Ricardo Martin Camarero (Jira)
[ https://issues.jboss.org/browse/WFCORE-4768?page=com.atlassian.jira.plugi... ]
Ricardo Martin Camarero moved JBEAP-18190 to WFCORE-4768:
---------------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-4768 (was: JBEAP-18190)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: IO
(was: Server)
Affects Version/s: 11.0.0.Beta3
(was: 7.2.5.GA)
> [GSS](7.2.z) WFLYIO001: Worker 'default' has auto-configured to 24 core threads should be IO threads
> ----------------------------------------------------------------------------------------------------
>
> Key: WFCORE-4768
> URL: https://issues.jboss.org/browse/WFCORE-4768
> Project: WildFly Core
> Issue Type: Bug
> Components: IO
> Affects Versions: 11.0.0.Beta3
> Reporter: Ricardo Martin Camarero
> Assignee: Ricardo Martin Camarero
> Priority: Minor
>
> [org.wildfly.extension.io] (ServerService Thread Pool -- 52) WFLYIO001: Worker 'default' has auto-configured to 24 core threads with 192 task threads based on your 12 available processors
> The IO subsystem by default picks values for the thread default sizes.
> The '24 core threads' is actually io-threads
> The '192 task threads' is the 'task-max-threads'
> The task-core-threads looks like it actually defaults to 2
> It would be better to change '24 core threads' to '24 IO threads' and 192 task threads' to 192 max task threads'
> {code}
> list-get map-put read-attribute-group read-children-types read-resource-description write-attribute
> [standalone@localhost:9990 /] /subsystem=io:read-resource(include-runtime=true,recursive=true)
> {
> "outcome" => "success",
> "result" => {
> "buffer-pool" => {"default" => {
> "buffer-size" => undefined,
> "buffers-per-slice" => undefined,
> "direct-buffers" => undefined
> }},
> "worker" => {"default" => {
> "busy-task-thread-count" => 0,
> "core-pool-size" => 2,
> "io-thread-count" => 24,
> "io-threads" => "24",
> "max-pool-size" => 192,
> "queue-size" => 0,
> "shutdown-requested" => false,
> "stack-size" => "0",
> "task-core-threads" => "2",
> "task-keepalive" => "60000",
> "task-max-threads" => "192",
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (DROOLS-4833) [DMN Designer] Data Types - edit is not consistent
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-4833?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-4833:
--------------------------------
Description: There is an inconsistent behavior of the "edit" mode according to the way in invoke it. See the video. Once started by mouse, once by keyboard. (was: There are a couple of keyboard problems related to tab index:
- When adding or editing a row, you can't tab the focus onto the save/cancel buttons (/)
- After selecting from the dropdown, the focus jumps back to the text field for some reason (/)
- The focus ring is not shown on the list toggle (/)
)
> [DMN Designer] Data Types - edit is not consistent
> --------------------------------------------------
>
> Key: DROOLS-4833
> URL: https://issues.jboss.org/browse/DROOLS-4833
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.31.0.Final
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Major
> Labels: drools-tools
> Attachments: edit-focus.webm
>
>
> There is an inconsistent behavior of the "edit" mode according to the way in invoke it. See the video. Once started by mouse, once by keyboard.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (DROOLS-4833) [DMN Designer] Data Types - edit is not consistent
by Jozef Marko (Jira)
Jozef Marko created DROOLS-4833:
-----------------------------------
Summary: [DMN Designer] Data Types - edit is not consistent
Key: DROOLS-4833
URL: https://issues.jboss.org/browse/DROOLS-4833
Project: Drools
Issue Type: Bug
Components: DMN Editor
Reporter: Jozef Marko
Assignee: Daniel José dos Santos
Attachments: edit-focus.webm
There are a couple of keyboard problems related to tab index:
- When adding or editing a row, you can't tab the focus onto the save/cancel buttons (/)
- After selecting from the dropdown, the focus jumps back to the text field for some reason (/)
- The focus ring is not shown on the list toggle (/)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (DROOLS-4833) [DMN Designer] Data Types - edit is not consistent
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-4833?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-4833:
--------------------------------
Attachment: (was: constraints-focus.webm)
> [DMN Designer] Data Types - edit is not consistent
> --------------------------------------------------
>
> Key: DROOLS-4833
> URL: https://issues.jboss.org/browse/DROOLS-4833
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.31.0.Final
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Major
> Labels: drools-tools
> Attachments: edit-focus.webm
>
>
> There are a couple of keyboard problems related to tab index:
> - When adding or editing a row, you can't tab the focus onto the save/cancel buttons (/)
> - After selecting from the dropdown, the focus jumps back to the text field for some reason (/)
> - The focus ring is not shown on the list toggle (/)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years