[JBoss JIRA] (DROOLS-4575) Test Scenario: unsaved changes warning appears even if file has not been changed
by Daniele Zonca (Jira)
[ https://issues.redhat.com/browse/DROOLS-4575?page=com.atlassian.jira.plug... ]
Daniele Zonca commented on DROOLS-4575:
---------------------------------------
[~jomarko]
If I remember correctly it still reproduces if you do an action that can be undone, then undo it and try to close
> Test Scenario: unsaved changes warning appears even if file has not been changed
> --------------------------------------------------------------------------------
>
> Key: DROOLS-4575
> URL: https://issues.redhat.com/browse/DROOLS-4575
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Daniele Zonca
> Priority: Major
> Labels: CustomerFocus, drools-tools
>
> If user opens a scesim file and then close it, no confirmation message should be opened
> h2. Manual Acceptance Test
> - Opening and closing without changes
> - Open, change data in cell, close
> - Open, add column, remove column, change column binding, close
> - Open, Change settings on the settings panel (e.g. ruleflow group, kie session), close
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13276) Galleon provisioning is failing intermittently on s390
by Yeray Borges Santana (Jira)
Yeray Borges Santana created WFLY-13276:
-------------------------------------------
Summary: Galleon provisioning is failing intermittently on s390
Key: WFLY-13276
URL: https://issues.redhat.com/browse/WFLY-13276
Project: WildFly
Issue Type: Bug
Components: Build System
Reporter: Yeray Borges Santana
Assignee: Yeray Borges Santana
It seems to be randomly between build and dist modules, but in s390 environment the builds fail with the following error:
{noformat}
org.jboss.galleon.ProvisioningException: Failed to generate host.xml on {
[Step 3/4] "operation" => "composite",
[Step 3/4] "address" => [],
[Step 3/4] "rollback-on-runtime-failure" => true,
[Step 3/4] "steps" => [
[Step 3/4] {
[Step 3/4] "operation" => "add",
[Step 3/4] "address" => [
[Step 3/4] {"host" => "master"},
[Step 3/4] {"subsystem" => "elytron"}
[Step 3/4] ],
[Step 3/4] "disallowed-providers" => ["OracleUcrypto"],
[Step 3/4] "final-providers" => "combined-providers"
[Step 3/4] },
[Step 3/4] {
[Step 3/4] "operation" => "add",
[Step 3/4] "address" => [
[Step 3/4] {"host" => "master"},
[Step 3/4] {"subsystem" => "elytron"},
[Step 3/4] {"provider-loader" => "elytron"}
[Step 3/4] ],
[Step 3/4] "module" => "org.wildfly.security.elytron"
[Step 3/4] },
[Step 3/4] {
[Step 3/4] "operation" => "add",
[Step 3/4] "address" => [
[Step 3/4] {"host" => "master"},
[Step 3/4] {"subsystem" => "elytron"},
[Step 3/4] {"provider-loader" => "openssl"}
[Step 3/4] ],
[Step 3/4] "module" => "org.wildfly.openssl"
[Step 3/4] },
[Step 3/4] {
[Step 3/4] "operation" => "add",
[Step 3/4] "address" => [
[Step 3/4] {"host" => "master"},
[Step 3/4] {"subsystem" => "elytron"},
[Step 3/4] {"aggregate-providers" => "combined-providers"}
[Step 3/4] ],
[Step 3/4] "providers" => [
[Step 3/4] "elytron",
[Step 3/4] "openssl"
[Step 3/4] ]
[Step 3/4] },
[Step 3/4] {
[Step 3/4] "operation" => "add",
[Step 3/4] "address" => [
[Step 3/4] {"host" => "master"},
[Step 3/4] {"subsystem" => "elytron"},
[Step 3/4] {"identity-realm" => "local"}
[Step 3/4] ],
[Step 3/4] "identity" => "$local"
[Step 3/4] },
[Step 3/4] {
[Step 3/4] "operation" => "add",
[Step 3/4] "address" => [
[Step 3/4] {"host" => "master"},
[Step 3/4] {"subsystem" => "elytron"},
[Step 3/4] {"file-audit-log" => "local-audit"}
[Step 3/4] ],
[Step 3/4] "format" => "JSON",
[Step 3/4] "path" => "audit.log",
[Step 3/4] "relative-to" => "jboss.domain.log.dir"
[Step 3/4] },
[Step 3/4] {
[Step 3/4] "operation" => "add",
[Step 3/4] "address" => [
[Step 3/4] {"host" => "master"},
[Step 3/4] {"subsystem" => "elytron"},
[Step 3/4] {"constant-realm-mapper" => "local"}
[Step 3/4] ],
[Step 3/4] "realm-name" => "local"
[Step 3/4] },
[Step 3/4] {
[Step 3/4] "operation" => "add",
[Step 3/4] "address" => [
[Step 3/4] {"host" => "master"},
[Step 3/4] {"subsystem" => "elytron"},
[Step 3/4] {"provider-http-server-mechanism-factory" => "global"}
[Step 3/4] ]
[Step 3/4] },
[Step 3/4] {
[Step 3/4] "operation" => "add",
[Step 3/4] "address" => [
[Step 3/4] {"host" => "master"},
[Step 3/4] {"subsystem" => "elytron"},
[Step 3/4] {"simple-permission-mapper" => "default-permission-mapper"}
[Step 3/4] ],
[Step 3/4] "mapping-mode" => "first",
[Step 3/4] "permission-mappings" => [
[Step 3/4] {
[Step 3/4] "principals" => ["anonymous"],
[Step 3/4] "permission-sets" => [{"permission-set" => "default-permissions"}]
[Step 3/4] },
[Step 3/4] {
[Step 3/4] "match-all" => "true",
[Step 3/4] "permission-sets" => [
[Step 3/4] {"permission-set" => "login-permission"},
[Step 3/4] {"permission-set" => "default-permissions"}
[Step 3/4] ]
[Step 3/4] }
[Step 3/4] ]
[Step 3/4] },
[Step 3/4] {
[Step 3/4] "operation" => "add",
[Step 3/4] "address" => [
[Step 3/4] {"host" => "master"},
[Step 3/4] {"subsystem" => "elytron"},
[Step 3/4] {"simple-role-decoder" => "groups-to-roles"}
[Step 3/4] ],
[Step 3/4] "attribute" => "groups"
[Step 3/4] },
[Step 3/4] {
[Step 3/4] "operation" => "add",
[Step 3/4] "address" => [
[Step 3/4] {"host" => "master"},
[Step 3/4] {"subsystem" => "elytron"},
[Step 3/4] {"provider-sasl-server-factory" => "global"}
[Step 3/4] ]
[Step 3/4] },
[Step 3/4] {
[Step 3/4] "operation" => "add",
[Step 3/4] "address" => [
[Step 3/4] {"host" => "master"},
[Step 3/4] {"subsystem" => "elytron"},
[Step 3/4] {"mechanism-provider-filtering-sasl-server-factory" => "elytron"}
[Step 3/4] ],
[Step 3/4] "filters" => [{"provider-name" => "WildFlyElytron"}],
[Step 3/4] "sasl-server-factory" => "global"
[Step 3/4] },
[Step 3/4] {
[Step 3/4] "operation" => "add",
[Step 3/4] "address" => [
[Step 3/4] {"host" => "master"},
[Step 3/4] {"subsystem" => "elytron"},
[Step 3/4] {"configurable-sasl-server-factory" => "configured"}
[Step 3/4] ],
[Step 3/4] "properties" => {"wildfly.sasl.local-user.default-user" => "$local"},
[Step 3/4] "sasl-server-factory" => "elytron"
[Step 3/4] },
[Step 3/4] {
[Step 3/4] "operation" => "add",
[Step 3/4] "address" => [
[Step 3/4] {"host" => "master"},
[Step 3/4] {"subsystem" => "elytron"},
[Step 3/4] {"constant-role-mapper" => "super-user-mapper"}
[Step 3/4] ],
[Step 3/4] "roles" => ["SuperUser"]
[Step 3/4] },
[Step 3/4] {
[Step 3/4] "operation" => "add",
[Step 3/4] "address" => [
[Step 3/4] {"host" => "master"},
[Step 3/4] {"subsystem" => "elytron"},
[Step 3/4] {"permission-set" => "login-permission"}
[Step 3/4] ],
[Step 3/4] "permissions" => [{"class-name" => "org.wildfly.security.auth.permission.LoginPermission"}]
[Step 3/4] },
[Step 3/4] {
[Step 3/4] "operation" => "add",
[Step 3/4] "address" => [
[Step 3/4] {"host" => "master"},
[Step 3/4] {"subsystem" => "elytron"},
[Step 3/4] {"permission-set" => "default-permissions"}
[Step 3/4] ],
[Step 3/4] "permissions" => []
[Step 3/4] },
[Step 3/4] {
[Step 3/4] "operation" => "add",
[Step 3/4] "address" => [
[Step 3/4] {"host" => "master"},
[Step 3/4] {"subsystem" => "elytron"},
[Step 3/4] {"properties-realm" => "ManagementRealm"}
[Step 3/4] ],
[Step 3/4] "users-properties" => {
[Step 3/4] "path" => "mgmt-users.properties",
[Step 3/4] "relative-to" => "jboss.domain.config.dir",
[Step 3/4] "digest-realm-name" => "ManagementRealm"
[Step 3/4] }
[Step 3/4] },
[Step 3/4] {
[Step 3/4] "operation" => "write-attribute",
[Step 3/4] "address" => [
[Step 3/4] {"host" => "master"},
[Step 3/4] {"subsystem" => "elytron"},
[Step 3/4] {"properties-realm" => "ManagementRealm"}
[Step 3/4] ],
[Step 3/4] "name" => "groups-properties",
[Step 3/4] "value" => {
[Step 3/4] "path" => "mgmt-groups.properties",
[Step 3/4] "relative-to" => "jboss.domain.config.dir"
[Step 3/4] }
[Step 3/4] },
[Step 3/4] {
[Step 3/4] "operation" => "add",
[Step 3/4] "address" => [
[Step 3/4] {"host" => "master"},
[Step 3/4] {"subsystem" => "elytron"},
[Step 3/4] {"security-domain" => "ManagementDomain"}
[Step 3/4] ],
[Step 3/4] "default-realm" => "ManagementRealm",
[Step 3/4] "permission-mapper" => "default-permission-mapper",
[Step 3/4] "realms" => [
[Step 3/4] {
[Step 3/4] "realm" => "ManagementRealm",
[Step 3/4] "role-decoder" => "groups-to-roles"
[Step 3/4] },
[Step 3/4] {
[Step 3/4] "realm" => "local",
[Step 3/4] "role-mapper" => "super-user-mapper"
[Step 3/4] }
[Step 3/4] ]
[Step 3/4] },
[Step 3/4] {
[Step 3/4] "operation" => "add",
[Step 3/4] "address" => [
[Step 3/4] {"host" => "master"},
[Step 3/4] {"subsystem" => "elytron"},
[Step 3/4] {"sasl-authentication-factory" => "management-sasl-authentication"}
[Step 3/4] ],
[Step 3/4] "mechanism-configurations" => [
[Step 3/4] {
[Step 3/4] "mechanism-name" => "JBOSS-LOCAL-USER",
[Step 3/4] "realm-mapper" => "local"
[Step 3/4] },
[Step 3/4] {
[Step 3/4] "mechanism-name" => "DIGEST-MD5",
[Step 3/4] "mechanism-realm-configurations" => [{"realm-name" => "ManagementRealm"}]
[Step 3/4] }
[Step 3/4] ],
[Step 3/4] "sasl-server-factory" => "configured",
[Step 3/4] "security-domain" => "ManagementDomain"
[Step 3/4] },
[Step 3/4] {
[Step 3/4] "operation" => "add",
[Step 3/4] "address" => [
[Step 3/4] {"host" => "master"},
[Step 3/4] {"subsystem" => "elytron"},
[Step 3/4] {"http-authentication-factory" => "management-http-authentication"}
[Step 3/4] ],
[Step 3/4] "http-server-mechanism-factory" => "global",
[Step 3/4] "mechanism-configurations" => [{
[Step 3/4] "mechanism-name" => "BASIC",
[Step 3/4] "mechanism-realm-configurations" => [{"realm-name" => "Management Realm"}]
[Step 3/4] }],
[Step 3/4] "security-domain" => "ManagementDomain"
[Step 3/4] }
[Step 3/4] ]
[Step 3/4] }: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-2" => {
[Step 3/4] "WFLYCTL0412: Required services that are not installed:" => ["elytron.security-properties"],
[Step 3/4] "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.providers.elytron is missing [elytron.security-properties]"]
[Step 3/4] }}}
[Step 3/4] at org.wildfly.galleon.plugin.config.generator.WfConfigGenerator.doHandle(WfConfigGenerator.java:356)
[Step 3/4] at org.wildfly.galleon.plugin.config.generator.WfConfigGenerator.endBatch(WfConfigGenerator.java:272)
[Step 3/4] at org.wildfly.galleon.plugin.config.generator.WfConfigGenerator.executeScript(WfConfigGenerator.java:494)
[Step 3/4] at org.wildfly.galleon.plugin.config.generator.WfConfigGenerator.forkedForEmbedded(WfConfigGenerator.java:471)
[Step 3/4] at org.wildfly.galleon.plugin.server.ForkedEmbeddedUtil.main(ForkedEmbeddedUtil.java:208)
[Step 3/4] [INFO] Overall Galleon provisioning took 27.115 seconds
{noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13239) Fix s390 OpenJ9 domain mode testing
by Yeray Borges Santana (Jira)
[ https://issues.redhat.com/browse/WFLY-13239?page=com.atlassian.jira.plugi... ]
Yeray Borges Santana resolved WFLY-13239.
-----------------------------------------
Resolution: Done
The problem was in the Job configuration itself. The Java version used to run the test (OpenJDK 11) was not in sync with the Java version used to run the slaves (OpenJDK 8).
This situation was throwing out the following errors starting the tests:
{noformat}
[CLITestSuite] [Test Output]
JVMJ9VM007E Command-line option unrecognised: --add-exports=java.base/sun.nio.ch=ALL-UNNAMED
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
{noformat}
Notice the Job execution is also affected by WFLY-13276
> Fix s390 OpenJ9 domain mode testing
> -----------------------------------
>
> Key: WFLY-13239
> URL: https://issues.redhat.com/browse/WFLY-13239
> Project: WildFly
> Issue Type: Task
> Components: Test Suite
> Reporter: Brian Stansberry
> Assignee: Yeray Borges Santana
> Priority: Major
>
> Our CI tests of running on a s390 server using OpenJ9 are consistently failing in testsuite/domain:
> https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxS390OpenJ911
> Specifically CLITestSuite and DomainTestSuite fail. Task is to resolve those and get reasonably consistent execution of those parts of the testsuite.
> [~luck3y] can provide info re the infrastructure running this job.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13088) ejb: binding should not be listed if there is no Remote interface
by Ingo Weiss (Jira)
[ https://issues.redhat.com/browse/WFLY-13088?page=com.atlassian.jira.plugi... ]
Ingo Weiss updated WFLY-13088:
------------------------------
Labels: downstream_dependency (was: )
> ejb: binding should not be listed if there is no Remote interface
> -----------------------------------------------------------------
>
> Key: WFLY-13088
> URL: https://issues.redhat.com/browse/WFLY-13088
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Moulali Shikalwadi
> Assignee: Moulali Shikalwadi
> Priority: Major
> Labels: downstream_dependency
> Fix For: 20.0.0.Beta1
>
> Attachments: local.jar, remote.jar
>
> Original Estimate: 4 minutes
> Remaining Estimate: 4 minutes
>
> The `ejb:` binding should not be logged if the EJB does not implement the Remote interface.
> The `ejb:` is a message that gives the lookup path for an EJB with a remote interface, it should only be logged if the java:jboss/exported binding is logged as these are basically the same.
> EJBs that only implement a Local interface or EJBs with No interface view should not log the ejb:
> 20:15:02,699 INFO [org.jboss.as.ejb3.deployment] (MSC service thread 1-8) WFLYEJB0473: JNDI bindings for session bean named 'HelloBean' in deployment unit 'deployment "local.jar"' are as follows:
> java:global/local/HelloBean!test.HelloLocal
> java:app/local/HelloBean!test.HelloLocal
> java:module/HelloBean!test.HelloLocal
> ejb:/local/HelloBean!test.HelloLocal
> java:global/local/HelloBean
> java:app/local/HelloBean
> java:module/HelloBean
> 20:15:53,450 INFO [org.jboss.as.ejb3.deployment] (MSC service thread 1-5) WFLYEJB0473: JNDI bindings for session bean named 'HelloBean' in deployment unit 'deployment "no-interface.jar"' are as follows:
> java:global/no-interface/HelloBean!test.HelloBean
> java:app/no-interface/HelloBean!test.HelloBean
> java:module/HelloBean!test.HelloBean
> ejb:/no-interface/HelloBean!test.HelloBean
> java:global/no-interface/HelloBean
> java:app/no-interface/HelloBean
> java:module/HelloBean
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFCORE-4594) Expose CoreProcessStateService functionality used by subsystems via a capability
by Ingo Weiss (Jira)
[ https://issues.redhat.com/browse/WFCORE-4594?page=com.atlassian.jira.plug... ]
Ingo Weiss updated WFCORE-4594:
-------------------------------
Labels: downstream_dependency (was: )
> Expose CoreProcessStateService functionality used by subsystems via a capability
> --------------------------------------------------------------------------------
>
> Key: WFCORE-4594
> URL: https://issues.redhat.com/browse/WFCORE-4594
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Major
> Labels: downstream_dependency
> Fix For: 11.0.0.Beta1, 11.0.0.Final
>
>
> Subsystems are injecting CoreProcessStateService to track the process state, and perhaps more should as some are using graceful startup as a kind of trigger for beginning work, when the process reaching RUNNING state would be more appropriate. But:
> 1) they aren't using a capability for this wiring, because the kernel doesn't expose one
> 2) ControlledProcessStateService is not a clean API, as it exposes the MSC Service interface which should not be accessible to subsystems.
> So, add a ProcessStateNotifier interface, and expose it via a capability. Impl is still ControlledProcessStateService.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13269) The org.wildfly:wildfly-client-all artefact incorrectly contains the Elytron CDI extension
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-13269?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFLY-13269:
-----------------------------------------
[~brian.stansberry] Was hoping that would be your opinion - going to go ahead with tags for the full set.
> The org.wildfly:wildfly-client-all artefact incorrectly contains the Elytron CDI extension
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-13269
> URL: https://issues.redhat.com/browse/WFLY-13269
> Project: WildFly
> Issue Type: Bug
> Components: Build System, MP JWT, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 20.0.0.Beta1
>
>
> This means if the artefact is included in a deployment the JWT activation is incorrectly triggered but with some dependencies missing leading to an error such as the following.
> {code}
> 09:46:44,391 WARN [org.jboss.modules.define] (MSC service thread 1-1) Failed to define class org.wildfly.security.mp.jwt.JWTCDIExtension in Module "deployment.XXXX.ear" from Service Module Loader: java.lang.NoClassDefFoundError: Failed to link org/wildfly/security/mp/jwt/JWTCDIExtension (Module "deployment.XXXX.ear" from Service Module Loader): io/smallrye/jwt/auth/cdi/SmallRyeJWTAuthCDIExtension
> at java.lang.ClassLoader.defineClass1(ClassLoader.java)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13259) Memory leak in Hibernate pending-puts cache when L2 cache is enabled
by Sorin Potra (Jira)
[ https://issues.redhat.com/browse/WFLY-13259?page=com.atlassian.jira.plugi... ]
Sorin Potra commented on WFLY-13259:
------------------------------------
[~smarlow] the scenario you described above is correct. I will try to provide some more details on what we do. We have a pretty large JEE application running in WildFly. The application exposes multiple functionalities. The scenario causing the issue is pretty simple. The application models a folder structure very similar to the folder structure in a classical file system. So we have a Folder entity (the Parent in our scenario) and a File entity (the Child). A Folder can contain multiple Files. Then there is an external tool (an importer) that we use to import files in a folder. The importer performs the following actions:
- it connects to an external system and downloads a file. The binary itself is stored somewhere on the file system.
- once the binary is available locally, the importer performs a call to WildFly to create a new File entity and add it to the parent Folder. The binary itself is not stored in the database, only metadata about the file is stored in the DB
- once the new File is added to the parent Folder (WildFly call is completed), the importer moves on to the next file and so on. This process is repeated for thousands of files.
The reasons why I think this is a memory leak are as follows:
- at any given time a single transaction is active in WildFly (we do not overload WildFly with multiple transactions is parallel)
- the amount of data loaded in each transaction (its PersistenceContext) is far less than the amount of available memory and yet the memory usage continues to increase as old, completed transactions cannot be garbage collected
The data loaded by a transaction, including its PersistenceContext, should be eligible for GC once the transaction is completed.
I will add shortly another comment with some findings from my investigation on this including a workaround that I found.
> Memory leak in Hibernate pending-puts cache when L2 cache is enabled
> --------------------------------------------------------------------
>
> Key: WFLY-13259
> URL: https://issues.redhat.com/browse/WFLY-13259
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 18.0.1.Final, 19.0.0.Final
> Reporter: Sorin Potra
> Assignee: Scott Marlow
> Priority: Critical
> Attachments: PathToGCRoots_strong_refs.PNG, afterOOM.hprof.zip, beforeOOM.hprof.zip, pending-puts-leak.PNG, simple-hibernate-war-client.zip, simple-hibernate-war.war, simple-hibernate-war.zip
>
>
> Under certain conditions, described below, WildFly / Hibernate can leak memory into the pending-puts cache eventually causing an OutOfMemoryError. Attached you can find a web application and a standalone client that can be used to reproduce the problem. The web app defines two entities: a Parent and a Child. There is a bidirectional one-to-many relationship between the Parent and the Child. JPA L2 cache is enabled (Infinispan is the cache provider).
> Repeatedly executing a transaction that creates a new Child and adds it to the list of children in the Parent will cause the memory usage to increase steadily until OOM is encountered. If the execution of these transactions is stopped before reaching OOM, the memory will be reclaimed after a few minutes of inactivity.
> Attached you can find the following:
> - simple-hibernate-war.war - the web app that can be deployed in WildFly to reproduce the issue.
> - simple-hibernate-war.zip - the source code for the above web app. The servlet that is invoked by the client to create and persist a new Child is com.microfocus.sa.web.AddChildServlet
> - simple-hibernate-war-client.zip - the standalone client that can be used to invoke the AddChildServlet. After unzipping the archive, the client can be run with the following command from the client folder:
>
> java -cp bin com.microfocus.sa.client.AddChildClient
>
> If you need to run the client multiple times, you have to restart WildFly in between the runs, to start from a fresh state (the web app uses the h2 in memory databasewhich is reset at each restart).
> - pending-puts-leak.PNG - a screeshot from Memory Analyzer showing a leaked SessionImpl instance
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13188) Exception while exporting metrics during WildFly initialization
by Ehsan Zaery Moghaddam (Jira)
[ https://issues.redhat.com/browse/WFLY-13188?page=com.atlassian.jira.plugi... ]
Ehsan Zaery Moghaddam commented on WFLY-13188:
----------------------------------------------
[~brian.stansberry] Here is the answers:
1. Do all the log WARNINGs include the deployment part of a resource address?
No, it comes from different subsystems. Here are some other examples:
{code:bash}
("subsystem" => "datasources"),
("data-source" => "ExampleDS"),
("statistics" => "pool")
{code}
or
{code:bash}
("subsystem" => "jgroups"),
("channel" => "ee"),
("protocol" => "TCP")
{code}
2. Does your server have a multiple deployments, some of which take a long time to deploy?
Yes, we have multiple deployments and they take overall between 2 to 3 minutes to deploy. Our application is running on WildFly 18. We have not ported it to 19, but I can reproduce the error by starting a fresh WildFly 19 (which takes around 7 seconds) and while the server is starting, I keep calling the http://localhost:9990/metrics URL in my browser by refreshing the page repeatedly. It always triggers the exception.
> Exception while exporting metrics during WildFly initialization
> ---------------------------------------------------------------
>
> Key: WFLY-13188
> URL: https://issues.redhat.com/browse/WFLY-13188
> Project: WildFly
> Issue Type: Bug
> Components: MP Metrics
> Affects Versions: 18.0.1.Final, 19.0.0.Beta2
> Reporter: Ehsan Zaery Moghaddam
> Assignee: Jeff Mesnil
> Priority: Major
> Labels: Microprofile
>
> When the open tracing system is enabled and some metrics are exposed, if when the WildFly is in the startup process, the Prometheus server calls the /metrics endpoint, WildFly prints a stacktrace for each metrics that is has detected (i.e. more than thousands) with the following message:
> *WFLYCTL0379: System boot is in process; execution of remote management operations is not currently available
> *
> In some cases the error persists, even after the server startup is done and we need to restart the WildFly; but we couldn't find the exact scenario for that.
> Here is an example for wildfly_jpa_second_level_cache_size_in_memory metric:
> {code}
> 2020-03-02 09:38:06,739 WARN [management I/O-2] [metrics] Unable to export metric wildfly_jpa_second_level_cache_size_in_memory: java.lang.IllegalStateException: WFLYMETRICS0003: Unable to read attribute second-level-cache-size-in-memory on [
> ("deployment" => "application.ear"),
> ("subdeployment" => "application-persistence.jar"),
> ("subsystem" => "jpa"),
> ("hibernate-persistence-unit" => "application.ear/application-persistence.jar#app"),
> ("entity-cache" => "com.app.persistence.entity.Country")
> ]: "WFLYCTL0379: System boot is in process; execution of remote management operations is not currently available".
> at org.wildfly.extension.microprofile.metrics.MetricCollector.readAttributeValue(MetricCollector.java:303)
> at org.wildfly.extension.microprofile.metrics.MetricCollector.access$200(MetricCollector.java:70)
> at org.wildfly.extension.microprofile.metrics.MetricCollector$2.getValue(MetricCollector.java:174)
> at org.wildfly.extension.microprofile.metrics.MetricCollector$2.getValue(MetricCollector.java:171)
> at io.smallrye.metrics.exporters.OpenMetricsExporter.createSimpleValueLine(OpenMetricsExporter.java:445)
> at io.smallrye.metrics.exporters.OpenMetricsExporter.exposeEntries(OpenMetricsExporter.java:178)
> at io.smallrye.metrics.exporters.OpenMetricsExporter.getEntriesForScope(OpenMetricsExporter.java:150)
> at io.smallrye.metrics.exporters.OpenMetricsExporter.exportAllScopes(OpenMetricsExporter.java:101)
> at io.smallrye.metrics.MetricsRequestHandler.handleRequest(MetricsRequestHandler.java:116)
> at io.smallrye.metrics.MetricsRequestHandler.handleRequest(MetricsRequestHandler.java:73)
> at org.wildfly.extension.microprofile.metrics.MetricsContextService$1.handleRequest(MetricsContextService.java:81)
> at org.jboss.as.domain.http.server.security.RealmReadinessHandler.handleRequest(RealmReadinessHandler.java:51)
> at org.jboss.as.domain.http.server.security.ServerErrorReadinessHandler.handleRequest(ServerErrorReadinessHandler.java:35)
> at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:91)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:211)
> at io.undertow.server.handlers.cache.CacheHandler.handleRequest(CacheHandler.java:92)
> at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:78)
> at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
> at org.jboss.as.domain.http.server.ManagementHttpRequestHandler.handleRequest(ManagementHttpRequestHandler.java:57)
> at org.jboss.as.domain.http.server.cors.CorsHttpHandler.handleRequest(CorsHttpHandler.java:75)
> at org.jboss.as.domain.http.server.ManagementHttpServer$UpgradeFixHandler.handleRequest(ManagementHttpServer.java:666)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:376)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:255)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:59)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-5139) [DMN Designer] Decision Navigator does not update Diagram name
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-5139?page=com.atlassian.jira.plug... ]
Yeser Amer updated DROOLS-5139:
-------------------------------
Sprint: 2020 Week 13-15 (from Mar 23)
> [DMN Designer] Decision Navigator does not update Diagram name
> --------------------------------------------------------------
>
> Key: DROOLS-5139
> URL: https://issues.redhat.com/browse/DROOLS-5139
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.34.0.Final
> Reporter: Michael Anstis
> Assignee: Yeser Amer
> Priority: Major
> Labels: drools-tools
>
> Following changes for https://issues.redhat.com/browse/DROOLS-5137 it became evident that the Decision Navigator does not show updated Diagram names.
> This pre-exists DROOLS-5137 and DROOLS-5060 (i.e. it is not a regression), so this new JIRA has been created.
> * Create a new DMN Diagram
> * Expand Decision Navigator
> * Expand Properties Panel
> * Select _background_ i.e. _diagram_
> * Change name in Properties Panel
> * Decision Navigator does not update
> * Saving, closing and re-opening diagram shows updated name
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month