[JBoss JIRA] (WFCORE-2011) Inconsistency of formatter and named-formatter in console logging handler
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2011?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2011:
------------------------------------------
You had assigned this to yourself, so if you still wanted to work it, please ping me. The logic I discussed would be in org.jboss.as.controller.operations.global.ReadAttributeHandler, static "resolveAttribute" method.
> Inconsistency of formatter and named-formatter in console logging handler
> -------------------------------------------------------------------------
>
> Key: WFCORE-2011
> URL: https://issues.jboss.org/browse/WFCORE-2011
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha13
> Environment: It is possible to reproduce with all profiles and all modes.
> All WildFly profiles
> All WildFly clustering mode
> * standalone mode
> * domain mode
> Reporter: ted won
> Assignee: Brian Stansberry
> Priority: Minor
> Labels: logging
> Attachments: COLOR-PATTERN.png, CONSOLE-console-handler.png
>
>
> In logging subsystem the default CONSOLE console-handler is defined with COLOR-PATTERN named-formatter.
> And the COLOR-PATTERN named-formatter is defined with: {noformat}"%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"{noformat}
> It is working as it is defined with colors in a console.
> {code:title=standalone.xml}
> ...
> <subsystem xmlns="urn:jboss:domain:logging:3.0">
> <console-handler name="CONSOLE">
> <level name="INFO"/>
> <formatter>
> <named-formatter name="COLOR-PATTERN"/>
> </formatter>
> </console-handler>
> ...
> <formatter name="COLOR-PATTERN">
> <pattern-formatter pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"/>
> </formatter>
> </subsystem>
> ...
> {code}
> However there is a inconsistency in the CLI and WildFly admin console views.
> In the CLI, CONSOLE formatter is: {noformat}"%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"{noformat} It is wrong and different with the working logging format in a console.
> {code:title=JBoss CLI}
> [standalone@localhost:9990 /] /subsystem=logging/console-handler=CONSOLE:read-resource
> {
> "outcome" => "success",
> "result" => {
> "autoflush" => true,
> "enabled" => true,
> "encoding" => undefined,
> "filter" => undefined,
> "filter-spec" => undefined,
> "formatter" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n",
> "level" => "INFO",
> "name" => "CONSOLE",
> "named-formatter" => "COLOR-PATTERN",
> "target" => "System.out"
> }
> }
> {code}
> It should be fixed like below:
> {code:title=Expected result}
> [standalone@localhost:9990 /] /subsystem=logging/console-handler=CONSOLE:read-resource
> {
> "outcome" => "success",
> "result" => {
> "autoflush" => true,
> "enabled" => true,
> "encoding" => undefined,
> "filter" => undefined,
> "filter-spec" => undefined,
> "formatter" => undefined,
> "level" => "INFO",
> "name" => "CONSOLE",
> "named-formatter" => "COLOR-PATTERN",
> "target" => "System.out"
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2011) Inconsistency of formatter and named-formatter in console logging handler
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2011?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-2011:
----------------------------------------
Component/s: Domain Management
(was: Logging)
Assignee: Brian Stansberry (was: ted won)
> Inconsistency of formatter and named-formatter in console logging handler
> -------------------------------------------------------------------------
>
> Key: WFCORE-2011
> URL: https://issues.jboss.org/browse/WFCORE-2011
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha13
> Environment: It is possible to reproduce with all profiles and all modes.
> All WildFly profiles
> All WildFly clustering mode
> * standalone mode
> * domain mode
> Reporter: ted won
> Assignee: Brian Stansberry
> Priority: Minor
> Labels: logging
> Attachments: COLOR-PATTERN.png, CONSOLE-console-handler.png
>
>
> In logging subsystem the default CONSOLE console-handler is defined with COLOR-PATTERN named-formatter.
> And the COLOR-PATTERN named-formatter is defined with: {noformat}"%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"{noformat}
> It is working as it is defined with colors in a console.
> {code:title=standalone.xml}
> ...
> <subsystem xmlns="urn:jboss:domain:logging:3.0">
> <console-handler name="CONSOLE">
> <level name="INFO"/>
> <formatter>
> <named-formatter name="COLOR-PATTERN"/>
> </formatter>
> </console-handler>
> ...
> <formatter name="COLOR-PATTERN">
> <pattern-formatter pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"/>
> </formatter>
> </subsystem>
> ...
> {code}
> However there is a inconsistency in the CLI and WildFly admin console views.
> In the CLI, CONSOLE formatter is: {noformat}"%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"{noformat} It is wrong and different with the working logging format in a console.
> {code:title=JBoss CLI}
> [standalone@localhost:9990 /] /subsystem=logging/console-handler=CONSOLE:read-resource
> {
> "outcome" => "success",
> "result" => {
> "autoflush" => true,
> "enabled" => true,
> "encoding" => undefined,
> "filter" => undefined,
> "filter-spec" => undefined,
> "formatter" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n",
> "level" => "INFO",
> "name" => "CONSOLE",
> "named-formatter" => "COLOR-PATTERN",
> "target" => "System.out"
> }
> }
> {code}
> It should be fixed like below:
> {code:title=Expected result}
> [standalone@localhost:9990 /] /subsystem=logging/console-handler=CONSOLE:read-resource
> {
> "outcome" => "success",
> "result" => {
> "autoflush" => true,
> "enabled" => true,
> "encoding" => undefined,
> "filter" => undefined,
> "filter-spec" => undefined,
> "formatter" => undefined,
> "level" => "INFO",
> "name" => "CONSOLE",
> "named-formatter" => "COLOR-PATTERN",
> "target" => "System.out"
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2011) Inconsistency of formatter and named-formatter in console logging handler
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2011?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2011:
------------------------------------------
I've thought about this some more and I think we can do something about this, at least in a majority of cases, perhaps the vast majority.
It's reasonable that even if include-defaults=true, which is the default, that the read-resource and read-attribute handlers return 'undefined' when the attribute has declared alternatives and one of those alternatives is defined. The purpose of include-defaults=true is to show the "effective configuration" and in this kind of case the effective configuration is that the attribute is undefined. (The purpose of the "include-defaults=false" view is to see what the user specifically configured.)
I don't think this can be handled in all cases because in some the kernel delegates to custom read-attribute handlers implemented by subsystems, and we don't have control over what they do and thus can't trigger this kind of more sophisticated behavior. But I expect that this kind of "attribute has a default and has alternatives" configuration is very rarely used in cases where custom read-attribute handlers are used.
Thanks for the report!
I'm going to change the component for this (as it's a kernel problem, not specific to logging) and reassign it.
> Inconsistency of formatter and named-formatter in console logging handler
> -------------------------------------------------------------------------
>
> Key: WFCORE-2011
> URL: https://issues.jboss.org/browse/WFCORE-2011
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Affects Versions: 3.0.0.Alpha13
> Environment: It is possible to reproduce with all profiles and all modes.
> All WildFly profiles
> All WildFly clustering mode
> * standalone mode
> * domain mode
> Reporter: ted won
> Assignee: ted won
> Priority: Minor
> Labels: logging
> Attachments: COLOR-PATTERN.png, CONSOLE-console-handler.png
>
>
> In logging subsystem the default CONSOLE console-handler is defined with COLOR-PATTERN named-formatter.
> And the COLOR-PATTERN named-formatter is defined with: {noformat}"%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"{noformat}
> It is working as it is defined with colors in a console.
> {code:title=standalone.xml}
> ...
> <subsystem xmlns="urn:jboss:domain:logging:3.0">
> <console-handler name="CONSOLE">
> <level name="INFO"/>
> <formatter>
> <named-formatter name="COLOR-PATTERN"/>
> </formatter>
> </console-handler>
> ...
> <formatter name="COLOR-PATTERN">
> <pattern-formatter pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"/>
> </formatter>
> </subsystem>
> ...
> {code}
> However there is a inconsistency in the CLI and WildFly admin console views.
> In the CLI, CONSOLE formatter is: {noformat}"%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"{noformat} It is wrong and different with the working logging format in a console.
> {code:title=JBoss CLI}
> [standalone@localhost:9990 /] /subsystem=logging/console-handler=CONSOLE:read-resource
> {
> "outcome" => "success",
> "result" => {
> "autoflush" => true,
> "enabled" => true,
> "encoding" => undefined,
> "filter" => undefined,
> "filter-spec" => undefined,
> "formatter" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n",
> "level" => "INFO",
> "name" => "CONSOLE",
> "named-formatter" => "COLOR-PATTERN",
> "target" => "System.out"
> }
> }
> {code}
> It should be fixed like below:
> {code:title=Expected result}
> [standalone@localhost:9990 /] /subsystem=logging/console-handler=CONSOLE:read-resource
> {
> "outcome" => "success",
> "result" => {
> "autoflush" => true,
> "enabled" => true,
> "encoding" => undefined,
> "filter" => undefined,
> "filter-spec" => undefined,
> "formatter" => undefined,
> "level" => "INFO",
> "name" => "CONSOLE",
> "named-formatter" => "COLOR-PATTERN",
> "target" => "System.out"
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (ELY-756) Elytron ldap-realm does not support recursive role search
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-756?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-756:
---------------------------
Issue Type: Feature Request (was: Bug)
> Elytron ldap-realm does not support recursive role search
> ---------------------------------------------------------
>
> Key: ELY-756
> URL: https://issues.jboss.org/browse/ELY-756
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: Realms
> Affects Versions: 1.1.0.Beta13
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
>
> Scenario:
> LDAP can include some roles which are members of other roles. I try to assigned also these "nested roles" to user during authentication/authorization process.
> In EAP 7.0 (with PicketBox) I am able to set configuration, which allows to assign these roles to user. LdapExtLoginModule with module option {{roleRecursion}} serves for this. It uses int value which determines how many levels should be searched and assigned to user. I am not able to achieve this scenario with Elytron and its ldap-realm.
> Missing this feature in Elytron can lead to situation when migration from PicketBox to Elytron will not be possible since LDAP structure for role assignment used by legacy solution will not be able to work correctly with Elytron.
> See example of LDIF for LDAP server:
> {code}
> dn: ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: People
> dn: uid=jduke,ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> uid: jduke
> cn: Java Duke
> sn: Duke
> userPassword: Password1
> dn: ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: Roles
> dn: cn=R1,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R1
> member: uid=jduke,ou=People,dc=jboss,dc=org
> description: the R1 group
> dn: cn=R2,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R2
> member: cn=R1,ou=Roles,dc=jboss,dc=org
> description: the R2 group
> dn: cn=R3,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R3
> member: cn=R2,ou=Roles,dc=jboss,dc=org
> description: the R3 group
> {code}
> In Elytron I am able to assigned only {{R1}} role to user jduke. Legacy solution is able to use for example {{roleRecursion=1}} which results to assign roles {{R1}} and {{R2}} to user jduke.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (ELY-772) asRdn meaning in LDAP realm
by Jan Kalina (JIRA)
Jan Kalina created ELY-772:
------------------------------
Summary: asRdn meaning in LDAP realm
Key: ELY-772
URL: https://issues.jboss.org/browse/ELY-772
Project: WildFly Elytron
Issue Type: Enhancement
Components: Realms
Reporter: Jan Kalina
Assignee: Jan Kalina
Meaning of asRdn in AttributeMaping of LdapSecurityRealm is illogicaly different for filtered and simple attributes:
Currently:
* meaning of asRdn is different for mappings without filter (obtaining attribute from identity entry) and with filter (different entry)
** simple: value of attribute (defined by ldapName) is parsed as DN
** filtered: DN of the filtered entry is parsed (and ldapName is ignored - even through it is defined)
I suggest:
* when asRdn is defined:
** if ldapName will be defined, LDAP attribute will be parsed (for filtered mappings too)
** if ldapName will not be defined, DN of entry will be parsed (DN of identity entry for simple mapping)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7632) asRdn meaning in LDAP realm
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7632?page=com.atlassian.jira.plugin.... ]
Jan Kalina moved ELY-772 to WFLY-7632:
--------------------------------------
Project: WildFly (was: WildFly Elytron)
Key: WFLY-7632 (was: ELY-772)
Component/s: Security
(was: Realms)
> asRdn meaning in LDAP realm
> ---------------------------
>
> Key: WFLY-7632
> URL: https://issues.jboss.org/browse/WFLY-7632
> Project: WildFly
> Issue Type: Enhancement
> Components: Security
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> Meaning of asRdn in AttributeMaping of LdapSecurityRealm is illogicaly different for filtered and simple attributes:
> Currently:
> * meaning of asRdn is different for mappings without filter (obtaining attribute from identity entry) and with filter (different entry)
> ** simple: value of attribute (defined by ldapName) is parsed as DN
> ** filtered: DN of the filtered entry is parsed (and ldapName is ignored - even through it is defined)
> I suggest:
> * when asRdn is defined:
> ** if ldapName will be defined, LDAP attribute will be parsed (for filtered mappings too)
> ** if ldapName will not be defined, DN of entry will be parsed (DN of identity entry for simple mapping)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7631) Elytron ldap-realm does not support recursive role search
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7631?page=com.atlassian.jira.plugin.... ]
Jan Kalina moved ELY-771 to WFLY-7631:
--------------------------------------
Project: WildFly (was: WildFly Elytron)
Key: WFLY-7631 (was: ELY-771)
Component/s: Security
(was: Realms)
Affects Version/s: (was: 1.1.0.Beta13)
> Elytron ldap-realm does not support recursive role search
> ---------------------------------------------------------
>
> Key: WFLY-7631
> URL: https://issues.jboss.org/browse/WFLY-7631
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
>
> Scenario:
> LDAP can include some roles which are members of other roles. I try to assigned also these "nested roles" to user during authentication/authorization process.
> In EAP 7.0 (with PicketBox) I am able to set configuration, which allows to assign these roles to user. LdapExtLoginModule with module option {{roleRecursion}} serves for this. It uses int value which determines how many levels should be searched and assigned to user. I am not able to achieve this scenario with Elytron and its ldap-realm.
> Missing this feature in Elytron can lead to situation when migration from PicketBox to Elytron will not be possible since LDAP structure for role assignment used by legacy solution will not be able to work correctly with Elytron.
> See example of LDIF for LDAP server:
> {code}
> dn: ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: People
> dn: uid=jduke,ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> uid: jduke
> cn: Java Duke
> sn: Duke
> userPassword: Password1
> dn: ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: Roles
> dn: cn=R1,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R1
> member: uid=jduke,ou=People,dc=jboss,dc=org
> description: the R1 group
> dn: cn=R2,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R2
> member: cn=R1,ou=Roles,dc=jboss,dc=org
> description: the R2 group
> dn: cn=R3,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R3
> member: cn=R2,ou=Roles,dc=jboss,dc=org
> description: the R3 group
> {code}
> In Elytron I am able to assigned only {{R1}} role to user jduke. Legacy solution is able to use for example {{roleRecursion=1}} which results to assign roles {{R1}} and {{R2}} to user jduke.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7631) Elytron ldap-realm does not support recursive role search
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7631?page=com.atlassian.jira.plugin.... ]
Jan Kalina updated WFLY-7631:
-----------------------------
Issue Type: Feature Request (was: Bug)
> Elytron ldap-realm does not support recursive role search
> ---------------------------------------------------------
>
> Key: WFLY-7631
> URL: https://issues.jboss.org/browse/WFLY-7631
> Project: WildFly
> Issue Type: Feature Request
> Components: Security
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
>
> Scenario:
> LDAP can include some roles which are members of other roles. I try to assigned also these "nested roles" to user during authentication/authorization process.
> In EAP 7.0 (with PicketBox) I am able to set configuration, which allows to assign these roles to user. LdapExtLoginModule with module option {{roleRecursion}} serves for this. It uses int value which determines how many levels should be searched and assigned to user. I am not able to achieve this scenario with Elytron and its ldap-realm.
> Missing this feature in Elytron can lead to situation when migration from PicketBox to Elytron will not be possible since LDAP structure for role assignment used by legacy solution will not be able to work correctly with Elytron.
> See example of LDIF for LDAP server:
> {code}
> dn: ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: People
> dn: uid=jduke,ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> uid: jduke
> cn: Java Duke
> sn: Duke
> userPassword: Password1
> dn: ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: Roles
> dn: cn=R1,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R1
> member: uid=jduke,ou=People,dc=jboss,dc=org
> description: the R1 group
> dn: cn=R2,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R2
> member: cn=R1,ou=Roles,dc=jboss,dc=org
> description: the R2 group
> dn: cn=R3,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R3
> member: cn=R2,ou=Roles,dc=jboss,dc=org
> description: the R3 group
> {code}
> In Elytron I am able to assigned only {{R1}} role to user jduke. Legacy solution is able to use for example {{roleRecursion=1}} which results to assign roles {{R1}} and {{R2}} to user jduke.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (ELY-771) Elytron ldap-realm does not support recursive role search
by Jan Kalina (JIRA)
Jan Kalina created ELY-771:
------------------------------
Summary: Elytron ldap-realm does not support recursive role search
Key: ELY-771
URL: https://issues.jboss.org/browse/ELY-771
Project: WildFly Elytron
Issue Type: Bug
Components: Realms
Affects Versions: 1.1.0.Beta13
Reporter: Jan Kalina
Assignee: Jan Kalina
Priority: Blocker
Scenario:
LDAP can include some roles which are members of other roles. I try to assigned also these "nested roles" to user during authentication/authorization process.
In EAP 7.0 (with PicketBox) I am able to set configuration, which allows to assign these roles to user. LdapExtLoginModule with module option {{roleRecursion}} serves for this. It uses int value which determines how many levels should be searched and assigned to user. I am not able to achieve this scenario with Elytron and its ldap-realm.
Missing this feature in Elytron can lead to situation when migration from PicketBox to Elytron will not be possible since LDAP structure for role assignment used by legacy solution will not be able to work correctly with Elytron.
See example of LDIF for LDAP server:
{code}
dn: ou=People,dc=jboss,dc=org
objectclass: top
objectclass: organizationalUnit
ou: People
dn: uid=jduke,ou=People,dc=jboss,dc=org
objectclass: top
objectclass: person
objectclass: inetOrgPerson
uid: jduke
cn: Java Duke
sn: Duke
userPassword: Password1
dn: ou=Roles,dc=jboss,dc=org
objectclass: top
objectclass: organizationalUnit
ou: Roles
dn: cn=R1,ou=Roles,dc=jboss,dc=org
objectclass: top
objectclass: groupOfNames
cn: R1
member: uid=jduke,ou=People,dc=jboss,dc=org
description: the R1 group
dn: cn=R2,ou=Roles,dc=jboss,dc=org
objectclass: top
objectclass: groupOfNames
cn: R2
member: cn=R1,ou=Roles,dc=jboss,dc=org
description: the R2 group
dn: cn=R3,ou=Roles,dc=jboss,dc=org
objectclass: top
objectclass: groupOfNames
cn: R3
member: cn=R2,ou=Roles,dc=jboss,dc=org
description: the R3 group
{code}
In Elytron I am able to assigned only {{R1}} role to user jduke. Legacy solution is able to use for example {{roleRecursion=1}} which results to assign roles {{R1}} and {{R2}} to user jduke.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-6561) EJB Timers Intermittently Execute Repeatedly on Server Restart with Error Code WFLYEJB0043
by Eder F. Freitas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6561?page=com.atlassian.jira.plugin.... ]
Eder F. Freitas commented on WFLY-6561:
---------------------------------------
In Wildfly 8 it works right? If the current one is not finished the next one is not canceled. There is a workaround?
> EJB Timers Intermittently Execute Repeatedly on Server Restart with Error Code WFLYEJB0043
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-6561
> URL: https://issues.jboss.org/browse/WFLY-6561
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final
> Reporter: Kevin Chen
> Assignee: Stuart Douglas
> Labels: downstream_dependency
> Fix For: 10.1.0.CR1, 10.1.0.Final
>
>
> On Wildfly10, we are experiencing intermittent problems where on server startup, an @Timeout annotated method can be executed hundreds of times in a second (log below). Going through the references to the @Timeout methods and the @Scheduled methods, all scheduled methods are set to be non-persistent (ex: timerConfig.setPersistent(false), persistent=false) so we don't know how this could occur. It is not consistent and our only solution has been to kill the Wildfly10 server process and restart.
> 13:47:27,824 WARN [org.jboss.as.ejb3] (EJB default - 6) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 96) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 97) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 37) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months