September 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-7091) Not able to configure list of key/trust managers on elytron ssl context.

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7091?page=com.atlassian.jira.plugin.... ] Martin Choma updated WFLY-7091: ------------------------------- Description: Base on xsd/model documentation key-managers and trust-managers attributes seems to be meant to hold list of managers. That also comply to SSLContext init() method [1]. Hovewer, in elytron subsystem, they are of type string and any my tries to set list (space/comma delimited list) failed. XSD documentation * key-managers - Reference to the KeyManagers to be used by this SSLContext. * trust-managers - Reference to the TrustManagers to be used by this SSLContext. Model description: {noformat} "key-managers" => { "type" => STRING, "description" => "Reference to the key managers to use within the SSLContext.", "expressions-allowed" => false, "nillable" => true, "capability-reference" => "org.wildfly.security.key-managers", "min-length" => 1L, "max-length" => 2147483647L, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "resource-services" }, "trust-managers" => { "type" => STRING, "description" => "Reference to the trust managers to use within the SSLContext.", "expressions-allowed" => false, "nillable" => true, "capability-reference" => "org.wildfly.security.trust-managers", "min-length" => 1L, "max-length" => 2147483647L, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "resource-services" }, {noformat} [1] https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLContext.html#i... was: key-managers and trust-managers attributes seems to be meant to hold list of managers. That also comply to SSLContext init() method [1]. Hovewer, in elytron subsystem, they are of type string and any my tries to set list (space/comma delimited list) failed. XSD documentation * key-managers - Reference to the KeyManagers to be used by this SSLContext. * trust-managers - Reference to the TrustManagers to be used by this SSLContext. Model description: {noformat} "key-managers" => { "type" => STRING, "description" => "Reference to the key managers to use within the SSLContext.", "expressions-allowed" => false, "nillable" => true, "capability-reference" => "org.wildfly.security.key-managers", "min-length" => 1L, "max-length" => 2147483647L, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "resource-services" }, "trust-managers" => { "type" => STRING, "description" => "Reference to the trust managers to use within the SSLContext.", "expressions-allowed" => false, "nillable" => true, "capability-reference" => "org.wildfly.security.trust-managers", "min-length" => 1L, "max-length" => 2147483647L, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "resource-services" }, {noformat} [1] https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLContext.html#i... > Not able to configure list of key/trust managers on elytron ssl context. > ------------------------------------------------------------------------ > > Key: WFLY-7091 > URL: https://issues.jboss.org/browse/WFLY-7091 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > > Base on xsd/model documentation key-managers and trust-managers attributes seems to be meant to hold list of managers. That also comply to SSLContext init() method [1]. Hovewer, in elytron subsystem, they are of type string and any my tries to set list (space/comma delimited list) failed. > XSD documentation > * key-managers - Reference to the KeyManagers to be used by this SSLContext. > * trust-managers - Reference to the TrustManagers to be used by this SSLContext. > Model description: > {noformat} > "key-managers" => { > "type" => STRING, > "description" => "Reference to the key managers to use within the SSLContext.", > "expressions-allowed" => false, > "nillable" => true, > "capability-reference" => "org.wildfly.security.key-managers", > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > "trust-managers" => { > "type" => STRING, > "description" => "Reference to the trust managers to use within the SSLContext.", > "expressions-allowed" => false, > "nillable" => true, > "capability-reference" => "org.wildfly.security.trust-managers", > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {noformat} > [1] https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLContext.html#i... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7091) Not able to configure list of key/trust managers on elytron ssl context.

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7091?page=com.atlassian.jira.plugin.... ] Martin Choma moved JBEAP-5951 to WFLY-7091: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7091 (was: JBEAP-5951) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: 11.0.0.Alpha1 (was: 7.1.0.DR4) > Not able to configure list of key/trust managers on elytron ssl context. > ------------------------------------------------------------------------ > > Key: WFLY-7091 > URL: https://issues.jboss.org/browse/WFLY-7091 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > > key-managers and trust-managers attributes seems to be meant to hold list of managers. That also comply to SSLContext init() method [1]. Hovewer, in elytron subsystem, they are of type string and any my tries to set list (space/comma delimited list) failed. > XSD documentation > * key-managers - Reference to the KeyManagers to be used by this SSLContext. > * trust-managers - Reference to the TrustManagers to be used by this SSLContext. > Model description: > {noformat} > "key-managers" => { > "type" => STRING, > "description" => "Reference to the key managers to use within the SSLContext.", > "expressions-allowed" => false, > "nillable" => true, > "capability-reference" => "org.wildfly.security.key-managers", > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > "trust-managers" => { > "type" => STRING, > "description" => "Reference to the trust managers to use within the SSLContext.", > "expressions-allowed" => false, > "nillable" => true, > "capability-reference" => "org.wildfly.security.trust-managers", > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {noformat} > [1] https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLContext.html#i... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5550) Formalize web session clustering modules into a proper subsystem

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-5550?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-5550: ------------------------------- Description: Currently, the coupling between the undertow subsystem and the modules required for distributed web session manager and single sign-on manager support is very loose. Consequently, misconfiguration (e.g. a missing "web" cache-container) can prevent deployment from succeeding without an adequate explanation. The subsystem would define the requisite cache-container, exposed as a capability. This subsystem would exposes a number of profiles, containing the configuration traditionally specified in jboss-web.xml, as well as the cache configuration to use (specified by cache-container + cache name). jboss-web.xml would only need to reference a profile by name, or, if unspecified, use the default profile. was: Currently, the coupling between the undertow subsystem and the modules required for distributed web session manager and single sign-on manager support is very loose. Consequently, misconfiguration (e.g. a missing "web" cache-container) can prevent deployment from succeeding without an adequate explanation. The subsystem would define the requisite cache-container, exposed as a capability. > Formalize web session clustering modules into a proper subsystem > ---------------------------------------------------------------- > > Key: WFLY-5550 > URL: https://issues.jboss.org/browse/WFLY-5550 > Project: WildFly > Issue Type: Enhancement > Components: Clustering > Affects Versions: 10.0.0.CR3 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Alpha1 > > > Currently, the coupling between the undertow subsystem and the modules required for distributed web session manager and single sign-on manager support is very loose. > Consequently, misconfiguration (e.g. a missing "web" cache-container) can prevent deployment from succeeding without an adequate explanation. > The subsystem would define the requisite cache-container, exposed as a capability. > This subsystem would exposes a number of profiles, containing the configuration traditionally specified in jboss-web.xml, as well as the cache configuration to use (specified by cache-container + cache name). jboss-web.xml would only need to reference a profile by name, or, if unspecified, use the default profile. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1781) DomainModelControllerService is installing the management request handlers for DC-related requests for slaves using cached-dc

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1781?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1781: ------------------------------------- Description: The DomainModelControllerService code block that parses a local domain.xml is also installing the service the allows the management interface to accept requests that uses the request headers meant for the master side slave->master intra-domain communications. This service should not be added in the slave using cached-dc case, but it is now. It also shouldn't be added if the DC is running admin-only. OTOH in all cases where it is not added, a different service should be added that will reject any slave registration requests that come in with the correct error codes that the slave knows how to parse. Currently that rejection is only happening for admin-only masters or slaves that are using cached-dc, which is not correct. was:The DomainModelControllerService code block that parses a local domain.xml is also installing the service the allows the management interface to accept requests that uses the request headers meant for the master side slave->master intra-domain communications. This service should not be added in the slave using cached-dc case, but it is now. > DomainModelControllerService is installing the management request handlers for DC-related requests for slaves using cached-dc > ----------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1781 > URL: https://issues.jboss.org/browse/WFCORE-1781 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > The DomainModelControllerService code block that parses a local domain.xml is also installing the service the allows the management interface to accept requests that uses the request headers meant for the master side slave->master intra-domain communications. This service should not be added in the slave using cached-dc case, but it is now. > It also shouldn't be added if the DC is running admin-only. > OTOH in all cases where it is not added, a different service should be added that will reject any slave registration requests that come in with the correct error codes that the slave knows how to parse. Currently that rejection is only happening for admin-only masters or slaves that are using cached-dc, which is not correct. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1781) DomainModelControllerService is installing the management request handlers for DC-related requests for slaves using cached-dc

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-1781: ---------------------------------------- Summary: DomainModelControllerService is installing the management request handlers for DC-related requests for slaves using cached-dc Key: WFCORE-1781 URL: https://issues.jboss.org/browse/WFCORE-1781 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry The DomainModelControllerService code block that parses a local domain.xml is also installing the service the allows the management interface to accept requests that uses the request headers meant for the master side slave->master intra-domain communications. This service should not be added in the slave using cached-dc case, but it is now. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7073) elytron key/trust-managers incosistency between dmr and xsd

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7073?page=com.atlassian.jira.plugin.... ] Jan Kalina edited comment on WFLY-7073 at 9/10/16 1:29 PM: ----------------------------------------------------------- Summary: add PROVIDER attribute into managers (like in key-stores already is) * mangers XML attribute "provider" will have to be renamed to "provider-loader" was (Author: honza889): Summary: add PROVIDER attribute into managers (like in key-stores already is) * mangers XML attribute PROVIDER will have to be renamed to PROVIDER_LOADER > elytron key/trust-managers incosistency between dmr and xsd > ----------------------------------------------------------- > > Key: WFLY-7073 > URL: https://issues.jboss.org/browse/WFLY-7073 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Jan Kalina > > For key/trust-managers in dmr model, there is "provider-loader" attribute [1], however xsd defines provider attribute [2] for key/trust-managers. > Probably if user could define both provider and provider-loader, that would be the best. > [1] > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/key-managers=server2:add( > algorithm key-store password provider-loader > {noformat} > [2] > https://github.com/wildfly-security/elytron-subsystem/blob/master/src/mai... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7073) elytron key/trust-managers incosistency between dmr and xsd

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7073?page=com.atlassian.jira.plugin.... ] Jan Kalina edited comment on WFLY-7073 at 9/10/16 1:28 PM: ----------------------------------------------------------- Summary: add PROVIDER attribute into managers (like in key-stores already is) * mangers XML attribute PROVIDER will have to be renamed to PROVIDER_LOADER was (Author: honza889): Summary: add PROVIDER attribute into managers (like in key-stores already is) > elytron key/trust-managers incosistency between dmr and xsd > ----------------------------------------------------------- > > Key: WFLY-7073 > URL: https://issues.jboss.org/browse/WFLY-7073 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Jan Kalina > > For key/trust-managers in dmr model, there is "provider-loader" attribute [1], however xsd defines provider attribute [2] for key/trust-managers. > Probably if user could define both provider and provider-loader, that would be the best. > [1] > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/key-managers=server2:add( > algorithm key-store password provider-loader > {noformat} > [2] > https://github.com/wildfly-security/elytron-subsystem/blob/master/src/mai... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7073) elytron key/trust-managers incosistency between dmr and xsd

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7073?page=com.atlassian.jira.plugin.... ] Jan Kalina edited comment on WFLY-7073 at 9/10/16 1:14 PM: ----------------------------------------------------------- Summary: add PROVIDER attribute into managers (like in key-stores already is) was (Author: honza889): Summary: add PROVIDER into managers (like in key-stores already is) > elytron key/trust-managers incosistency between dmr and xsd > ----------------------------------------------------------- > > Key: WFLY-7073 > URL: https://issues.jboss.org/browse/WFLY-7073 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Jan Kalina > > For key/trust-managers in dmr model, there is "provider-loader" attribute [1], however xsd defines provider attribute [2] for key/trust-managers. > Probably if user could define both provider and provider-loader, that would be the best. > [1] > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/key-managers=server2:add( > algorithm key-store password provider-loader > {noformat} > [2] > https://github.com/wildfly-security/elytron-subsystem/blob/master/src/mai... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7073) elytron key/trust-managers incosistency between dmr and xsd

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7073?page=com.atlassian.jira.plugin.... ] Jan Kalina commented on WFLY-7073: ---------------------------------- To add: PROVIDER into managers (like in key-stores already is) > elytron key/trust-managers incosistency between dmr and xsd > ----------------------------------------------------------- > > Key: WFLY-7073 > URL: https://issues.jboss.org/browse/WFLY-7073 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Jan Kalina > > For key/trust-managers in dmr model, there is "provider-loader" attribute [1], however xsd defines provider attribute [2] for key/trust-managers. > Probably if user could define both provider and provider-loader, that would be the best. > [1] > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/key-managers=server2:add( > algorithm key-store password provider-loader > {noformat} > [2] > https://github.com/wildfly-security/elytron-subsystem/blob/master/src/mai... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7073) elytron key/trust-managers incosistency between dmr and xsd

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7073?page=com.atlassian.jira.plugin.... ] Jan Kalina edited comment on WFLY-7073 at 9/10/16 1:13 PM: ----------------------------------------------------------- Summary: add PROVIDER into managers (like in key-stores already is) was (Author: honza889): To add: PROVIDER into managers (like in key-stores already is) > elytron key/trust-managers incosistency between dmr and xsd > ----------------------------------------------------------- > > Key: WFLY-7073 > URL: https://issues.jboss.org/browse/WFLY-7073 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Jan Kalina > > For key/trust-managers in dmr model, there is "provider-loader" attribute [1], however xsd defines provider attribute [2] for key/trust-managers. > Probably if user could define both provider and provider-loader, that would be the best. > [1] > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/key-managers=server2:add( > algorithm key-store password provider-loader > {noformat} > [2] > https://github.com/wildfly-security/elytron-subsystem/blob/master/src/mai... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7076) Elytron introduces SSL/TLS protocol constraints

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7076?page=com.atlassian.jira.plugin.... ] Jan Kalina edited comment on WFLY-7076 at 9/10/16 11:19 AM: ------------------------------------------------------------ bq. I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place. This is defined in *org.wildfly.security.ssl.Protocol* enum (wildfly-elytron) Reason for restriction is using this enum in our *ProtocolSelector*. To remove this restriction should be sufficient replace all Protocol occurences by String. Is it what we want, [~dlofthouse]? was (Author: honza889): bq. I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place. This is defined in *org.wildfly.security.ssl.Protocol* enum (wildfly-elytron) Reason for restriction is using this enum in our *ProtocolSelector*. To remove this restriction should be sufficient replace all Protocol occurences by String. Is it what we want? > Elytron introduces SSL/TLS protocol constraints > ----------------------------------------------- > > Key: WFLY-7076 > URL: https://issues.jboss.org/browse/WFLY-7076 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > > {noformat} > "protocols" => { > "type" => LIST, > "description" => "The enabled protocols.", > "expressions-allowed" => true, > "nillable" => false, > "allowed" => [ > "SSLv2", > "SSLv3", > "TLSv1", > "TLSv1_1", > "TLSv1_2", > "TLSv1_3" > ], > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {noformat} > Why elytron on this place is going to validate user input and map standard java values [1] into proprietary values? > Whereas on other similar places (KeyManager algorithm, TrustManager algorithm, Keystore types) it leaves up to user to set proper value. > IMO, with such mapping another place, where bugs can raise was introduced. EAP will be here always one step back compared to java. > Note, IBM java already today defines little bit different protocols set [2] > I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place. > [1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardN... > [2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7076) Elytron introduces SSL/TLS protocol constraints

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7076?page=com.atlassian.jira.plugin.... ] Jan Kalina edited comment on WFLY-7076 at 9/10/16 10:22 AM: ------------------------------------------------------------ bq. I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place. This is defined in *org.wildfly.security.ssl.Protocol* enum (wildfly-elytron) Reason for restriction is using this enum in our *ProtocolSelector*. To remove this restriction should be sufficient replace all Protocol occurences by String. Is it what we want? was (Author: honza889): bq. I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place. This is defined in *org.wildfly.security.ssl.Protocol* enum (wildfly-elytron) Reason for restriction is using this enum in our *ProtocolSelector*. To remove this restriction, I can replace all Protocol occurences by String. > Elytron introduces SSL/TLS protocol constraints > ----------------------------------------------- > > Key: WFLY-7076 > URL: https://issues.jboss.org/browse/WFLY-7076 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > > {noformat} > "protocols" => { > "type" => LIST, > "description" => "The enabled protocols.", > "expressions-allowed" => true, > "nillable" => false, > "allowed" => [ > "SSLv2", > "SSLv3", > "TLSv1", > "TLSv1_1", > "TLSv1_2", > "TLSv1_3" > ], > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {noformat} > Why elytron on this place is going to validate user input and map standard java values [1] into proprietary values? > Whereas on other similar places (KeyManager algorithm, TrustManager algorithm, Keystore types) it leaves up to user to set proper value. > IMO, with such mapping another place, where bugs can raise was introduced. EAP will be here always one step back compared to java. > Note, IBM java already today defines little bit different protocols set [2] > I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place. > [1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardN... > [2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7076) Elytron introduces SSL/TLS protocol constraints

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7076?page=com.atlassian.jira.plugin.... ] Jan Kalina edited comment on WFLY-7076 at 9/10/16 10:20 AM: ------------------------------------------------------------ bq. I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place. This is defined in *org.wildfly.security.ssl.Protocol* enum (wildfly-elytron) Reason for restriction is using this enum in our *ProtocolSelector*. To remove this restriction, I can replace all Protocol occurences by String. was (Author: honza889): bq. I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place. This is defined in *org.wildfly.security.ssl.Protocol* enum (wildfly-elytron) Reason for restriction is using this enum in our *ProtocolSelector*. > Elytron introduces SSL/TLS protocol constraints > ----------------------------------------------- > > Key: WFLY-7076 > URL: https://issues.jboss.org/browse/WFLY-7076 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > > {noformat} > "protocols" => { > "type" => LIST, > "description" => "The enabled protocols.", > "expressions-allowed" => true, > "nillable" => false, > "allowed" => [ > "SSLv2", > "SSLv3", > "TLSv1", > "TLSv1_1", > "TLSv1_2", > "TLSv1_3" > ], > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {noformat} > Why elytron on this place is going to validate user input and map standard java values [1] into proprietary values? > Whereas on other similar places (KeyManager algorithm, TrustManager algorithm, Keystore types) it leaves up to user to set proper value. > IMO, with such mapping another place, where bugs can raise was introduced. EAP will be here always one step back compared to java. > Note, IBM java already today defines little bit different protocols set [2] > I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place. > [1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardN... > [2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-254) logging-profiles doesn't work with Apache Common Logging

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-254?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated WFCORE-254: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1164063, https://bugzilla.redhat.com/show_bug.cgi?id=1374457 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1164063) > logging-profiles doesn't work with Apache Common Logging > -------------------------------------------------------- > > Key: WFCORE-254 > URL: https://issues.jboss.org/browse/WFCORE-254 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: Anders Welen > Assignee: James Perkins > Priority: Minor > Attachments: 87905.tar > > > The logging for one logging-profile ends up in another logging-profile from time to time. It's not sporadic as all logging will end up in the wrong place when things go wrong. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7076) Elytron introduces SSL/TLS protocol constraints

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7076?page=com.atlassian.jira.plugin.... ] Jan Kalina edited comment on WFLY-7076 at 9/10/16 10:09 AM: ------------------------------------------------------------ bq. I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place. This is defined in *org.wildfly.security.ssl.Protocol* enum (wildfly-elytron) Reason for restriction is using this enum in our *ProtocolSelector*. was (Author: honza889): bq. I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place. This is defined in *org.wildfly.security.ssl.Protocol* enum (wildfly-elytron) > Elytron introduces SSL/TLS protocol constraints > ----------------------------------------------- > > Key: WFLY-7076 > URL: https://issues.jboss.org/browse/WFLY-7076 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > > {noformat} > "protocols" => { > "type" => LIST, > "description" => "The enabled protocols.", > "expressions-allowed" => true, > "nillable" => false, > "allowed" => [ > "SSLv2", > "SSLv3", > "TLSv1", > "TLSv1_1", > "TLSv1_2", > "TLSv1_3" > ], > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {noformat} > Why elytron on this place is going to validate user input and map standard java values [1] into proprietary values? > Whereas on other similar places (KeyManager algorithm, TrustManager algorithm, Keystore types) it leaves up to user to set proper value. > IMO, with such mapping another place, where bugs can raise was introduced. EAP will be here always one step back compared to java. > Note, IBM java already today defines little bit different protocols set [2] > I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place. > [1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardN... > [2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7076) Elytron introduces SSL/TLS protocol constraints

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7076?page=com.atlassian.jira.plugin.... ] Jan Kalina commented on WFLY-7076: ---------------------------------- bq. I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place. This is defined in *org.wildfly.security.ssl.Protocol* enum (wildfly-elytron) > Elytron introduces SSL/TLS protocol constraints > ----------------------------------------------- > > Key: WFLY-7076 > URL: https://issues.jboss.org/browse/WFLY-7076 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > > {noformat} > "protocols" => { > "type" => LIST, > "description" => "The enabled protocols.", > "expressions-allowed" => true, > "nillable" => false, > "allowed" => [ > "SSLv2", > "SSLv3", > "TLSv1", > "TLSv1_1", > "TLSv1_2", > "TLSv1_3" > ], > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {noformat} > Why elytron on this place is going to validate user input and map standard java values [1] into proprietary values? > Whereas on other similar places (KeyManager algorithm, TrustManager algorithm, Keystore types) it leaves up to user to set proper value. > IMO, with such mapping another place, where bugs can raise was introduced. EAP will be here always one step back compared to java. > Note, IBM java already today defines little bit different protocols set [2] > I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place. > [1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardN... > [2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7080) Creating ssl context with only required attribute cause NPE

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7080?page=com.atlassian.jira.plugin.... ] Jan Kalina edited comment on WFLY-7080 at 9/10/16 7:40 AM: ----------------------------------------------------------- Sent pull request to wildfly master. (added to pull request with "SSLContext - client side", which is strongly related and may be required too) was (Author: honza889): Sent pull request to wildfly master. > Creating ssl context with only required attribute cause NPE > ----------------------------------------------------------- > > Key: WFLY-7080 > URL: https://issues.jboss.org/browse/WFLY-7080 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Critical > Fix For: 11.0.0.Alpha1 > > > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=server2:add(protocols=[TLSv1_2]) > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {noformat} > In log of server there is exception: > {noformat} > 07:12:21,014 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.security.ssl-context.server2: org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NullPointerException > at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:275) > at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:45) > at org.wildfly.extension.elytron.SSLDefinitions$3.lambda$getValueSupplier$1(SSLDefinitions.java:411) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > 07:12:21,016 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 6) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("server-ssl-context" => "server2") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7080) Creating ssl context with only required attribute cause NPE

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7080?page=com.atlassian.jira.plugin.... ] Jan Kalina edited comment on WFLY-7080 at 9/10/16 7:32 AM: ----------------------------------------------------------- * *SSLContextBuilder:* "key-managers" was made optional in SSLContextBuilder because client-ssl-context (client doesnt need keystore when client auth is not used, only truststore) * *model validation:* I will change "protocols" to optional in model. was (Author: honza889): * "key-managers" was made optional in SSLContextBuilder because client-ssl-context (client doesnt need keystore when client auth is not used, only truststore) * I will change "protocols" to optional in model. > Creating ssl context with only required attribute cause NPE > ----------------------------------------------------------- > > Key: WFLY-7080 > URL: https://issues.jboss.org/browse/WFLY-7080 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Critical > Fix For: 11.0.0.Alpha1 > > > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=server2:add(protocols=[TLSv1_2]) > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {noformat} > In log of server there is exception: > {noformat} > 07:12:21,014 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.security.ssl-context.server2: org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NullPointerException > at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:275) > at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:45) > at org.wildfly.extension.elytron.SSLDefinitions$3.lambda$getValueSupplier$1(SSLDefinitions.java:411) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > 07:12:21,016 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 6) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("server-ssl-context" => "server2") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7080) Creating ssl context with only required attribute cause NPE

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7080?page=com.atlassian.jira.plugin.... ] Jan Kalina commented on WFLY-7080: ---------------------------------- * "key-managers" was made optional in SSLContextBuilder because client-ssl-context (client doesnt need keystore when client auth is not used, only truststore) * I will change "protocols" to optional in model. > Creating ssl context with only required attribute cause NPE > ----------------------------------------------------------- > > Key: WFLY-7080 > URL: https://issues.jboss.org/browse/WFLY-7080 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Critical > Fix For: 11.0.0.Alpha1 > > > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=server2:add(protocols=[TLSv1_2]) > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {noformat} > In log of server there is exception: > {noformat} > 07:12:21,014 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.security.ssl-context.server2: org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NullPointerException > at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:275) > at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:45) > at org.wildfly.extension.elytron.SSLDefinitions$3.lambda$getValueSupplier$1(SSLDefinitions.java:411) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > 07:12:21,016 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 6) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("server-ssl-context" => "server2") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7089) Undertow appears to require explicit keywords implements WebApplicationInitializer

by Darryl Miles (JIRA)

Darryl Miles created WFLY-7089: ---------------------------------- Summary: Undertow appears to require explicit keywords implements WebApplicationInitializer Key: WFLY-7089 URL: https://issues.jboss.org/browse/WFLY-7089 Project: WildFly Issue Type: Feature Request Components: Web (Undertow) Affects Versions: 10.1.0.Final Reporter: Darryl Miles Assignee: Stuart Douglas Undertow appears to require explicit keywords implements WebApplicationInitializer set on WEB-INF/classes when the class is using an "extends AbstractBaseClassThatImplementWebApplicationInitializer". It does not appear to see the annotation set on the base class AbstractBaseClassThatImplementWebApplicationInitializer. More over in my particular scenario this base class is provided in a JAR that is inside the EAR (not the WAR). Maybe what Wildfly is doing is completely specification compliant and other Servlet implementations work differently. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-254) logging-profiles doesn't work with Apache Common Logging

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-254?page=com.atlassian.jira.plugin... ] James Perkins commented on WFCORE-254: -------------------------------------- I've got a local implementation of this with just implementing the {{org.apache.commons.logging.Log}} and {{org.apache.commons.logging.LogFactory}}. I need to test it with WildFly and decide the level the project should be compiled to. Currently WildFly uses jboss-logmanager 2.0.4.Final which targets Java 7. If this project will be required for JBoss EAP 6 then it will need to work with Java 6 as well. > logging-profiles doesn't work with Apache Common Logging > -------------------------------------------------------- > > Key: WFCORE-254 > URL: https://issues.jboss.org/browse/WFCORE-254 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: Anders Welen > Assignee: James Perkins > Priority: Minor > Attachments: 87905.tar > > > The logging for one logging-profile ends up in another logging-profile from time to time. It's not sporadic as all logging will end up in the wrong place when things go wrong. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7077) logging profile with apache commons does not work

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-7077?page=com.atlassian.jira.plugin.... ] James Perkins closed WFLY-7077. ------------------------------- Resolution: Duplicate Issue > logging profile with apache commons does not work > -------------------------------------------------- > > Key: WFLY-7077 > URL: https://issues.jboss.org/browse/WFLY-7077 > Project: WildFly > Issue Type: Bug > Components: Logging > Reporter: Brad Maxwell > Assignee: James Perkins > > All entry logs go to the log file of the first accessed application logging profile. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7077) logging profile with apache commons does not work

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-7077?page=com.atlassian.jira.plugin.... ] James Perkins commented on WFLY-7077: ------------------------------------- I've been a bit hesitant to add yet another logging project, but now that this issue is coming up again I think it might be time. See the details on WFCORE-254 for more information. > logging profile with apache commons does not work > -------------------------------------------------- > > Key: WFLY-7077 > URL: https://issues.jboss.org/browse/WFLY-7077 > Project: WildFly > Issue Type: Bug > Components: Logging > Reporter: Brad Maxwell > Assignee: James Perkins > > All entry logs go to the log file of the first accessed application logging profile. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1780) Imprecise messages related to slave HC being unable to connect to master

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1780?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1780: ------------------------------------- Description: If a slave fails to connect to the master it logs "Could not connect to master. Aborting. Error was: %s" but since WFCORE-316 it no longer always aborts. Plus when it does abort it uses the deprecated SystemExiter.exit method. So we should change the first message to drop the bit about aborting and then if we do really abort pass an abort message to SystemExiter. was: If a slave fails to connect to the master it logs "Could not connect to master. Aborting. Error was: %s" but since WFCORE-316 it no longer always aborts. Plus when it does abort it uses the deprecated SystemExiter.exit method. So we should change the first message to drop the bit abort aborting and then if we do really abort pass an abort message to SystemExiter. > Imprecise messages related to slave HC being unable to connect to master > ------------------------------------------------------------------------ > > Key: WFCORE-1780 > URL: https://issues.jboss.org/browse/WFCORE-1780 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > > If a slave fails to connect to the master it logs "Could not connect to master. Aborting. Error was: %s" but since WFCORE-316 it no longer always aborts. > Plus when it does abort it uses the deprecated SystemExiter.exit method. > So we should change the first message to drop the bit about aborting and then if we do really abort pass an abort message to SystemExiter. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1780) Imprecise messages related to slave HC being unable to connect to master

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-1780: ---------------------------------------- Summary: Imprecise messages related to slave HC being unable to connect to master Key: WFCORE-1780 URL: https://issues.jboss.org/browse/WFCORE-1780 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor If a slave fails to connect to the master it logs "Could not connect to master. Aborting. Error was: %s" but since WFCORE-316 it no longer always aborts. Plus when it does abort it uses the deprecated SystemExiter.exit method. So we should change the first message to drop the bit abort aborting and then if we do really abort pass an abort message to SystemExiter. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7088) Resource adapter subsystem configuration descriptions: connection-definitions

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/WFLY-7088?page=com.atlassian.jira.plugin.... ] Ilia Vassilev updated WFLY-7088: -------------------------------- Affects Version/s: 10.1.0.Final > Resource adapter subsystem configuration descriptions: connection-definitions > ----------------------------------------------------------------------------- > > Key: WFLY-7088 > URL: https://issues.jboss.org/browse/WFLY-7088 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 10.1.0.Final > Reporter: Ilia Vassilev > Assignee: Ilia Vassilev > Priority: Trivial > > Multiple typos and grammar issues with the descriptions. > I will create a diff with the issues, and suggested fixes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7083) Resource adapter subsystem configuration descriptions: wm-security

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/WFLY-7083?page=com.atlassian.jira.plugin.... ] Ilia Vassilev updated WFLY-7083: -------------------------------- Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/9182) > Resource adapter subsystem configuration descriptions: wm-security > ------------------------------------------------------------------ > > Key: WFLY-7083 > URL: https://issues.jboss.org/browse/WFLY-7083 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 10.1.0.Final > Reporter: Ilia Vassilev > Assignee: Ilia Vassilev > Priority: Trivial > > These descriptions of wm-security may want to be reviewed. > * There is a typo in the resource description of {{wm-security}}: > bq. Toggle on/off wm.security for this resource-adapter. In case of false all wm-security-* parameters are ignored, even thei defaults. > * For {{wm-security-mapping-required}}, the description seems to refer to documentation sections: > bq. Defines if a mapping is required for security credentials. A value of false means Case 1 as defined in section 16.4.3, and a value of true means Case 2 as defined in section 16.4.4. > However these sections can me moved or removed, and the numbers will often change. I'm not even sure what content this refers to. We shouldn't hard-code documentation references. > * Ending the description with a full stop is also missing on many descriptions. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7088) Resource adapter subsystem configuration descriptions: connection-definitions

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/WFLY-7088?page=com.atlassian.jira.plugin.... ] Ilia Vassilev moved JBEAP-5949 to WFLY-7088: -------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7088 (was: JBEAP-5949) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JCA (was: JCA) (was: User Experience) Affects Version/s: (was: 7.0.0.GA) > Resource adapter subsystem configuration descriptions: connection-definitions > ----------------------------------------------------------------------------- > > Key: WFLY-7088 > URL: https://issues.jboss.org/browse/WFLY-7088 > Project: WildFly > Issue Type: Bug > Components: JCA > Reporter: Ilia Vassilev > Assignee: Ilia Vassilev > Priority: Trivial > > Multiple typos and grammar issues with the descriptions. > I will create a diff with the issues, and suggested fixes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1250) Drools Sample.drl is broken

by Robert (Bob) Brodt (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1250?page=com.atlassian.jira.plugi... ] Robert (Bob) Brodt commented on DROOLS-1250: -------------------------------------------- See https://github.com/droolsjbpm/drools/pull/912 > Drools Sample.drl is broken > --------------------------- > > Key: DROOLS-1250 > URL: https://issues.jboss.org/browse/DROOLS-1250 > Project: Drools > Issue Type: Feature Request > Components: eclipse plugin > Affects Versions: 6.4.0.Final > Reporter: Tianwei Chen > Assignee: Robert (Bob) Brodt > > Hello, I use drools plugin (6.4.0.Final) in Eclipse Neon. I followed the wizard to create a drools project with some example files. After the step were done, Eclipse highlighted errors at the two rules in the Sample.drl file. Here is one of the errors: > Multiple markers at this line > - com.sample.DroolsTest.Message cannot be resolved to a type > - org.drools.core.util.bitmask.AllSetBitMask cannot be resolved to a type > - Only a type can be imported. com.sample.DroolsTest.Message resolves to a package > - org.kie.api.runtime.rule.FactHandle cannot be resolved to a type > - KnowledgeHelper cannot be resolved to a type > - Only a type can be imported. org.drools.core.spi.KnowledgeHelper resolves to a package > - Message.GOODBYE cannot be resolved to a type > - org.kie.api.runtime.rule.RuleContext cannot be resolved to a type > - java.lang.Exception cannot be resolved to a type > When I ran DroolsTest.java, I got the following error: > java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=Sample.drl, line=15, column=0 > text=Rule Compilation error Only a type can be imported. com.sample.DroolsTest.Message resolves to a package > Only a type can be imported. org.drools.core.spi.KnowledgeHelper resolves to a package > KnowledgeHelper cannot be resolved to a type > org.kie.api.runtime.rule.FactHandle cannot be resolved to a type > java.lang.Exception cannot be resolved to a type > org.kie.api.runtime.rule.RuleContext cannot be resolved to a type], Message [id=2, level=ERROR, path=Sample.drl, line=5, column=0 > text=Rule Compilation error Only a type can be imported. com.sample.DroolsTest.Message resolves to a package > Only a type can be imported. org.drools.core.spi.KnowledgeHelper resolves to a package > KnowledgeHelper cannot be resolved to a type > com.sample.DroolsTest.Message cannot be resolved to a type > org.kie.api.runtime.rule.FactHandle cannot be resolved to a type > org.kie.api.runtime.rule.FactHandle cannot be resolved to a type > java.lang.Exception cannot be resolved to a type > org.kie.api.runtime.rule.RuleContext cannot be resolved to a type > Message.GOODBYE cannot be resolved to a type > org.drools.core.util.bitmask.AllSetBitMask cannot be resolved to a type > com.sample.DroolsTest.Message cannot be resolved to a type]] > at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:450) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:604) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:575) > It seems like an library path issue. Please help! > Thank you very much! > Tianwei Chen -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6965) Audit @Ignore-d clustering integration tests

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6965?page=com.atlassian.jira.plugin.... ] Radoslav Husar edited comment on WFLY-6965 at 9/9/16 12:48 PM: --------------------------------------------------------------- Analyzed and enabled 4 cases in a PR https://github.com/wildfly/wildfly/pull/9131 -RemoteFailoverTestCase already has PR submitted since 2015.- Status: merged. Fine/CoarseSessionPassivationTestCase fail intermittently probably due to Infinispan issue, traced under WFLY-6624. -WFLY-835 is being fixed by Mike M.- Status: merged. was (Author: rhusar): Analyzed and enabled 4 cases in a PR https://github.com/wildfly/wildfly/pull/9131 RemoteFailoverTestCase already has PR submitted since 2015. Fine/CoarseSessionPassivationTestCase fail intermittently probably due to Infinispan issue. WFLY-835 is being fixed by Mike M. > Audit @Ignore-d clustering integration tests > -------------------------------------------- > > Key: WFLY-6965 > URL: https://issues.jboss.org/browse/WFLY-6965 > Project: WildFly > Issue Type: Task > Components: Clustering > Affects Versions: 10.1.0.CR1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 11.0.0.Alpha1 > > > Recently stumbling upon an @Ignore-d test which would have caught a regression, we need to audit ignored clustering tests, e.g. some are referencing already fixed issues. > {noformat} > [rhusar@syrah clustering]$ git grep @Ignore > src/test/java/org/jboss/as/test/clustering/cluster/ejb/remote/RemoteFailoverTestCase.java: @Ignore("WFLY-3532") > src/test/java/org/jboss/as/test/clustering/cluster/ejb/stateful/StatefulFailoverTestCase.java: @Ignore("WFLY-835 @Resource UserTransaction error when file passivation store is selected") > src/test/java/org/jboss/as/test/clustering/cluster/web/passivation/CoarseSessionPassivationTestCase.java:@Ignore("WFLY-6624") > src/test/java/org/jboss/as/test/clustering/cluster/web/passivation/FineSessionPassivationTestCase.java:@Ignore("WFLY-6624") > src/test/java/org/jboss/as/test/clustering/extended/ejb2/stateful/passivation/ClusterPassivationTestCase.java: @Ignore("JBPAPP-8774") > src/test/java/org/jboss/as/test/clustering/extended/ejb2/stateful/remote/failover/dd/RemoteEJB2ClientStatefulBeanFailoverDDTestCase.java: @Ignore("JBPAPP-8726") > src/test/java/org/jboss/as/test/clustering/extended/ejb2/stateful/remote/failover/dd/RemoteEJB2ClientStatefulBeanFailoverDDTestCase.java: @Ignore("JBPAPP-8726") > src/test/java/org/jboss/as/test/clustering/single/jdbcstore/TransactionalJdbcStoreTestCase.java:@Ignore("https://issues.jboss.org/browse/ISPN-604") > src/test/java/org/jboss/as/test/clustering/xsite/XSiteSimpleTestCase.java: @Ignore("https://issues.jboss.org/browse/WFLY-5239") > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1779) Remove /deployment-overlay=*/content=*:read-content

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-1779: ---------------------------------------- Summary: Remove /deployment-overlay=*/content=*:read-content Key: WFCORE-1779 URL: https://issues.jboss.org/browse/WFCORE-1779 Project: WildFly Core Issue Type: Task Components: Domain Management Reporter: Brian Stansberry Follow-on to WFCORE-1778. Not to be scheduled for a release prior to the release that will be used in EAP 8. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1778) Deprecate /deployment-overlay=*/content=*:read-content, replace with a response stream variant

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1778?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1778: ------------------------------------- Description: The /deployment-overlay=*/content=*:read-content op is returning file content as a DMR ModelNode of type STRING. We need to deprecate and eventually drop this operation. Reading these files should use the response attachment mechanism. Probably we should add a 'stream' attribute to the resource as the replacement. Perhaps other attributes to mirror /subsystem=logging/log-file=*. was: The /deployment-overlay=*/content=*:read-content op is returning file content as a DMR ModelNode of type STRING. We need to deprecate and eventually drop this operation. Reading these files should use the response attachment mechanism. Probably we should add a 'stream' attribute to the resource as the replacement. > Deprecate /deployment-overlay=*/content=*:read-content, replace with a response stream variant > ---------------------------------------------------------------------------------------------- > > Key: WFCORE-1778 > URL: https://issues.jboss.org/browse/WFCORE-1778 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 3.0.0.Beta1 > > > The /deployment-overlay=*/content=*:read-content op is returning file content as a DMR ModelNode of type STRING. We need to deprecate and eventually drop this operation. Reading these files should use the response attachment mechanism. > Probably we should add a 'stream' attribute to the resource as the replacement. Perhaps other attributes to mirror /subsystem=logging/log-file=*. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1778) Deprecate /deployment-overlay=*/content=*:read-content, replace with a response stream variant

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1778?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-1778: ---------------------------------------- Assignee: ehsavoie Hugonnet > Deprecate /deployment-overlay=*/content=*:read-content, replace with a response stream variant > ---------------------------------------------------------------------------------------------- > > Key: WFCORE-1778 > URL: https://issues.jboss.org/browse/WFCORE-1778 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: ehsavoie Hugonnet > Fix For: 3.0.0.Beta1 > > > The /deployment-overlay=*/content=*:read-content op is returning file content as a DMR ModelNode of type STRING. We need to deprecate and eventually drop this operation. Reading these files should use the response attachment mechanism. > Probably we should add a 'stream' attribute to the resource as the replacement. Perhaps other attributes to mirror /subsystem=logging/log-file=*. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1778) Deprecate /deployment-overlay=*/content=*:read-content, replace with a response stream variant

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-1778: ---------------------------------------- Summary: Deprecate /deployment-overlay=*/content=*:read-content, replace with a response stream variant Key: WFCORE-1778 URL: https://issues.jboss.org/browse/WFCORE-1778 Project: WildFly Core Issue Type: Task Components: Domain Management Reporter: Brian Stansberry Fix For: 3.0.0.Beta1 The /deployment-overlay=*/content=*:read-content op is returning file content as a DMR ModelNode of type STRING. We need to deprecate and eventually drop this operation. Reading these files should use the response attachment mechanism. Probably we should add a 'stream' attribute to the resource as the replacement. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1777) Use separate resources for GET requests involving useStreamAsResponse

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-1777: ---------------------------------------- Summary: Use separate resources for GET requests involving useStreamAsResponse Key: WFCORE-1777 URL: https://issues.jboss.org/browse/WFCORE-1777 Project: WildFly Core Issue Type: Enhancement Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 3.0.0.CR1 A request for streamed content can potentially involve a large amount of content, e.g. a very large log file. We should limit the amount of resources (e.g. threads) available for handling such HTTP requests over the /management context, particularly in the case of GET requests where we don't do the cross-origin checks that we do with POST. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7087) Deprecate internal, timer and oob thread pools with JGroups 4.x upgrade

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7087?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-7087: --------------------------------- Issue Type: Task (was: Feature Request) > Deprecate internal, timer and oob thread pools with JGroups 4.x upgrade > ----------------------------------------------------------------------- > > Key: WFLY-7087 > URL: https://issues.jboss.org/browse/WFLY-7087 > Project: WildFly > Issue Type: Task > Components: Clustering > Reporter: Radoslav Husar > Assignee: Paul Ferraro > > http://belaban.blogspot.cz/2016/09/removing-thread-pools-in-jgroups-40.html -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1775) CLI command for enabling tracking configuration changes act differently when host is specifiend and when it is not

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1775?page=com.atlassian.jira.plugi... ] Brian Stansberry resolved WFCORE-1775. -------------------------------------- Resolution: Rejected > CLI command for enabling tracking configuration changes act differently when host is specifiend and when it is not > ------------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1775 > URL: https://issues.jboss.org/browse/WFCORE-1775 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Ivan Straka > Assignee: Brian Stansberry > > If I execute > {code} > /host=slave/core-service=management/service=configuration-changes:add(history-size=10) > {code} > on host controller, everything is fine. > But, if > {code} > /core-service=management/service=configuration-changes:add(history-size=10) > {code} > is executed, > {code:json} > { > "outcome" => "failed", > "failure-description" => "WFLYDC0032: Operation add for address [ > (\"core-service\" => \"management\"), > (\"service\" => \"configuration-changes\") > ] can only be handled by the master Domain Controller; this host is not the master Domain Controller", > "rolled-back" => true > } > {code} > is returned. > I have discussed this with [~ehugonnet], and it has not been decided whether this is correct behavior. For some reason it is trying to route the request to the DC. > This jira is supposed to start a discussion about this - is it a bug, or correct behavior? > IMHO results of these two commands should should be the same. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1775) CLI command for enabling tracking configuration changes act differently when host is specifiend and when it is not

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1775?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1775: ------------------------------------------ This is correct behavior. Connecting to a non-master HC and trying to invoke any write operation for a resource not in the /host=* tree should produce that error. Not producing that error is a bug. > CLI command for enabling tracking configuration changes act differently when host is specifiend and when it is not > ------------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1775 > URL: https://issues.jboss.org/browse/WFCORE-1775 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Ivan Straka > Assignee: Brian Stansberry > > If I execute > {code} > /host=slave/core-service=management/service=configuration-changes:add(history-size=10) > {code} > on host controller, everything is fine. > But, if > {code} > /core-service=management/service=configuration-changes:add(history-size=10) > {code} > is executed, > {code:json} > { > "outcome" => "failed", > "failure-description" => "WFLYDC0032: Operation add for address [ > (\"core-service\" => \"management\"), > (\"service\" => \"configuration-changes\") > ] can only be handled by the master Domain Controller; this host is not the master Domain Controller", > "rolled-back" => true > } > {code} > is returned. > I have discussed this with [~ehugonnet], and it has not been decided whether this is correct behavior. For some reason it is trying to route the request to the DC. > This jira is supposed to start a discussion about this - is it a bug, or correct behavior? > IMHO results of these two commands should should be the same. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7087) Deprecate internal, timer and oob thread pools with JGroups 4.x upgrade

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-7087: ------------------------------------ Summary: Deprecate internal, timer and oob thread pools with JGroups 4.x upgrade Key: WFLY-7087 URL: https://issues.jboss.org/browse/WFLY-7087 Project: WildFly Issue Type: Feature Request Components: Clustering Reporter: Radoslav Husar Assignee: Paul Ferraro http://belaban.blogspot.cz/2016/09/removing-thread-pools-in-jgroups-40.html -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7085) Server should verify EJB business methods during deployment and reject

by Wolf-Dieter Fink (JIRA)

[ https://issues.jboss.org/browse/WFLY-7085?page=com.atlassian.jira.plugin.... ] Wolf-Dieter Fink updated WFLY-7085: ----------------------------------- Summary: Server should verify EJB business methods during deployment and reject (was: By spec EJB business methods should not final but the deployment did not fail under any circumstances) > Server should verify EJB business methods during deployment and reject > ---------------------------------------------------------------------- > > Key: WFLY-7085 > URL: https://issues.jboss.org/browse/WFLY-7085 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 11.0.0.Alpha1 > Reporter: Wolf-Dieter Fink > > The ejb 3.2 core specification state in chapter 4.9.6 that business methods should not be declared as final or static. > But a Bean with a business method declared in the local or remote interface can be correct deployed and is accesible under some circumstances. > To ensure that the Bean is according to the spec and avoid runtime or injection issues the methods should be checked and a VerifyError should be thrown at deployment time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBNAME-63) Fix type check in Protocol#RENAME

by Philippe Marschall (JIRA)

[ https://issues.jboss.org/browse/JBNAME-63?page=com.atlassian.jira.plugin.... ] Philippe Marschall updated JBNAME-63: ------------------------------------- Git Pull Request: https://github.com/jbossas/jboss-remote-naming/pull/30 > Fix type check in Protocol#RENAME > --------------------------------- > > Key: JBNAME-63 > URL: https://issues.jboss.org/browse/JBNAME-63 > Project: JBoss Naming > Issue Type: Bug > Components: naming > Reporter: Philippe Marschall > Assignee: Eduardo Martins > > {{Protocol#RENAME}} checks the type of the same array element twice before casting instead of checking the types of all array elements before casing. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBNAME-63) Fix type check in Protocol#RENAME

by Philippe Marschall (JIRA)

Philippe Marschall created JBNAME-63: ---------------------------------------- Summary: Fix type check in Protocol#RENAME Key: JBNAME-63 URL: https://issues.jboss.org/browse/JBNAME-63 Project: JBoss Naming Issue Type: Bug Components: naming Reporter: Philippe Marschall Assignee: Eduardo Martins {{Protocol#RENAME}} checks the type of the same array element twice before casting instead of checking the types of all array elements before casing. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7086) By spec EJB business methods should not final but the deployment did not fail under any circumstances

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created WFLY-7086: -------------------------------------- Summary: By spec EJB business methods should not final but the deployment did not fail under any circumstances Key: WFLY-7086 URL: https://issues.jboss.org/browse/WFLY-7086 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 11.0.0.Alpha1 Reporter: Wolf-Dieter Fink The ejb 3.2 core specification state in chapter 4.9.6 that business methods should not be declared as final or static. But a Bean with a business method declared in the local or remote interface can be correct deployed and is accesible under some circumstances. To ensure that the Bean is according to the spec and avoid runtime or injection issues the methods should be checked and a VerifyError should be thrown at deployment time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7084) Support Artemis JDBC store

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-7084?page=com.atlassian.jira.plugin.... ] Jeff Mesnil closed WFLY-7084. ----------------------------- Resolution: Duplicate Issue > Support Artemis JDBC store > -------------------------- > > Key: WFLY-7084 > URL: https://issues.jboss.org/browse/WFLY-7084 > Project: WildFly > Issue Type: Feature Request > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7085) By spec EJB business methods should not final but the deployment did not fail under any circumstances

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created WFLY-7085: -------------------------------------- Summary: By spec EJB business methods should not final but the deployment did not fail under any circumstances Key: WFLY-7085 URL: https://issues.jboss.org/browse/WFLY-7085 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 11.0.0.Alpha1 Reporter: Wolf-Dieter Fink The ejb 3.2 core specification state in chapter 4.9.6 that business methods should not be declared as final or static. But a Bean with a business method declared in the local or remote interface can be correct deployed and is accesible under some circumstances. To ensure that the Bean is according to the spec and avoid runtime or injection issues the methods should be checked and a VerifyError should be thrown at deployment time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7084) Support Artemis JDBC store

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFLY-7084: --------------------------------- Summary: Support Artemis JDBC store Key: WFLY-7084 URL: https://issues.jboss.org/browse/WFLY-7084 Project: WildFly Issue Type: Feature Request Components: JMS Reporter: Jeff Mesnil Assignee: Jeff Mesnil -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6899) Upgrade RESTEasy to 3.1.0.Beta2

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/WFLY-6899?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated WFLY-6899: ---------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/9181 (was: https://github.com/wildfly/wildfly/pull/9086) > Upgrade RESTEasy to 3.1.0.Beta2 > ------------------------------- > > Key: WFLY-6899 > URL: https://issues.jboss.org/browse/WFLY-6899 > Project: WildFly > Issue Type: Component Upgrade > Components: REST > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: 11.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6899) Upgrade RESTEasy to 3.1.0.Beta2

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/WFLY-6899?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated WFLY-6899: ---------------------------------- Summary: Upgrade RESTEasy to 3.1.0.Beta2 (was: Upgrade RESTEasy to 3.1.0.Beta1) > Upgrade RESTEasy to 3.1.0.Beta2 > ------------------------------- > > Key: WFLY-6899 > URL: https://issues.jboss.org/browse/WFLY-6899 > Project: WildFly > Issue Type: Component Upgrade > Components: REST > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: 11.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1127) SocketBindingManagerImpl$UnnamedRegistryImpl is overly picky about unbound sockets

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1127?page=com.atlassian.jira.plugi... ] Dan Berindei commented on WFCORE-1127: -------------------------------------- Thanks [~pferraro], I looked at {{UnnamedRegistryImpl.registerBinding()}} to check that it still throws the {{IllegalStateException}}, but I didn't realize {{ManagedSocketFactory}} and {{ManagedSocketFactoryTest}} had changed instead. I guess I have some rebasing to do :) > SocketBindingManagerImpl$UnnamedRegistryImpl is overly picky about unbound sockets > ---------------------------------------------------------------------------------- > > Key: WFCORE-1127 > URL: https://issues.jboss.org/browse/WFCORE-1127 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.1.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 2.0.2.Final > > > A failure like this isn't necessary: > {code} > 08:02:23,475 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.jgroups.channel.ee.connector: org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee.connector: java.lang.IllegalStateException > at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:96) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.IllegalStateException > at org.jboss.as.network.SocketBindingManagerImpl$UnnamedRegistryImpl.unregisterBinding(SocketBindingManagerImpl.java:501) > at org.jboss.as.network.ManagedDatagramSocketBinding.close(ManagedDatagramSocketBinding.java:73) > at org.jboss.as.clustering.jgroups.ManagedSocketFactory.close(ManagedSocketFactory.java:148) > at org.jgroups.protocols.UDP.closeUnicastSocket(UDP.java:577) > at org.jgroups.protocols.UDP.destroySockets(UDP.java:429) > at org.jgroups.protocols.UDP.start(UDP.java:274) > at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965) > at org.jgroups.JChannel.startStack(JChannel.java:890) > at org.jgroups.JChannel._preConnect(JChannel.java:553) > at org.jgroups.JChannel.connect(JChannel.java:288) > at org.jgroups.JChannel.connect(JChannel.java:279) > at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:94) > ... 5 more > {code} > If there's no socket address, it should just move on. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7075) proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization)

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-7075: ------------------------------------ The naughty/bad thing about fixing the mentioned bug (that we will track via a new WFLY jira soon), is that applications that associate an UNSYNCHRONIZED extended persistence context with the JTA transaction which could start seeing (IllegalStateException) failures after the fix is applied due to the testForMixedSynchronizationTypes. We might need a workaround for applications to get the current behaviour (property to treat extended persistence context as SYNCHRONIZED). > proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization) > ------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7075 > URL: https://issues.jboss.org/browse/WFLY-7075 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.1.0.Final > Environment: *AppServer:* WildFly 10.1.0.Final > *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar > Reporter: Viacheslav Astapkovich > Assignee: Scott Marlow > Attachments: kitchensink-ear.rar > > > As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. > > *The obtained defect:* > A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. > The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) > *FIX:* > We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 > Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... > _Changes_: The method getSynchronizationType returns declared synchronization type. > *Consequences:* > We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. > Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. > It requires a declaration of synchronize persistence context. > We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. > However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. > *Our actions:* > We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). > This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. > _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... > *Example for reproduction:* > I modified quickstart example: [^kitchensink-ear.rar] > MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. > MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. > MemberRepository also perform join Transaction. > Questions from [~smarlow]: > - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. > We decided to use Container-managed EntityManager, because > - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components > - The container makes our job > We want to use the existing mechanism > *In Addition:* > Formally, this is out of JPA SPEC, but we have the following reasons: > - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". > But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. > ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) > - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1776) CLI gui returns null for specific command with access-control parameter while console CLI returns valid result

by Alexey Loubyansky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1776?page=com.atlassian.jira.plugi... ] Alexey Loubyansky moved JBEAP-5946 to WFCORE-1776: -------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-1776 (was: JBEAP-5946) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: CLI (was: CLI) Affects Version/s: (was: 7.0.1.CR1) (was: 7.1.0.DR4) > CLI gui returns null for specific command with access-control parameter while console CLI returns valid result > -------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1776 > URL: https://issues.jboss.org/browse/WFCORE-1776 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > > I tried to click through CLI GUI, particullary interested in webservices subsystem. > I navigated through the tree into {{/subsystem=webservices/endpoint-config=*}}, right-click and chose {{ead-resource-description}}. > It generated this command, but after executing through GUI, it returns null: > {code} > /subsystem=webservices/endpoint-config=*/:read-resource-description(recursive=false,access-control=none) > null > {code} > The same command in console CLI return valid resut: > {code:java} > [standalone@localhost:9990 /] /subsystem=webservices/endpoint-config=*/:read-resource-description(recursive=false,access-control=none) > { > "outcome" => "success", > "result" => [{ > "address" => [ > ("subsystem" => "webservices"), > ("endpoint-config" => "*") > ], > "outcome" => "success", > "result" => { > "description" => "Webservice endpoint configuration", > "attributes" => {}, > "operations" => undefined, > "notifications" => undefined, > "children" => { > "pre-handler-chain" => { > "description" => "Pre handler chain", > "model-description" => undefined > }, > "post-handler-chain" => { > "description" => "Post handler chain", > "model-description" => undefined > }, > "property" => { > "description" => "Configuration property", > "model-description" => undefined > } > } > } > }] > } > {code} > The problem seems to be related to the {{access-control=none}} parameter, because without it both GUI and console return the same valid result > {code:java} > /subsystem=webservices/endpoint-config=*/:read-resource-description(recursive=false) > { > "outcome" => "success", > "result" => [{ > "address" => [ > ("subsystem" => "webservices"), > ("endpoint-config" => "*") > ], > "outcome" => "success", > "result" => { > "description" => "Webservice endpoint configuration", > "attributes" => {}, > "operations" => undefined, > "notifications" => undefined, > "children" => { > "pre-handler-chain" => { > "description" => "Pre handler chain", > "model-description" => undefined > }, > "post-handler-chain" => { > "description" => "Post handler chain", > "model-description" => undefined > }, > "property" => { > "description" => "Configuration property", > "model-description" => undefined > } > } > } > }] > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-263) ClassPool cannot read generated classes

by Shigeru Chiba (JIRA)

[ https://issues.jboss.org/browse/JASSIST-263?page=com.atlassian.jira.plugi... ] Shigeru Chiba commented on JASSIST-263: --------------------------------------- ClassPool needs bytecode since a loaded class does not expose its bytecode although Java 9 seems to include a method to obtain the bytecode. Here the bytecode means a class file (= generated byte[] array). > ClassPool cannot read generated classes > --------------------------------------- > > Key: JASSIST-263 > URL: https://issues.jboss.org/browse/JASSIST-263 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.20.0-GA > Reporter: Paul Pogonyshev > Assignee: Shigeru Chiba > Attachments: JavassistBug.java > > > ClassPool.get() cannot retrieve classes that are in turn generated at runtime. For example, if I try to define at runtime two classes, one of which extends another, the base will not be found, even though it can be retrieved just fine from my class loader. See the attached example. > As far as I could trace it, the issue comes from ClassPoolTail.find() returning a null URL for the class. This is understandable, since class definition doesn't exist as a file --- it is generated at runtime. However, ClassPool.get() should still succeed for classes that have no URL, yet can be found through its ClassLoader. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6127) Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-6127?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-6127: ------------------------------------ Thanks [~veselroger] for reporting the WFLY-7075 jira to add the suggested extension. For applying the patch that you mention, for the org.jboss.as.jpa.container.ExtendedEntityManager.getSynchronizationType() to return the proper application specified SynchronizationType, could you please also create a tracking jira for that bug fix, which your comment correctly identifies as still unfixed after WFLY-6127 changes were applied. We need a separate jira for that bug fix because the changes for WFLY-6127 were already released in WildFly 10.1.0, so it would be confusing to reopen it. Thank you! -Scott > Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context > ---------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-6127 > URL: https://issues.jboss.org/browse/WFLY-6127 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 9.0.2.Final, 10.0.0.Final > Reporter: Mazen Mahmoud > Assignee: Scott Marlow > Priority: Blocker > Fix For: 10.1.0.CR1, 10.1.0.Final > > Attachments: server-log.txt > > > SPEC: If a component is called and the JTA transaction is propagated into that component: > If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED > associated with the JTA transaction and the target component specifies a persistence context of type SynchronizationType.SYNCHRONIZED, the IllegalStateException is thrown by the container > We have a stateful session bean (SFB1) / PC: TRANSACTION/UNSYNCHRONIZED) > stateful session bean (SFB2) / PC: TRANSACTION/SYNCHRONIZED) > SFB1 method M1 (REQUIRED) calls SFB2 Method 2 (REQUIRED): > PC is propagated from SFB1 to SFB2 without any exception. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7083) Resource adapter subsystem configuration descriptions: wm-security

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/WFLY-7083?page=com.atlassian.jira.plugin.... ] Ilia Vassilev updated WFLY-7083: -------------------------------- Affects Version/s: 10.1.0.Final > Resource adapter subsystem configuration descriptions: wm-security > ------------------------------------------------------------------ > > Key: WFLY-7083 > URL: https://issues.jboss.org/browse/WFLY-7083 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 10.1.0.Final > Reporter: Ilia Vassilev > Assignee: Ilia Vassilev > Priority: Trivial > > These descriptions of wm-security may want to be reviewed. > * There is a typo in the resource description of {{wm-security}}: > bq. Toggle on/off wm.security for this resource-adapter. In case of false all wm-security-* parameters are ignored, even thei defaults. > * For {{wm-security-mapping-required}}, the description seems to refer to documentation sections: > bq. Defines if a mapping is required for security credentials. A value of false means Case 1 as defined in section 16.4.3, and a value of true means Case 2 as defined in section 16.4.4. > However these sections can me moved or removed, and the numbers will often change. I'm not even sure what content this refers to. We shouldn't hard-code documentation references. > * Ending the description with a full stop is also missing on many descriptions. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7083) Resource adapter subsystem configuration descriptions: wm-security

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/WFLY-7083?page=com.atlassian.jira.plugin.... ] Ilia Vassilev moved JBEAP-5945 to WFLY-7083: -------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7083 (was: JBEAP-5945) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JCA (was: JCA) (was: User Experience) Affects Version/s: (was: 7.0.0.GA) > Resource adapter subsystem configuration descriptions: wm-security > ------------------------------------------------------------------ > > Key: WFLY-7083 > URL: https://issues.jboss.org/browse/WFLY-7083 > Project: WildFly > Issue Type: Bug > Components: JCA > Reporter: Ilia Vassilev > Assignee: Ilia Vassilev > Priority: Trivial > > These descriptions of wm-security may want to be reviewed. > * There is a typo in the resource description of {{wm-security}}: > bq. Toggle on/off wm.security for this resource-adapter. In case of false all wm-security-* parameters are ignored, even thei defaults. > * For {{wm-security-mapping-required}}, the description seems to refer to documentation sections: > bq. Defines if a mapping is required for security credentials. A value of false means Case 1 as defined in section 16.4.3, and a value of true means Case 2 as defined in section 16.4.4. > However these sections can me moved or removed, and the numbers will often change. I'm not even sure what content this refers to. We shouldn't hard-code documentation references. > * Ending the description with a full stop is also missing on many descriptions. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7069) EJBs accessible too early (spec violation) - deployment marked started before ready

by Brad Maxwell (JIRA)

[ https://issues.jboss.org/browse/WFLY-7069?page=com.atlassian.jira.plugin.... ] Brad Maxwell updated WFLY-7069: ------------------------------- Component/s: EE EJB > EJBs accessible too early (spec violation) - deployment marked started before ready > ----------------------------------------------------------------------------------- > > Key: WFLY-7069 > URL: https://issues.jboss.org/browse/WFLY-7069 > Project: WildFly > Issue Type: Bug > Components: EE, EJB > Affects Versions: 10.1.0.Final > Reporter: Brad Maxwell > Assignee: Fedor Gavrilov > > Follow up of WFLY-6402, the deployment is being marked started in the deployment repository before it is ready, resulting in requests being accepted. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1276) KieContainer.newKieSession((String) null) should return the default ksession to be consistent with getKieSessionModel(null)

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1276?page=com.atlassian.jira.plugi... ] Geoffrey De Smet commented on DROOLS-1276: ------------------------------------------ Raisd priority of this one, because without a fix for this one, the kie optaplanner-execution-server can't handle kjar that use the default ksession (which is a common use case). > KieContainer.newKieSession((String) null) should return the default ksession to be consistent with getKieSessionModel(null) > --------------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-1276 > URL: https://issues.jboss.org/browse/DROOLS-1276 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 6.5.0.CR1 > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > Priority: Critical > > This works to get the default kieSession: > {code} > String ksessionName = null; > // if ksessionName is null, then the default kieSession is used > KieSessionModel kieSessionModel = kieContainer.getKieSessionModel(ksessionName); > {code} > But this doesn't work to get the default ksession: > {code} > String ksessionName = null; > // Fails if ksessionName is null. Should return the default ksession instead. > return kieContainer.newKieSession(ksessionName); > {code} > The above fails if ksessioName is null with this stacktrace: > {code} > java.lang.NullPointerException > at java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011) > at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1006) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:692) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:652) > at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirectorFactory.newKieSession(DroolsScoreDirectorFactory.java:129) > {code} > If no default ksession exists with argument null, a nice error message should be thrown. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1276) KieContainer.newKieSession((String) null) should return the default ksession to be consistent with getKieSessionModel(null)

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1276?page=com.atlassian.jira.plugi... ] Geoffrey De Smet updated DROOLS-1276: ------------------------------------- Priority: Critical (was: Major) > KieContainer.newKieSession((String) null) should return the default ksession to be consistent with getKieSessionModel(null) > --------------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-1276 > URL: https://issues.jboss.org/browse/DROOLS-1276 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 6.5.0.CR1 > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > Priority: Critical > > This works to get the default kieSession: > {code} > String ksessionName = null; > // if ksessionName is null, then the default kieSession is used > KieSessionModel kieSessionModel = kieContainer.getKieSessionModel(ksessionName); > {code} > But this doesn't work to get the default ksession: > {code} > String ksessionName = null; > // Fails if ksessionName is null. Should return the default ksession instead. > return kieContainer.newKieSession(ksessionName); > {code} > The above fails if ksessioName is null with this stacktrace: > {code} > java.lang.NullPointerException > at java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011) > at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1006) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:692) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:652) > at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirectorFactory.newKieSession(DroolsScoreDirectorFactory.java:129) > {code} > If no default ksession exists with argument null, a nice error message should be thrown. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1127) SocketBindingManagerImpl$UnnamedRegistryImpl is overly picky about unbound sockets

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1127?page=com.atlassian.jira.plugi... ] Paul Ferraro commented on WFCORE-1127: -------------------------------------- [~dan.berindei] "JGroups prior to version 4.0 "fixes" this by always replacing the ManagedSocketFactory set by JChannelFactory.init() with its own DefaultSocketFactory in JChannel.startStack()." That not the case in WF 10. This was corrected almost a year ago: https://github.com/wildfly/wildfly/commit/ab5b4358aef108dfa8296b1f5df7888... This exposed a number of issues with unbound sockets and the SocketBindingManager - all of which were fixed, such that WildFly 10.x uses the the provided ManagedSocketFactory w/JGroups 3.6.x without issue. Granted, I haven't tried this with JGroups 4 yet, but it seems to me that the infinispan-server fork of WildFly's jgroups subsystem is quite out of date. > SocketBindingManagerImpl$UnnamedRegistryImpl is overly picky about unbound sockets > ---------------------------------------------------------------------------------- > > Key: WFCORE-1127 > URL: https://issues.jboss.org/browse/WFCORE-1127 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.1.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 2.0.2.Final > > > A failure like this isn't necessary: > {code} > 08:02:23,475 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.jgroups.channel.ee.connector: org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee.connector: java.lang.IllegalStateException > at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:96) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.IllegalStateException > at org.jboss.as.network.SocketBindingManagerImpl$UnnamedRegistryImpl.unregisterBinding(SocketBindingManagerImpl.java:501) > at org.jboss.as.network.ManagedDatagramSocketBinding.close(ManagedDatagramSocketBinding.java:73) > at org.jboss.as.clustering.jgroups.ManagedSocketFactory.close(ManagedSocketFactory.java:148) > at org.jgroups.protocols.UDP.closeUnicastSocket(UDP.java:577) > at org.jgroups.protocols.UDP.destroySockets(UDP.java:429) > at org.jgroups.protocols.UDP.start(UDP.java:274) > at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965) > at org.jgroups.JChannel.startStack(JChannel.java:890) > at org.jgroups.JChannel._preConnect(JChannel.java:553) > at org.jgroups.JChannel.connect(JChannel.java:288) > at org.jgroups.JChannel.connect(JChannel.java:279) > at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:94) > ... 5 more > {code} > If there's no socket address, it should just move on. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7075) proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization)

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-7075: ------------------------------------ Sounds good, I pasted my last comment mostly for me, so I wouldn't have to open the spec and find it, to review it again, while thinking about this issue. :) > proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization) > ------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7075 > URL: https://issues.jboss.org/browse/WFLY-7075 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.1.0.Final > Environment: *AppServer:* WildFly 10.1.0.Final > *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar > Reporter: Viacheslav Astapkovich > Assignee: Scott Marlow > Attachments: kitchensink-ear.rar > > > As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. > > *The obtained defect:* > A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. > The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) > *FIX:* > We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 > Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... > _Changes_: The method getSynchronizationType returns declared synchronization type. > *Consequences:* > We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. > Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. > It requires a declaration of synchronize persistence context. > We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. > However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. > *Our actions:* > We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). > This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. > _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... > *Example for reproduction:* > I modified quickstart example: [^kitchensink-ear.rar] > MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. > MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. > MemberRepository also perform join Transaction. > Questions from [~smarlow]: > - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. > We decided to use Container-managed EntityManager, because > - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components > - The container makes our job > We want to use the existing mechanism > *In Addition:* > Formally, this is out of JPA SPEC, but we have the following reasons: > - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". > But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. > ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) > - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7077) logging profile with apache commons does not work

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-7077?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-7077: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1374457 Bugzilla Update: Perform > logging profile with apache commons does not work > -------------------------------------------------- > > Key: WFLY-7077 > URL: https://issues.jboss.org/browse/WFLY-7077 > Project: WildFly > Issue Type: Bug > Components: Logging > Reporter: Brad Maxwell > Assignee: James Perkins > > All entry logs go to the log file of the first accessed application logging profile. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2099) TP: one single thread pool

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2099?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2099: -------------------------------- Hmm, UPerf shows slightly better performance with a {{ForkJoinPool}} of size {{Runtime.availableProcessors()}}. Adding a flag {{use_fork_join_pool}} to make use of FJP configurable... > TP: one single thread pool > -------------------------- > > Key: JGRP-2099 > URL: https://issues.jboss.org/browse/JGRP-2099 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently, TP has 4 thread pools: > * OOB > * Regular > * Internal > * Timer (used by TimeScheduler3) > The reason for this was mainly to prevent certain types of tasks from getting dropped due to a full pool. However, this can be changed by (1) making the pool have no queue and (2) handling the RejectedExecutionException (e.g. by spawning a new thread, or upping the max-threads value) for (e.g.) INTERNAL messages and timer tasks. > This not only simplify configuration (1 config section rather than 4), but also reduces the size of TP (removal of accessors, attributes). Things might also become a bit faster as a result. > The new common pool would have the following characteristics: > * Default rejection policy of "abort" (so we can handle pool exhaustion) > * No queue ({{SynchronousQueue}}), so new threads up to max-threads are created if none of the existing ones are available. The queue config attribute will be removed > * Catch RejectedExecutionException for INTERNAL messages and timer tasks. A new thread will be spawned on a RejectedExecutionException. This will be used mainly by INTERNAL messages and timer tasks > * Alternatively, we could increase max-threads (if {{ergonomics==true}}) if we get a constant rate of these exceptions -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7029) RemoteFailoverTestCast#testGracefulShutdownConcurrentFailover fails with "ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations."

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7029?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-7029: --------------------------------- Comment: was deleted (was: Hi Radoslav, In mod_cluster 1.3.1.final, mod_cluster-manager status page reports wrong information. For details, can you please check following thread. https://developer.jboss.org/thread/271283?start=0&tstart=0 Thanks. Leo) > RemoteFailoverTestCast#testGracefulShutdownConcurrentFailover fails with "ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations." > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7029 > URL: https://issues.jboss.org/browse/WFLY-7029 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Richard Achmatowicz > Labels: clean_shutdown > > https://ci.wildfly.org/viewLog.html?buildId=24851&tab=buildResultsDiv&bui... > {noformat} > 04:31:43,323 INFO [org.jboss.as.test.clustering.NodeUtil] (main) Stopping container=container-0, timeout=15 > 04:31:43,324 INFO [org.jboss.as.arquillian.container.controller.ClientWildFlyContainerController] (main) Manual stopping of a server instance with timeout=15 > &amp#27;[0m04:31:43,338 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0211: Suspending server with 15000 ms timeout. > &amp#27;[0m04:31:43,343 INFO [org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler] (Remoting "config-based-ejb-client-endpoint" task-10) Retrying invocation which failed on node node-0 with exception:: javax.ejb.NoSuchEJBException: No such EJB[appname=,modulename=remote-failover-test,distinctname=,beanname=SlowToDestroyStatefulIncrementorBean,viewclassname=org.jboss.as.test.clustering.cluster.ejb.remote.bean.Incrementor] > at org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler.processMessage(NoSuchEJBExceptionResponseHandler.java:64) > at org.jboss.ejb.client.remoting.ChannelAssociation.processResponse(ChannelAssociation.java:386) > at org.jboss.ejb.client.remoting.ChannelAssociation$ResponseReceiver.handleMessage(ChannelAssociation.java:498) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > &amp#27;[0m04:31:43,345 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' > &amp#27;[0m&amp#27;[0m04:31:43,430 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping > &amp#27;[0m&amp#27;[0m04:31:43,436 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 29) MODCLUSTER000002: Initiating mod_cluster shutdown > &amp#27;[0m&amp#27;[0m04:31:43,445 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 74) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:/ConnectionFactory > &amp#27;[0m&amp#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000080: Disconnecting JGroups channel hibernate > &amp#27;[0m&amp#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher for channel hibernate > &amp#27;[0m&amp#27;[0m04:31:43,463 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000080: Disconnecting JGroups channel server > &amp#27;[0m&amp#27;[0m04:31:43,464 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000082: Stopping the RpcDispatcher for channel server > &amp#27;[0m&amp#27;[0m04:31:43,471 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000029: Passivating all entries to disk > &amp#27;[0m&amp#27;[0m04:31:43,472 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000030: Passivated 2 entries in 0 milliseconds > &amp#27;[0m&amp#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel web > &amp#27;[0m&amp#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel web > &amp#27;[0m&amp#27;[0m04:31:43,502 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 29) WFLYCLINF0003: Stopped remote-failover-test.jar cache from ejb container > &amp#27;[0m&amp#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel testDbPersistence > &amp#27;[0m&amp#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel testDbPersistence > &amp#27;[0m&amp#27;[33m04:31:43,502 WARN [org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler] (thread-11,ee,node-0) ISPN000071: Caught exception when handling command LockControlCommand{cache=remote-failover-test.jar, keys=[UnknownSessionID [6951504948515351686656515249505365655750686851525048706670486766]], flags=[FORCE_WRITE_LOCK], unlock=false, gtx=GlobalTransaction:<node-1>:48:remote}: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > at org.jgroups.JChannel.up(JChannel.java:738) > at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120) > at org.jgroups.stack.Protocol.up(Protocol.java:380) > at org.jgroups.protocols.FORK.up(FORK.java:114) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070) > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD.up(FD.java:260) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) > at org.jgroups.protocols.Discovery.up(Discovery.java:296) > at org.jgroups.protocols.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52) > at java.lang.Thread.run(Thread.java:745) > &amp#27;[0m&amp#27;[0m04:31:43,517 INFO [org.wildfly.extension.messaging-activemq] (MSC service thread 1-2) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory > &amp#27;[0m&amp#27;[0m04:31:43,517 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > &amp#27;[0m&amp#27;[0m04:31:43,518 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA] > &amp#27;[0m&amp#27;[0m04:31:43,535 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-8) WFLYJCA0019: Stopped Driver service with driver-name = h2 > &amp#27;[0m&amp#27;[0m04:31:43,547 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 2) WFLYCLINF0003: Stopped client-mappings cache from ejb container > &amp#27;[0m04:31:43,565 INFO [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-14) EJBCLIENT000016: Channel Channel ID b007a55b (outbound) of Remoting connection 017c35ab to /0:0:0:0:0:0:0:1:8080 of endpoint "config-based-ejb-client-endpoint" <1c33eee> can no longer process messages > &amp#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000080: Disconnecting JGroups channel ejb > &amp#27;[0m&amp#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000082: Stopping the RpcDispatcher for channel ejb > &amp#27;[0m&amp#27;[0m04:31:43,575 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 35) AMQ151003: resource adaptor stopped > &amp#27;[0m&amp#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow AJP listener ajp suspending > &amp#27;[0m&amp#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [::1]:8009 > &amp#27;[0m&amp#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTPS listener https suspending > &amp#27;[0m&amp#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [::1]:8443 > &amp#27;[0m&amp#27;[31m04:31:43,585 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-11) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace > at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:795) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642) > at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602) > at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577) > at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) > at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962) > at org.infinispan.remoting.transport.jgroups.RspListFuture.futureDone(RspListFuture.java:31) > at org.jgroups.blocks.Request.checkCompletion(Request.java:152) > at org.jgroups.blocks.GroupRequest.receiveResponse(GroupRequest.java:116) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:427) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > at org.jgroups.JChannel.up(JChannel.java:738) > at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120) > at org.jgroups.stack.Protocol.up(Protocol.java:380) > at org.jgroups.protocols.FORK.up(FORK.java:114) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070) > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD.up(FD.java:260) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) > at org.jgroups.protocols.Discovery.up(Discovery.java:296) > at org.jgroups.protocols.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.infinispan.commons.CacheException: Problems invoking command. > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.exceptionHandlingCommand(BasePerCacheInboundInvocationHandler.java:106) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:101) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > ... 27 more > Caused by: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > ... 33 more > &amp#27;[0m&amp#27;[31m04:31:43,588 ERROR [org.jboss.as.ejb3.invocation] (default task-11) WFLYEJB0034: EJB Invocation failed on component SlowToDestroyStatefulIncrementorBean for method public abstract org.jboss.as.test.clustering.cluster.ejb.remote.bean.Result org.jboss.as.test.clustering.cluster.ejb.remote.bean.Incrementor.increment(): javax.ejb.EJBException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace > at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:328) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:201) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:263) > at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213) > at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76) > at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace > at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:795) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642) > at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602) > at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577) > at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) > at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962) > at org.infinispan.remoting.transport.jgroups.RspListFuture.futureDone(RspListFuture.java:31) > at org.jgroups.blocks.Request.checkCompletion(Request.java:152) > at org.jgroups.blocks.GroupRequest.receiveResponse(GroupRequest.java:116) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:427) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > at org.jgroups.JChannel.up(JChannel.java:738) > at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120) > at org.jgroups.stack.Protocol.up(Protocol.java:380) > at org.jgroups.protocols.FORK.up(FORK.java:114) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070) > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD.up(FD.java:260) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) > at org.jgroups.protocols.Discovery.up(Discovery.java:296) > at org.jgroups.protocols.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52) > ... 1 more > Caused by: org.infinispan.commons.CacheException: Problems invoking command. > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.exceptionHandlingCommand(BasePerCacheInboundInvocationHandler.java:106) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:101) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > ... 27 more > Caused by: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > ... 33 more > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7080) Creating ssl context with only required attribute cause NPE

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7080?page=com.atlassian.jira.plugin.... ] Martin Choma edited comment on WFLY-7080 at 9/9/16 7:06 AM: ------------------------------------------------------------ As stated in javadoc of SSLContextBuilder "key-managers" is required and "protocols" is optional. What is contrary to model validation, where "key-managers" is optional and protocols is "required". [1] https://github.com/wildfly-security/wildfly-elytron/blob/d9c5a9e2ae3681f8... was (Author: mchoma): As stated in javadoc of SSLContextBuilder "key-managers" is required and "protocols" is optional. What is in contrast to model validation, where "key-managers" is optional and protocols is "required". [1] https://github.com/wildfly-security/wildfly-elytron/blob/d9c5a9e2ae3681f8... > Creating ssl context with only required attribute cause NPE > ----------------------------------------------------------- > > Key: WFLY-7080 > URL: https://issues.jboss.org/browse/WFLY-7080 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Critical > Fix For: 11.0.0.Alpha1 > > > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=server2:add(protocols=[TLSv1_2]) > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {noformat} > In log of server there is exception: > {noformat} > 07:12:21,014 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.security.ssl-context.server2: org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NullPointerException > at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:275) > at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:45) > at org.wildfly.extension.elytron.SSLDefinitions$3.lambda$getValueSupplier$1(SSLDefinitions.java:411) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > 07:12:21,016 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 6) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("server-ssl-context" => "server2") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7082) Adding simple-permission-mapper with some permission throws NPE

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7082?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-7082: -------------------------------------- Assignee: Jan Kalina (was: Darran Lofthouse) > Adding simple-permission-mapper with some permission throws NPE > --------------------------------------------------------------- > > Key: WFLY-7082 > URL: https://issues.jboss.org/browse/WFLY-7082 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > > Adding simple-permission-mapper with ChangeRoleMapperPermission or RunAsPrincipalPermission throws NPE. In case when LoginPermission is used then it works correctly. > {code} > /subsystem=elytron/simple-permission-mapper=SomeMapper:add(permission-mappings=[{roles=[All],permissions=[{class-name="org.wildfly.security.auth.permission.ChangeRoleMapperPermission"}]}]) > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.permission-mapper.SomeMapper" => "org.jboss.msc.service.StartException in service org.wildfly.security.permission-mapper.SomeMapper: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.permission-mapper.SomeMapper"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {code} > NPE occurs in server log: > {code} > ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service org.wildfly.security.permission-mapper.SomeMapper: org.jboss.msc.service.StartException in service org.wildfly.security.permission-mapper.SomeMapper: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NullPointerException > at org.wildfly.security.permission.ByNamePermissionCollection.doAdd(ByNamePermissionCollection.java:59) > at org.wildfly.security.permission.AbstractPermissionCollection.add(AbstractPermissionCollection.java:83) > at java.security.Permissions.add(Permissions.java:133) > at org.wildfly.extension.elytron.PermissionMapperDefinitions.createSimplePermissionMapper(PermissionMapperDefinitions.java:214) > at org.wildfly.extension.elytron.PermissionMapperDefinitions.access$000(PermissionMapperDefinitions.java:67) > at org.wildfly.extension.elytron.PermissionMapperDefinitions$2.lambda$getValueSupplier$0(PermissionMapperDefinitions.java:188) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7082) Adding simple-permission-mapper with some permission throws NPE

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7082?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-7082: ------------------------------- Affects Version/s: 11.0.0.Alpha1 > Adding simple-permission-mapper with some permission throws NPE > --------------------------------------------------------------- > > Key: WFLY-7082 > URL: https://issues.jboss.org/browse/WFLY-7082 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > Adding simple-permission-mapper with ChangeRoleMapperPermission or RunAsPrincipalPermission throws NPE. In case when LoginPermission is used then it works correctly. > {code} > /subsystem=elytron/simple-permission-mapper=SomeMapper:add(permission-mappings=[{roles=[All],permissions=[{class-name="org.wildfly.security.auth.permission.ChangeRoleMapperPermission"}]}]) > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.permission-mapper.SomeMapper" => "org.jboss.msc.service.StartException in service org.wildfly.security.permission-mapper.SomeMapper: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.permission-mapper.SomeMapper"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {code} > NPE occurs in server log: > {code} > ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service org.wildfly.security.permission-mapper.SomeMapper: org.jboss.msc.service.StartException in service org.wildfly.security.permission-mapper.SomeMapper: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NullPointerException > at org.wildfly.security.permission.ByNamePermissionCollection.doAdd(ByNamePermissionCollection.java:59) > at org.wildfly.security.permission.AbstractPermissionCollection.add(AbstractPermissionCollection.java:83) > at java.security.Permissions.add(Permissions.java:133) > at org.wildfly.extension.elytron.PermissionMapperDefinitions.createSimplePermissionMapper(PermissionMapperDefinitions.java:214) > at org.wildfly.extension.elytron.PermissionMapperDefinitions.access$000(PermissionMapperDefinitions.java:67) > at org.wildfly.extension.elytron.PermissionMapperDefinitions$2.lambda$getValueSupplier$0(PermissionMapperDefinitions.java:188) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2099) TP: one single thread pool

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2099?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2099: -------------------------------- The recommendations to use a FJP are: * must be plain (between 100 and 10,000 basic computational steps in the compute method), * compute intensive code only, * no blocking, * no I/O, * no synchronization Timer tasks and messages submitted to a FJP cannot guarantee that they are non-blocking; as a matter of fact messages delivered to an application can block or synchronize, as JGroups has no control over them... > TP: one single thread pool > -------------------------- > > Key: JGRP-2099 > URL: https://issues.jboss.org/browse/JGRP-2099 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently, TP has 4 thread pools: > * OOB > * Regular > * Internal > * Timer (used by TimeScheduler3) > The reason for this was mainly to prevent certain types of tasks from getting dropped due to a full pool. However, this can be changed by (1) making the pool have no queue and (2) handling the RejectedExecutionException (e.g. by spawning a new thread, or upping the max-threads value) for (e.g.) INTERNAL messages and timer tasks. > This not only simplify configuration (1 config section rather than 4), but also reduces the size of TP (removal of accessors, attributes). Things might also become a bit faster as a result. > The new common pool would have the following characteristics: > * Default rejection policy of "abort" (so we can handle pool exhaustion) > * No queue ({{SynchronousQueue}}), so new threads up to max-threads are created if none of the existing ones are available. The queue config attribute will be removed > * Catch RejectedExecutionException for INTERNAL messages and timer tasks. A new thread will be spawned on a RejectedExecutionException. This will be used mainly by INTERNAL messages and timer tasks > * Alternatively, we could increase max-threads (if {{ergonomics==true}}) if we get a constant rate of these exceptions -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7082) Adding simple-permission-mapper with some permission throws NPE

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-7082: ---------------------------------- Summary: Adding simple-permission-mapper with some permission throws NPE Key: WFLY-7082 URL: https://issues.jboss.org/browse/WFLY-7082 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Adding simple-permission-mapper with ChangeRoleMapperPermission or RunAsPrincipalPermission throws NPE. In case when LoginPermission is used then it works correctly. {code} /subsystem=elytron/simple-permission-mapper=SomeMapper:add(permission-mappings=[{roles=[All],permissions=[{class-name="org.wildfly.security.auth.permission.ChangeRoleMapperPermission"}]}]) { "outcome" => "failed", "failure-description" => { "WFLYCTL0080: Failed services" => {"org.wildfly.security.permission-mapper.SomeMapper" => "org.jboss.msc.service.StartException in service org.wildfly.security.permission-mapper.SomeMapper: Failed to start service Caused by: java.lang.NullPointerException"}, "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.permission-mapper.SomeMapper"], "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined }, "rolled-back" => true } {code} NPE occurs in server log: {code} ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service org.wildfly.security.permission-mapper.SomeMapper: org.jboss.msc.service.StartException in service org.wildfly.security.permission-mapper.SomeMapper: Failed to start service at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.NullPointerException at org.wildfly.security.permission.ByNamePermissionCollection.doAdd(ByNamePermissionCollection.java:59) at org.wildfly.security.permission.AbstractPermissionCollection.add(AbstractPermissionCollection.java:83) at java.security.Permissions.add(Permissions.java:133) at org.wildfly.extension.elytron.PermissionMapperDefinitions.createSimplePermissionMapper(PermissionMapperDefinitions.java:214) at org.wildfly.extension.elytron.PermissionMapperDefinitions.access$000(PermissionMapperDefinitions.java:67) at org.wildfly.extension.elytron.PermissionMapperDefinitions$2.lambda$getValueSupplier$0(PermissionMapperDefinitions.java:188) at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) ... 3 more {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2099) TP: one single thread pool

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2099?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2099: -------------------------------- Hmm, reading [1] (and part 2 and 3), I'm not convinced FJP is the solution. What bothers me so far is that a FJP is essentially unbounded and never rejects a task because it is full, but rather blocks or spawns a new thread (when {{ManagedBlocker}} is used). However, I _want_ an exhausted pool to reject tasks (other than non-blocking timer tasks and internal messages)! So far, I've not managed to see more than {{parallism +1}} threads in the FJP, I need to see if I can create more threads in the pool (e.g. by using ManagedBlocker). IIUIC, FJP uses (unbounded?) queues for each worker. If unbounded, then not good! [1] http://coopsoft.com/ar/CalamityArticle.html > TP: one single thread pool > -------------------------- > > Key: JGRP-2099 > URL: https://issues.jboss.org/browse/JGRP-2099 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently, TP has 4 thread pools: > * OOB > * Regular > * Internal > * Timer (used by TimeScheduler3) > The reason for this was mainly to prevent certain types of tasks from getting dropped due to a full pool. However, this can be changed by (1) making the pool have no queue and (2) handling the RejectedExecutionException (e.g. by spawning a new thread, or upping the max-threads value) for (e.g.) INTERNAL messages and timer tasks. > This not only simplify configuration (1 config section rather than 4), but also reduces the size of TP (removal of accessors, attributes). Things might also become a bit faster as a result. > The new common pool would have the following characteristics: > * Default rejection policy of "abort" (so we can handle pool exhaustion) > * No queue ({{SynchronousQueue}}), so new threads up to max-threads are created if none of the existing ones are available. The queue config attribute will be removed > * Catch RejectedExecutionException for INTERNAL messages and timer tasks. A new thread will be spawned on a RejectedExecutionException. This will be used mainly by INTERNAL messages and timer tasks > * Alternatively, we could increase max-threads (if {{ergonomics==true}}) if we get a constant rate of these exceptions -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7080) Creating ssl context with only required attribute cause NPE

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7080?page=com.atlassian.jira.plugin.... ] Martin Choma commented on WFLY-7080: ------------------------------------ As stated in javadoc of SSLContextBuilder "key-managers" is required and "protocols" is optional. What is in contrast to model validation, where "key-managers" is optional and protocols is "required". [1] https://github.com/wildfly-security/wildfly-elytron/blob/d9c5a9e2ae3681f8... > Creating ssl context with only required attribute cause NPE > ----------------------------------------------------------- > > Key: WFLY-7080 > URL: https://issues.jboss.org/browse/WFLY-7080 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Critical > Fix For: 11.0.0.Alpha1 > > > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=server2:add(protocols=[TLSv1_2]) > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {noformat} > In log of server there is exception: > {noformat} > 07:12:21,014 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.security.ssl-context.server2: org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NullPointerException > at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:275) > at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:45) > at org.wildfly.extension.elytron.SSLDefinitions$3.lambda$getValueSupplier$1(SSLDefinitions.java:411) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > 07:12:21,016 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 6) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("server-ssl-context" => "server2") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7080) Creating ssl context with only required attribute cause NPE

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7080?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-7080: ----------------------------------- Description: {noformat} [standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=server2:add(protocols=[TLSv1_2]) { "outcome" => "failed", "failure-description" => { "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service Caused by: java.lang.NullPointerException"}, "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined }, "rolled-back" => true } {noformat} In log of server there is exception: {noformat} 07:12:21,014 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.security.ssl-context.server2: org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.NullPointerException at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:275) at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:45) at org.wildfly.extension.elytron.SSLDefinitions$3.lambda$getValueSupplier$1(SSLDefinitions.java:411) at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) ... 3 more 07:12:21,016 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 6) WFLYCTL0013: Operation ("add") failed - address: ([ ("subsystem" => "elytron"), ("server-ssl-context" => "server2") ]) - failure description: { "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service Caused by: java.lang.NullPointerException"}, "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined } {noformat} was: {noformat} [standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=server2:add(protocols=[TLSv1_2]) { "outcome" => "failed", "failure-description" => { "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service Caused by: java.lang.NullPointerException"}, "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined }, "rolled-back" => true } {noformat} In log of server there is exception: {noformat} 07:12:21,014 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.security.ssl-context.server2: org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.NullPointerException at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:275) at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:45) at org.wildfly.extension.elytron.SSLDefinitions$3.lambda$getValueSupplier$1(SSLDefinitions.java:411) at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) ... 3 more 07:12:21,016 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 6) WFLYCTL0013: Operation ("add") failed - address: ([ ("subsystem" => "elytron"), ("server-ssl-context" => "server2") ]) - failure description: { "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service Caused by: java.lang.NullPointerException"}, "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined } {noformat} Looking into org.wildfly.security.ssl.SSLContextBuilder, one question come to my mind. Is there still possibility for user to configure equivalent of SSLContext.getInstance("Default")? > Creating ssl context with only required attribute cause NPE > ----------------------------------------------------------- > > Key: WFLY-7080 > URL: https://issues.jboss.org/browse/WFLY-7080 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Critical > Fix For: 11.0.0.Alpha1 > > > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=server2:add(protocols=[TLSv1_2]) > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {noformat} > In log of server there is exception: > {noformat} > 07:12:21,014 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.security.ssl-context.server2: org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NullPointerException > at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:275) > at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:45) > at org.wildfly.extension.elytron.SSLDefinitions$3.lambda$getValueSupplier$1(SSLDefinitions.java:411) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > 07:12:21,016 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 6) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("server-ssl-context" => "server2") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7080) Creating ssl context with only required attribute cause NPE

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7080?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-7080: ---------------------------------------- [~honza889] Of the subsystem issues passed to you so far this one is a little more important, I suspect one of our attributes is not sufficient flagged as required but as a NPE also possibility of a missing null check possibly in the Elytron code. > Creating ssl context with only required attribute cause NPE > ----------------------------------------------------------- > > Key: WFLY-7080 > URL: https://issues.jboss.org/browse/WFLY-7080 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Critical > Fix For: 11.0.0.Alpha1 > > > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=server2:add(protocols=[TLSv1_2]) > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {noformat} > In log of server there is exception: > {noformat} > 07:12:21,014 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.security.ssl-context.server2: org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NullPointerException > at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:275) > at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:45) > at org.wildfly.extension.elytron.SSLDefinitions$3.lambda$getValueSupplier$1(SSLDefinitions.java:411) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > 07:12:21,016 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 6) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("server-ssl-context" => "server2") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > {noformat} > Looking into org.wildfly.security.ssl.SSLContextBuilder, one question come to my mind. Is there still possibility for user to configure equivalent of SSLContext.getInstance("Default")? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7080) Creating ssl context with only required attribute cause NPE

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7080?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-7080: -------------------------------------- Assignee: Jan Kalina (was: Darran Lofthouse) > Creating ssl context with only required attribute cause NPE > ----------------------------------------------------------- > > Key: WFLY-7080 > URL: https://issues.jboss.org/browse/WFLY-7080 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Critical > Fix For: 11.0.0.Alpha1 > > > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=server2:add(protocols=[TLSv1_2]) > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {noformat} > In log of server there is exception: > {noformat} > 07:12:21,014 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.security.ssl-context.server2: org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NullPointerException > at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:275) > at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:45) > at org.wildfly.extension.elytron.SSLDefinitions$3.lambda$getValueSupplier$1(SSLDefinitions.java:411) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > 07:12:21,016 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 6) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("server-ssl-context" => "server2") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > {noformat} > Looking into org.wildfly.security.ssl.SSLContextBuilder, one question come to my mind. Is there still possibility for user to configure equivalent of SSLContext.getInstance("Default")? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7080) Creating ssl context with only required attribute cause NPE

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7080?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-7080: ----------------------------------- Fix Version/s: 11.0.0.Alpha1 > Creating ssl context with only required attribute cause NPE > ----------------------------------------------------------- > > Key: WFLY-7080 > URL: https://issues.jboss.org/browse/WFLY-7080 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 11.0.0.Alpha1 > > > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=server2:add(protocols=[TLSv1_2]) > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {noformat} > In log of server there is exception: > {noformat} > 07:12:21,014 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.security.ssl-context.server2: org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NullPointerException > at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:275) > at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:45) > at org.wildfly.extension.elytron.SSLDefinitions$3.lambda$getValueSupplier$1(SSLDefinitions.java:411) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > 07:12:21,016 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 6) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("server-ssl-context" => "server2") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > {noformat} > Looking into org.wildfly.security.ssl.SSLContextBuilder, one question come to my mind. Is there still possibility for user to configure equivalent of SSLContext.getInstance("Default")? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7080) Creating ssl context with only required attribute cause NPE

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7080?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-7080: ----------------------------------- Priority: Critical (was: Blocker) > Creating ssl context with only required attribute cause NPE > ----------------------------------------------------------- > > Key: WFLY-7080 > URL: https://issues.jboss.org/browse/WFLY-7080 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 11.0.0.Alpha1 > > > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=server2:add(protocols=[TLSv1_2]) > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {noformat} > In log of server there is exception: > {noformat} > 07:12:21,014 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.security.ssl-context.server2: org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NullPointerException > at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:275) > at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:45) > at org.wildfly.extension.elytron.SSLDefinitions$3.lambda$getValueSupplier$1(SSLDefinitions.java:411) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > 07:12:21,016 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 6) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("server-ssl-context" => "server2") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > {noformat} > Looking into org.wildfly.security.ssl.SSLContextBuilder, one question come to my mind. Is there still possibility for user to configure equivalent of SSLContext.getInstance("Default")? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7081) Elytron + https-listener in undertow listener doesn't work with enable-http2 set to "true"

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7081?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved WFLY-7081. ------------------------------------ Fix Version/s: 11.0.0.Alpha1 Resolution: Rejected > Elytron + https-listener in undertow listener doesn't work with enable-http2 set to "true" > ------------------------------------------------------------------------------------------ > > Key: WFLY-7081 > URL: https://issues.jboss.org/browse/WFLY-7081 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 11.0.0.Alpha1 > > > When I want to use HTTPS settings in combination with Elytron subsystem then I have to set "enable-http2" to "false" value. > For settings I followed this blog post http://darranl.blogspot.cz/2016/02/wildfly-elytron-ssl-configuration.html > And as keystore I used default application.keystore -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6890) Add Weld SPI dependency to the transactions module

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/WFLY-6890?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated WFLY-6890: ---------------------------------- Description: To fix JBTM-2704 we need to access bean manager classes from Weld core. To get that dependency on Weld SPI is needed. Without Weld SPI dependency, handlers in JAR as part of EAR cannot be found: {code} ^[[0m^[[31m11:28:32,054 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."service.ear".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."service.ear".WeldStartService: Failed to start service at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: org.jboss.weld.exceptions.WeldException: WELD-001524: Unable to load proxy class for bean @New Managed Bean [class org.jboss.narayana.compensations.internal.CompensatableActionImpl] with qualifiers [@New] with class class org.jboss.narayana.compensations.internal.CompensatableActionImpl using classloader ModuleClassLoader for Module "deployment.service.ear:main" from Service Module Loader at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:371) at org.jboss.weld.injection.producer.SubclassedComponentInstantiator.createEnhancedSubclass(SubclassedComponentInstantiator.java:114) at org.jboss.weld.injection.producer.SubclassedComponentInstantiator.initEnhancedSubclass(SubclassedComponentInstantiator.java:86) at org.jboss.weld.injection.producer.SubclassedComponentInstantiator.<init>(SubclassedComponentInstantiator.java:79) at org.jboss.weld.injection.producer.SubclassedComponentInstantiator.forInterceptedDecoratedBean(SubclassedComponentInstantiator.java:63) at org.jboss.weld.injection.producer.BeanInjectionTarget.initializeAfterBeanDiscovery(BeanInjectionTarget.java:121) at org.jboss.weld.injection.producer.InjectionTargetInitializationContext.initialize(InjectionTargetInitializationContext.java:42) at org.jboss.weld.injection.producer.InjectionTargetService.initialize(InjectionTargetService.java:63) at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:433) at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83) at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:95) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) ... 3 more Caused by: java.lang.RuntimeException: java.lang.NoClassDefFoundError: org/jboss/narayana/compensations/api/CompensatableAction at org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:101) at org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:491) at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:364) ... 15 more Caused by: java.lang.NoClassDefFoundError: org/jboss/narayana/compensations/api/CompensatableAction at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:763) at sun.reflect.GeneratedMethodAccessor34.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:108) at org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:97) ... 17 more Caused by: java.lang.ClassNotFoundException: org.jboss.narayana.compensations.api.CompensatableAction from [Module "deployment.service.ear:main" from Service Module Loader] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:364) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:352) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94) ... 24 more {code} was:To fix JBTM-2704 we need to access bean manager classes from Weld core. To get that dependency on Weld SPI is needed. > Add Weld SPI dependency to the transactions module > -------------------------------------------------- > > Key: WFLY-6890 > URL: https://issues.jboss.org/browse/WFLY-6890 > Project: WildFly > Issue Type: Task > Components: Transactions > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 11.0.0.Alpha1 > > > To fix JBTM-2704 we need to access bean manager classes from Weld core. To get that dependency on Weld SPI is needed. > Without Weld SPI dependency, handlers in JAR as part of EAR cannot be found: > {code} > ^[[0m^[[31m11:28:32,054 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."service.ear".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."service.ear".WeldStartService: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.jboss.weld.exceptions.WeldException: WELD-001524: Unable to load proxy class for bean @New Managed Bean [class org.jboss.narayana.compensations.internal.CompensatableActionImpl] with qualifiers [@New] with class class org.jboss.narayana.compensations.internal.CompensatableActionImpl using classloader ModuleClassLoader for Module "deployment.service.ear:main" from Service Module Loader > at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:371) > at org.jboss.weld.injection.producer.SubclassedComponentInstantiator.createEnhancedSubclass(SubclassedComponentInstantiator.java:114) > at org.jboss.weld.injection.producer.SubclassedComponentInstantiator.initEnhancedSubclass(SubclassedComponentInstantiator.java:86) > at org.jboss.weld.injection.producer.SubclassedComponentInstantiator.<init>(SubclassedComponentInstantiator.java:79) > at org.jboss.weld.injection.producer.SubclassedComponentInstantiator.forInterceptedDecoratedBean(SubclassedComponentInstantiator.java:63) > at org.jboss.weld.injection.producer.BeanInjectionTarget.initializeAfterBeanDiscovery(BeanInjectionTarget.java:121) > at org.jboss.weld.injection.producer.InjectionTargetInitializationContext.initialize(InjectionTargetInitializationContext.java:42) > at org.jboss.weld.injection.producer.InjectionTargetService.initialize(InjectionTargetService.java:63) > at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:433) > at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:95) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > Caused by: java.lang.RuntimeException: java.lang.NoClassDefFoundError: org/jboss/narayana/compensations/api/CompensatableAction > at org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:101) > at org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:491) > at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:364) > ... 15 more > Caused by: java.lang.NoClassDefFoundError: org/jboss/narayana/compensations/api/CompensatableAction > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:763) > at sun.reflect.GeneratedMethodAccessor34.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:108) > at org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:97) > ... 17 more > Caused by: java.lang.ClassNotFoundException: org.jboss.narayana.compensations.api.CompensatableAction from [Module "deployment.service.ear:main" from Service Module Loader] > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:364) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:352) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94) > ... 24 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6890) Add Weld SPI dependency to the transactions module

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/WFLY-6890?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated WFLY-6890: ---------------------------------- Description: To fix JBTM-2704 we need to access bean manager classes from Weld core. To get that dependency on Weld SPI is needed. > Add Weld SPI dependency to the transactions module > -------------------------------------------------- > > Key: WFLY-6890 > URL: https://issues.jboss.org/browse/WFLY-6890 > Project: WildFly > Issue Type: Task > Components: Transactions > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 11.0.0.Alpha1 > > > To fix JBTM-2704 we need to access bean manager classes from Weld core. To get that dependency on Weld SPI is needed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7081) Elytron + https-listener in undertow listener doesn't work with enable-http2 set to "true"

by Hynek Švábek (JIRA)

[ https://issues.jboss.org/browse/WFLY-7081?page=com.atlassian.jira.plugin.... ] Hynek Švábek updated WFLY-7081: ------------------------------- Priority: Critical (was: Major) > Elytron + https-listener in undertow listener doesn't work with enable-http2 set to "true" > ------------------------------------------------------------------------------------------ > > Key: WFLY-7081 > URL: https://issues.jboss.org/browse/WFLY-7081 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Darran Lofthouse > Priority: Critical > > When I want to use HTTPS settings in combination with Elytron subsystem then I have to set "enable-http2" to "false" value. > For settings I followed this blog post http://darranl.blogspot.cz/2016/02/wildfly-elytron-ssl-configuration.html > And as keystore I used default application.keystore -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-263) ClassPool cannot read generated classes

by Paul Pogonyshev (JIRA)

[ https://issues.jboss.org/browse/JASSIST-263?page=com.atlassian.jira.plugi... ] Paul Pogonyshev commented on JASSIST-263: ----------------------------------------- The fix works, thanks. However, for me to better understand: ClassPool absolutely needs bytecode, not a loaded class, right? Would it be somehow possible to keep generated byte[] arrays, or does ClassPool need classes as files? > ClassPool cannot read generated classes > --------------------------------------- > > Key: JASSIST-263 > URL: https://issues.jboss.org/browse/JASSIST-263 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.20.0-GA > Reporter: Paul Pogonyshev > Assignee: Shigeru Chiba > Attachments: JavassistBug.java > > > ClassPool.get() cannot retrieve classes that are in turn generated at runtime. For example, if I try to define at runtime two classes, one of which extends another, the base will not be found, even though it can be retrieved just fine from my class loader. See the attached example. > As far as I could trace it, the issue comes from ClassPoolTail.find() returning a null URL for the class. This is understandable, since class definition doesn't exist as a file --- it is generated at runtime. However, ClassPool.get() should still succeed for classes that have no URL, yet can be found through its ClassLoader. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1775) CLI command for enabling tracking configuration changes act differently when host is specifiend and when it is not

by Ivan Straka (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1775?page=com.atlassian.jira.plugi... ] Ivan Straka updated WFCORE-1775: -------------------------------- Description: If I execute {code} /host=slave/core-service=management/service=configuration-changes:add(history-size=10) {code} on host controller, everything is fine. But, if {code} /core-service=management/service=configuration-changes:add(history-size=10) {code} is executed, {code:json} { "outcome" => "failed", "failure-description" => "WFLYDC0032: Operation add for address [ (\"core-service\" => \"management\"), (\"service\" => \"configuration-changes\") ] can only be handled by the master Domain Controller; this host is not the master Domain Controller", "rolled-back" => true } {code} is returned. I have discussed this with [~ehugonnet], and it has not been decided whether this is correct behavior. For some reason it is trying to route the request to the DC. This jira is supposed to start a discussion about this - is it a bug, or correct behavior? IMHO results of these two commands should should be the same. was: If I execute {code} /host=slave/core-service=management/service=configuration-changes:add(history-size=10) {code} on host controller, everything is fine. But, if {code} /core-service=management/service=configuration-changes:add(history-size=10) {code} is executed, {code:json} { "outcome" => "failed", "failure-description" => "WFLYDC0032: Operation add for address [ (\"core-service\" => \"management\"), (\"service\" => \"configuration-changes\") ] can only be handled by the master Domain Controller; this host is not the master Domain Controller", "rolled-back" => true } {code} is returned. I have discussed this with [~ehugonnet], and it has not been decided whether this is correct behavior. For some reason it is trying to route the request to the DC. This jira is supposed to start a discussion about this - is it a bug, or correct behavior? IMHO these two commands should act the same. > CLI command for enabling tracking configuration changes act differently when host is specifiend and when it is not > ------------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1775 > URL: https://issues.jboss.org/browse/WFCORE-1775 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Ivan Straka > Assignee: Brian Stansberry > > If I execute > {code} > /host=slave/core-service=management/service=configuration-changes:add(history-size=10) > {code} > on host controller, everything is fine. > But, if > {code} > /core-service=management/service=configuration-changes:add(history-size=10) > {code} > is executed, > {code:json} > { > "outcome" => "failed", > "failure-description" => "WFLYDC0032: Operation add for address [ > (\"core-service\" => \"management\"), > (\"service\" => \"configuration-changes\") > ] can only be handled by the master Domain Controller; this host is not the master Domain Controller", > "rolled-back" => true > } > {code} > is returned. > I have discussed this with [~ehugonnet], and it has not been decided whether this is correct behavior. For some reason it is trying to route the request to the DC. > This jira is supposed to start a discussion about this - is it a bug, or correct behavior? > IMHO results of these two commands should should be the same. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1775) CLI command for enabling tracking configuration changes act differently when host is specifiend and when it is not

by Ivan Straka (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1775?page=com.atlassian.jira.plugi... ] Ivan Straka updated WFCORE-1775: -------------------------------- Description: If I execute {code} /host=slave/core-service=management/service=configuration-changes:add(history-size=10) {code} on host controller, everything is fine. But, if {code} /core-service=management/service=configuration-changes:add(history-size=10) {code} is executed, {code:json} { "outcome" => "failed", "failure-description" => "WFLYDC0032: Operation add for address [ (\"core-service\" => \"management\"), (\"service\" => \"configuration-changes\") ] can only be handled by the master Domain Controller; this host is not the master Domain Controller", "rolled-back" => true } {code} is returned. I have discussed this with [~ehugonnet], and it has not been decided whether this is correct behavior. For some reason it is trying to route the request to the DC. This jira is supposed to start a discussion about this - is it a bug, or correct behavior? IMHO these two commands should act the same. was: If I execute {code} /host=slave/core-service=management/service=configuration-changes:add(history-size=10) {code} on host controller, everything is fine. But, if {code} /core-service=management/service=configuration-changes:add(history-size=10) {code} is executed, {code:json} { "outcome" => "failed", "failure-description" => "WFLYDC0032: Operation add for address [ (\"core-service\" => \"management\"), (\"service\" => \"configuration-changes\") ] can only be handled by the master Domain Controller; this host is not the master Domain Controller", "rolled-back" => true } {code} is returned. I have discussed this with [~ehugonnet], and it has not been decided whether this is correct behavior. For some reason it is trying to route the request to the DC. This jira is supposed to start a discussion about this rather than saying that this is a bug. > CLI command for enabling tracking configuration changes act differently when host is specifiend and when it is not > ------------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1775 > URL: https://issues.jboss.org/browse/WFCORE-1775 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Ivan Straka > Assignee: Brian Stansberry > > If I execute > {code} > /host=slave/core-service=management/service=configuration-changes:add(history-size=10) > {code} > on host controller, everything is fine. > But, if > {code} > /core-service=management/service=configuration-changes:add(history-size=10) > {code} > is executed, > {code:json} > { > "outcome" => "failed", > "failure-description" => "WFLYDC0032: Operation add for address [ > (\"core-service\" => \"management\"), > (\"service\" => \"configuration-changes\") > ] can only be handled by the master Domain Controller; this host is not the master Domain Controller", > "rolled-back" => true > } > {code} > is returned. > I have discussed this with [~ehugonnet], and it has not been decided whether this is correct behavior. For some reason it is trying to route the request to the DC. > This jira is supposed to start a discussion about this - is it a bug, or correct behavior? > IMHO these two commands should act the same. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1775) CLI command for enabling tracking configuration changes act differently when host is specifiend and when it is not

by Ivan Straka (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1775?page=com.atlassian.jira.plugi... ] Ivan Straka updated WFCORE-1775: -------------------------------- Description: If I execute {code} /host=slave/core-service=management/service=configuration-changes:add(history-size=10) {code} on host controller, everything is fine. But, if {code} /core-service=management/service=configuration-changes:add(history-size=10) {code} is executed, {code:json} { "outcome" => "failed", "failure-description" => "WFLYDC0032: Operation add for address [ (\"core-service\" => \"management\"), (\"service\" => \"configuration-changes\") ] can only be handled by the master Domain Controller; this host is not the master Domain Controller", "rolled-back" => true } {code} is returned. I have discussed this with [~ehugonnet], and it has not been decided whether this is correct behavior. For some reason it is trying to route the request to the DC. This jira is supposed to start a discussion about this rather than saying that this is a bug. was: If I execute /host=slave/core-service=management/service=configuration-changes:add(history-size=10) on host controller, everything is fine. But, if /core-service=management/service=configuration-changes:add(history-size=10) is executed, {code:json} { "outcome" => "failed", "failure-description" => "WFLYDC0032: Operation add for address [ (\"core-service\" => \"management\"), (\"service\" => \"configuration-changes\") ] can only be handled by the master Domain Controller; this host is not the master Domain Controller", "rolled-back" => true } {code} is returned. I have discussed this with [~ehugonnet], and it has not been decided whether this is correct behavior. For some reason it is trying to route the request to the DC. This jira is supposed to start a discussion about this rather than saying that this is a bug. > CLI command for enabling tracking configuration changes act differently when host is specifiend and when it is not > ------------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1775 > URL: https://issues.jboss.org/browse/WFCORE-1775 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Ivan Straka > Assignee: Brian Stansberry > > If I execute > {code} > /host=slave/core-service=management/service=configuration-changes:add(history-size=10) > {code} > on host controller, everything is fine. But, if > {code} > /core-service=management/service=configuration-changes:add(history-size=10) > {code} > is executed, > {code:json} > { > "outcome" => "failed", > "failure-description" => "WFLYDC0032: Operation add for address [ > (\"core-service\" => \"management\"), > (\"service\" => \"configuration-changes\") > ] can only be handled by the master Domain Controller; this host is not the master Domain Controller", > "rolled-back" => true > } > {code} > is returned. > I have discussed this with [~ehugonnet], and it has not been decided whether this is correct behavior. For some reason it is trying to route the request to the DC. > This jira is supposed to start a discussion about this rather than saying that this is a bug. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1775) CLI command for enabling tracking configuration changes act differently when host is specifiend and when it is not

by Ivan Straka (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1775?page=com.atlassian.jira.plugi... ] Ivan Straka updated WFCORE-1775: -------------------------------- Description: If I execute {code} /host=slave/core-service=management/service=configuration-changes:add(history-size=10) {code} on host controller, everything is fine. But, if {code} /core-service=management/service=configuration-changes:add(history-size=10) {code} is executed, {code:json} { "outcome" => "failed", "failure-description" => "WFLYDC0032: Operation add for address [ (\"core-service\" => \"management\"), (\"service\" => \"configuration-changes\") ] can only be handled by the master Domain Controller; this host is not the master Domain Controller", "rolled-back" => true } {code} is returned. I have discussed this with [~ehugonnet], and it has not been decided whether this is correct behavior. For some reason it is trying to route the request to the DC. This jira is supposed to start a discussion about this rather than saying that this is a bug. was: If I execute {code} /host=slave/core-service=management/service=configuration-changes:add(history-size=10) {code} on host controller, everything is fine. But, if {code} /core-service=management/service=configuration-changes:add(history-size=10) {code} is executed, {code:json} { "outcome" => "failed", "failure-description" => "WFLYDC0032: Operation add for address [ (\"core-service\" => \"management\"), (\"service\" => \"configuration-changes\") ] can only be handled by the master Domain Controller; this host is not the master Domain Controller", "rolled-back" => true } {code} is returned. I have discussed this with [~ehugonnet], and it has not been decided whether this is correct behavior. For some reason it is trying to route the request to the DC. This jira is supposed to start a discussion about this rather than saying that this is a bug. > CLI command for enabling tracking configuration changes act differently when host is specifiend and when it is not > ------------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1775 > URL: https://issues.jboss.org/browse/WFCORE-1775 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Ivan Straka > Assignee: Brian Stansberry > > If I execute > {code} > /host=slave/core-service=management/service=configuration-changes:add(history-size=10) > {code} > on host controller, everything is fine. > But, if > {code} > /core-service=management/service=configuration-changes:add(history-size=10) > {code} > is executed, > {code:json} > { > "outcome" => "failed", > "failure-description" => "WFLYDC0032: Operation add for address [ > (\"core-service\" => \"management\"), > (\"service\" => \"configuration-changes\") > ] can only be handled by the master Domain Controller; this host is not the master Domain Controller", > "rolled-back" => true > } > {code} > is returned. > I have discussed this with [~ehugonnet], and it has not been decided whether this is correct behavior. For some reason it is trying to route the request to the DC. > This jira is supposed to start a discussion about this rather than saying that this is a bug. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1775) CLI command for enabling tracking configuration changes act differently when host is specifiend and when it is not

by Ivan Straka (JIRA)

Ivan Straka created WFCORE-1775: ----------------------------------- Summary: CLI command for enabling tracking configuration changes act differently when host is specifiend and when it is not Key: WFCORE-1775 URL: https://issues.jboss.org/browse/WFCORE-1775 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Ivan Straka Assignee: Brian Stansberry If I execute /host=slave/core-service=management/service=configuration-changes:add(history-size=10) on host controller, everything is fine. But, if /core-service=management/service=configuration-changes:add(history-size=10) is executed, {code:json} { "outcome" => "failed", "failure-description" => "WFLYDC0032: Operation add for address [ (\"core-service\" => \"management\"), (\"service\" => \"configuration-changes\") ] can only be handled by the master Domain Controller; this host is not the master Domain Controller", "rolled-back" => true } {code} is returned. I have discussed this with [~ehugonnet], and it has not been decided whether this is correct behavior. For some reason it is trying to route the request to the DC. This jira is supposed to start a discussion about this rather than saying that this is a bug. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7081) Elytron + https-listener in undertow listener doesn't work with enable-http2 set to "true"

by Hynek Švábek (JIRA)

Hynek Švábek created WFLY-7081: ---------------------------------- Summary: Elytron + https-listener in undertow listener doesn't work with enable-http2 set to "true" Key: WFLY-7081 URL: https://issues.jboss.org/browse/WFLY-7081 Project: WildFly Issue Type: Bug Components: Security Reporter: Hynek Švábek Assignee: Darran Lofthouse When I want to use HTTPS settings in combination with Elytron subsystem then I have to set "enable-http2" to "false" value. For settings I followed this blog post http://darranl.blogspot.cz/2016/02/wildfly-elytron-ssl-configuration.html And as keystore I used default application.keystore -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2100) Timer: don't submit non-blocking tasks to the thread pool

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2100?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2100. ---------------------------- Resolution: Done > Timer: don't submit non-blocking tasks to the thread pool > --------------------------------------------------------- > > Key: JGRP-2100 > URL: https://issues.jboss.org/browse/JGRP-2100 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently, {{TimeScheduler3}} has a runner thread which continually takes tasks from a {{DelayQueue}} and submits them to the thread pool. > If a task is non-blocking, this is not necessary; instead the task can be run on the runner's thread. This will reduce the number of thread created in the thread pool. > Investigate whether it is possible to mark tasks as blocking or non-blocking. Example: an {{AgeOutCache}} task is always non-blocking. A {{UNICAST3}} or {{NAKACK2}} retransmission task is (potentially) blocking if {{TCP}} is used as transport and non-blocking if for example {{UDP}} or {{TCP_NIO2}} are used. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2100) Timer: don't submit non-blocking tasks to the thread pool

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2100?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2100: -------------------------------- I made this configurable; the old behavior can be resurrected by setting {{timer_handle_non_blocking_tasks}} to false. Retransmission should not really be an issue as flow control should prevent huge gaps from occurring. I'll revisit this when I've read up on ForkJoinPool and its {{managedBlock()}} operation. > Timer: don't submit non-blocking tasks to the thread pool > --------------------------------------------------------- > > Key: JGRP-2100 > URL: https://issues.jboss.org/browse/JGRP-2100 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently, {{TimeScheduler3}} has a runner thread which continually takes tasks from a {{DelayQueue}} and submits them to the thread pool. > If a task is non-blocking, this is not necessary; instead the task can be run on the runner's thread. This will reduce the number of thread created in the thread pool. > Investigate whether it is possible to mark tasks as blocking or non-blocking. Example: an {{AgeOutCache}} task is always non-blocking. A {{UNICAST3}} or {{NAKACK2}} retransmission task is (potentially) blocking if {{TCP}} is used as transport and non-blocking if for example {{UDP}} or {{TCP_NIO2}} are used. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6960) SFSB concurrent access timeout when the bean defines CDI producer for another SFSB

by Enrique González Martínez (JIRA)

[ https://issues.jboss.org/browse/WFLY-6960?page=com.atlassian.jira.plugin.... ] Enrique González Martínez edited comment on WFLY-6960 at 9/9/16 3:14 AM: ------------------------------------------------------------------------- The rest of the stacktrace... {code} Caused by: org.jboss.weld.exceptions.CreationException: WELD-000079: Could not instantiate a proxy for a session bean: Session bean [class org.github.jboss.test.weld.SFBean2 with qualifiers [@Any @Default]; local interfaces are [SFBean2] Proxy: class org.github.jboss.test.weld.SFBean2$Proxy$_$$_Weld$EnterpriseProxy$ at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.newInstance(SessionBeanProxyInstantiator.java:72) at org.jboss.weld.bean.SessionBean.create(SessionBean.java:149) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.get(ContextualInstanceStrategy.java:178) at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99) at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125) at org.github.jboss.test.weld.SFBean2$Proxy$_$$_WeldClientProxy.foo(Unknown Source) at org.github.jboss.test.weld.SFBean3.test(SFBean3.java:19) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:125) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64) at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) ... 85 more Caused by: java.lang.IllegalStateException: WFLYEE0042: No logró construir la instancia del componente at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163) at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:150) at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75) at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134) at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:145) at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75) at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88) at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:135) at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:75) at org.jboss.as.ejb3.cache.simple.SimpleCache.create(SimpleCache.java:118) at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238) at org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.<init>(StatefulSessionObjectReferenceImpl.java:70) at org.jboss.as.weld.services.bootstrap.WeldEjbServices.resolveEjb(WeldEjbServices.java:53) at org.jboss.weld.bean.SessionBean.createReference(SessionBean.java:230) at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:84) at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:64) at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.createEnterpriseTargetBeanInstance(SessionBeanProxyInstantiator.java:80) at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.newInstance(SessionBeanProxyInstantiator.java:61) ... 127 more Caused by: javax.ejb.ConcurrentAccessTimeoutException: WFLYEJB0228: Tiempo de expiración de acceso concurrente EJB 3.1 FR 4.3.14.1 en SFBean1 - no pudo obtener el bloqueo dentro de 5000 MILLISECONDS at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:86) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64) at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) at org.github.jboss.test.weld.SFBean1$$$view3.produceString(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:433) at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:128) at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) at org.github.jboss.test.weld.SFBean1$Proxy$_$$_Weld$EnterpriseProxy$.produceString(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) at org.jboss.weld.injection.producer.ProducerMethodProducer.produce(ProducerMethodProducer.java:100) at org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:161) at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:181) at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:70) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742) at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:842) at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92) at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:364) at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:375) at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:71) at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:73) at org.jboss.weld.injection.producer.ejb.SessionBeanInjectionTarget.inject(SessionBeanInjectionTarget.java:140) at org.jboss.as.weld.injection.WeldInjectionContext.inject(WeldInjectionContext.java:39) at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:51) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:263) at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.notSupported(LifecycleCMTTxInterceptor.java:92) at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.jpa.interceptor.SFSBPreCreateInterceptor.processInvocation(SFSBPreCreateInterceptor.java:47) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161) ... 144 more {code} was (Author: elguardian): The rest of the stacktrace... {code} Caused by: org.jboss.weld.exceptions.CreationException: WELD-000079: Could not instantiate a proxy for a session bean: Session bean [class org.github.jboss.test.weld.SFBean2 with qualifiers [@Any @Default]; local interfaces are [SFBean2] Proxy: class org.github.jboss.test.weld.SFBean2$Proxy$_$$_Weld$EnterpriseProxy$ at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.newInstance(SessionBeanProxyInstantiator.java:72) at org.jboss.weld.bean.SessionBean.create(SessionBean.java:149) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.get(ContextualInstanceStrategy.java:178) at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99) at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125) at org.github.jboss.test.weld.SFBean2$Proxy$_$$_WeldClientProxy.foo(Unknown Source) at org.github.jboss.test.weld.SFBean3.test(SFBean3.java:19) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:125) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64) at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) ... 85 more Caused by: java.lang.IllegalStateException: WFLYEE0042: No logró construir la instancia del componente at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163) at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:150) at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75) at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134) at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:145) at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75) at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88) at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:135) at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:75) at org.jboss.as.ejb3.cache.simple.SimpleCache.create(SimpleCache.java:118) at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238) at org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.<init>(StatefulSessionObjectReferenceImpl.java:70) at org.jboss.as.weld.services.bootstrap.WeldEjbServices.resolveEjb(WeldEjbServices.java:53) at org.jboss.weld.bean.SessionBean.createReference(SessionBean.java:230) at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:84) at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:64) at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.createEnterpriseTargetBeanInstance(SessionBeanProxyInstantiator.java:80) at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.newInstance(SessionBeanProxyInstantiator.java:61) ... 127 more {code} > SFSB concurrent access timeout when the bean defines CDI producer for another SFSB > ---------------------------------------------------------------------------------- > > Key: WFLY-6960 > URL: https://issues.jboss.org/browse/WFLY-6960 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final, 10.1.0.CR1 > Reporter: Tomas Remes > Assignee: Enrique González Martínez > > In the given scenario there are two calls to {{org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor#processInvocation}} in the same thread. In the first call the {{OwnableReentrantLock}} is obtained but it couldn't be reentered in the second call. This results to: > {noformat} > 14:54:21,184 ERROR [org.jboss.as.ejb3.invocation] (pool-2-thread-2) WFLYEJB0034: EJB Invocation failed on component SFBean1 for method public org.jboss.weld.tests.ejb.stateful.producer.Foo org.jboss.weld.tests.ejb.stateful.producer.SFBean1.produceString(): javax.ejb.ConcurrentAccessTimeoutException: WFLYEJB0228: EJB 3.1 FR 4.3.14.1 concurrent access timeout on SFBean1 - could not obtain lock within 5000 MILLISECONDS > at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:86) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) > at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64) > at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195) > at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean1$$$view5.produceString(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:436) > at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127) > at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) > at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean1$Proxy$_$$_Weld$EnterpriseProxy$.produceString(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.producer.ProducerMethodProducer.produce(ProducerMethodProducer.java:99) > at org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:161) > at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:181) > at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:70) > at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) > at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) > at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742) > at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:842) > at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92) > at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:378) > at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:389) > at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:71) > at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) > at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:73) > at org.jboss.weld.injection.producer.ejb.SessionBeanInjectionTarget.inject(SessionBeanInjectionTarget.java:140) > at org.jboss.as.weld.injection.WeldInjectionContext.inject(WeldInjectionContext.java:39) > at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:51) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:263) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.notSupported(CMTTxInterceptor.java:308) > at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:62) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.jpa.interceptor.SFSBPreCreateInterceptor.processInvocation(SFSBPreCreateInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:150) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75) > at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:145) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75) > at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:135) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:75) > at org.jboss.as.ejb3.cache.simple.SimpleCache.create(SimpleCache.java:118) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238) > at org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.<init>(StatefulSessionObjectReferenceImpl.java:70) > at org.jboss.as.weld.services.bootstrap.WeldEjbServices.resolveEjb(WeldEjbServices.java:53) > at org.jboss.weld.bean.SessionBean.createReference(SessionBean.java:230) > at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:83) > at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:63) > at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.createEnterpriseTargetBeanInstance(SessionBeanProxyInstantiator.java:80) > at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.newInstance(SessionBeanProxyInstantiator.java:61) > at org.jboss.weld.bean.SessionBean.create(SessionBean.java:149) > at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96) > at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) > at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.get(ContextualInstanceStrategy.java:178) > at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) > at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99) > at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean2$Proxy$_$$_WeldClientProxy.foo(Unknown Source) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean3.ping(SFBean3.java:19) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) > at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) > at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) > at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:125) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) > at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64) > at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195) > at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$$$view6.ping(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:436) > at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127) > at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) > at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$Proxy$_$$_Weld$EnterpriseProxy$.ping(Unknown Source) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$Proxy$_$$_WeldClientProxy.ping(Unknown Source) > at org.jboss.weld.tests.ejb.stateful.producer.ConcurrentAccessTest.test(ConcurrentAccessTest.java:31) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7029) RemoteFailoverTestCast#testGracefulShutdownConcurrentFailover fails with "ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations."

by Leo HE (JIRA)

[ https://issues.jboss.org/browse/WFLY-7029?page=com.atlassian.jira.plugin.... ] Leo HE commented on WFLY-7029: ------------------------------ Hi Radoslav, In mod_cluster 1.3.1.final, mod_cluster-manager status page reports wrong information. For details, can you please check following thread. https://developer.jboss.org/thread/271283?start=0&tstart=0 Thanks. Leo > RemoteFailoverTestCast#testGracefulShutdownConcurrentFailover fails with "ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations." > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7029 > URL: https://issues.jboss.org/browse/WFLY-7029 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Richard Achmatowicz > Labels: clean_shutdown > > https://ci.wildfly.org/viewLog.html?buildId=24851&tab=buildResultsDiv&bui... > {noformat} > 04:31:43,323 INFO [org.jboss.as.test.clustering.NodeUtil] (main) Stopping container=container-0, timeout=15 > 04:31:43,324 INFO [org.jboss.as.arquillian.container.controller.ClientWildFlyContainerController] (main) Manual stopping of a server instance with timeout=15 > &amp#27;[0m04:31:43,338 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0211: Suspending server with 15000 ms timeout. > &amp#27;[0m04:31:43,343 INFO [org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler] (Remoting "config-based-ejb-client-endpoint" task-10) Retrying invocation which failed on node node-0 with exception:: javax.ejb.NoSuchEJBException: No such EJB[appname=,modulename=remote-failover-test,distinctname=,beanname=SlowToDestroyStatefulIncrementorBean,viewclassname=org.jboss.as.test.clustering.cluster.ejb.remote.bean.Incrementor] > at org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler.processMessage(NoSuchEJBExceptionResponseHandler.java:64) > at org.jboss.ejb.client.remoting.ChannelAssociation.processResponse(ChannelAssociation.java:386) > at org.jboss.ejb.client.remoting.ChannelAssociation$ResponseReceiver.handleMessage(ChannelAssociation.java:498) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > &amp#27;[0m04:31:43,345 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' > &amp#27;[0m&amp#27;[0m04:31:43,430 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping > &amp#27;[0m&amp#27;[0m04:31:43,436 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 29) MODCLUSTER000002: Initiating mod_cluster shutdown > &amp#27;[0m&amp#27;[0m04:31:43,445 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 74) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:/ConnectionFactory > &amp#27;[0m&amp#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000080: Disconnecting JGroups channel hibernate > &amp#27;[0m&amp#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher for channel hibernate > &amp#27;[0m&amp#27;[0m04:31:43,463 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000080: Disconnecting JGroups channel server > &amp#27;[0m&amp#27;[0m04:31:43,464 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000082: Stopping the RpcDispatcher for channel server > &amp#27;[0m&amp#27;[0m04:31:43,471 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000029: Passivating all entries to disk > &amp#27;[0m&amp#27;[0m04:31:43,472 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000030: Passivated 2 entries in 0 milliseconds > &amp#27;[0m&amp#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel web > &amp#27;[0m&amp#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel web > &amp#27;[0m&amp#27;[0m04:31:43,502 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 29) WFLYCLINF0003: Stopped remote-failover-test.jar cache from ejb container > &amp#27;[0m&amp#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel testDbPersistence > &amp#27;[0m&amp#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel testDbPersistence > &amp#27;[0m&amp#27;[33m04:31:43,502 WARN [org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler] (thread-11,ee,node-0) ISPN000071: Caught exception when handling command LockControlCommand{cache=remote-failover-test.jar, keys=[UnknownSessionID [6951504948515351686656515249505365655750686851525048706670486766]], flags=[FORCE_WRITE_LOCK], unlock=false, gtx=GlobalTransaction:<node-1>:48:remote}: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > at org.jgroups.JChannel.up(JChannel.java:738) > at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120) > at org.jgroups.stack.Protocol.up(Protocol.java:380) > at org.jgroups.protocols.FORK.up(FORK.java:114) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070) > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD.up(FD.java:260) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) > at org.jgroups.protocols.Discovery.up(Discovery.java:296) > at org.jgroups.protocols.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52) > at java.lang.Thread.run(Thread.java:745) > &amp#27;[0m&amp#27;[0m04:31:43,517 INFO [org.wildfly.extension.messaging-activemq] (MSC service thread 1-2) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory > &amp#27;[0m&amp#27;[0m04:31:43,517 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > &amp#27;[0m&amp#27;[0m04:31:43,518 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA] > &amp#27;[0m&amp#27;[0m04:31:43,535 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-8) WFLYJCA0019: Stopped Driver service with driver-name = h2 > &amp#27;[0m&amp#27;[0m04:31:43,547 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 2) WFLYCLINF0003: Stopped client-mappings cache from ejb container > &amp#27;[0m04:31:43,565 INFO [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-14) EJBCLIENT000016: Channel Channel ID b007a55b (outbound) of Remoting connection 017c35ab to /0:0:0:0:0:0:0:1:8080 of endpoint "config-based-ejb-client-endpoint" <1c33eee> can no longer process messages > &amp#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000080: Disconnecting JGroups channel ejb > &amp#27;[0m&amp#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000082: Stopping the RpcDispatcher for channel ejb > &amp#27;[0m&amp#27;[0m04:31:43,575 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 35) AMQ151003: resource adaptor stopped > &amp#27;[0m&amp#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow AJP listener ajp suspending > &amp#27;[0m&amp#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [::1]:8009 > &amp#27;[0m&amp#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTPS listener https suspending > &amp#27;[0m&amp#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [::1]:8443 > &amp#27;[0m&amp#27;[31m04:31:43,585 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-11) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace > at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:795) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642) > at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602) > at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577) > at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) > at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962) > at org.infinispan.remoting.transport.jgroups.RspListFuture.futureDone(RspListFuture.java:31) > at org.jgroups.blocks.Request.checkCompletion(Request.java:152) > at org.jgroups.blocks.GroupRequest.receiveResponse(GroupRequest.java:116) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:427) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > at org.jgroups.JChannel.up(JChannel.java:738) > at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120) > at org.jgroups.stack.Protocol.up(Protocol.java:380) > at org.jgroups.protocols.FORK.up(FORK.java:114) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070) > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD.up(FD.java:260) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) > at org.jgroups.protocols.Discovery.up(Discovery.java:296) > at org.jgroups.protocols.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.infinispan.commons.CacheException: Problems invoking command. > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.exceptionHandlingCommand(BasePerCacheInboundInvocationHandler.java:106) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:101) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > ... 27 more > Caused by: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > ... 33 more > &amp#27;[0m&amp#27;[31m04:31:43,588 ERROR [org.jboss.as.ejb3.invocation] (default task-11) WFLYEJB0034: EJB Invocation failed on component SlowToDestroyStatefulIncrementorBean for method public abstract org.jboss.as.test.clustering.cluster.ejb.remote.bean.Result org.jboss.as.test.clustering.cluster.ejb.remote.bean.Incrementor.increment(): javax.ejb.EJBException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace > at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:328) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:201) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:263) > at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213) > at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76) > at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace > at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:795) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642) > at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602) > at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577) > at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) > at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962) > at org.infinispan.remoting.transport.jgroups.RspListFuture.futureDone(RspListFuture.java:31) > at org.jgroups.blocks.Request.checkCompletion(Request.java:152) > at org.jgroups.blocks.GroupRequest.receiveResponse(GroupRequest.java:116) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:427) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > at org.jgroups.JChannel.up(JChannel.java:738) > at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120) > at org.jgroups.stack.Protocol.up(Protocol.java:380) > at org.jgroups.protocols.FORK.up(FORK.java:114) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070) > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD.up(FD.java:260) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) > at org.jgroups.protocols.Discovery.up(Discovery.java:296) > at org.jgroups.protocols.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52) > ... 1 more > Caused by: org.infinispan.commons.CacheException: Problems invoking command. > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.exceptionHandlingCommand(BasePerCacheInboundInvocationHandler.java:106) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:101) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > ... 27 more > Caused by: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > ... 33 more > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7075) proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization)

by kostd kostd (JIRA)

[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ] kostd kostd commented on WFLY-7075: ----------------------------------- {quote} in order to alleviate the risk of integrating uncommitted changes into the persistence context in the event that the transaction is later rolled back. {quote} after tx rollback we fully drop associated XPC and begin new one on next request(Our XPC is conversation-scoped and we simply begin new conversation). Therefore no risk for us to integrate uncommited and "rolled back" changes. > proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization) > ------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7075 > URL: https://issues.jboss.org/browse/WFLY-7075 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.1.0.Final > Environment: *AppServer:* WildFly 10.1.0.Final > *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar > Reporter: Viacheslav Astapkovich > Assignee: Scott Marlow > Attachments: kitchensink-ear.rar > > > As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. > > *The obtained defect:* > A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. > The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) > *FIX:* > We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 > Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... > _Changes_: The method getSynchronizationType returns declared synchronization type. > *Consequences:* > We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. > Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. > It requires a declaration of synchronize persistence context. > We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. > However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. > *Our actions:* > We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). > This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. > _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... > *Example for reproduction:* > I modified quickstart example: [^kitchensink-ear.rar] > MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. > MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. > MemberRepository also perform join Transaction. > Questions from [~smarlow]: > - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. > We decided to use Container-managed EntityManager, because > - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components > - The container makes our job > We want to use the existing mechanism > *In Addition:* > Formally, this is out of JPA SPEC, but we have the following reasons: > - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". > But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. > ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) > - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7080) Creating ssl context with only required attribute cause NPE

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7080?page=com.atlassian.jira.plugin.... ] Martin Choma moved JBEAP-5938 to WFLY-7080: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7080 (was: JBEAP-5938) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: 11.0.0.Alpha1 (was: 7.1.0.DR4) > Creating ssl context with only required attribute cause NPE > ----------------------------------------------------------- > > Key: WFLY-7080 > URL: https://issues.jboss.org/browse/WFLY-7080 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=server2:add(protocols=[TLSv1_2]) > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {noformat} > In log of server there is exception: > {noformat} > 07:12:21,014 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.security.ssl-context.server2: org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NullPointerException > at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:275) > at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:45) > at org.wildfly.extension.elytron.SSLDefinitions$3.lambda$getValueSupplier$1(SSLDefinitions.java:411) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > 07:12:21,016 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 6) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("server-ssl-context" => "server2") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > {noformat} > Looking into org.wildfly.security.ssl.SSLContextBuilder, one question come to my mind. Is there still possibility for user to configure equivalent of SSLContext.getInstance("Default")? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1279) [GSS] compilation of spreadsheet fails with specific condition

by Hiroko Miura (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1279?page=com.atlassian.jira.plugi... ] Hiroko Miura updated DROOLS-1279: --------------------------------- Description: Reproducer is attached.with problematic spredsheet named SampleNG.xml. Compilation of this fails with the following error. java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=dtables/SampleNG.xls, line=8, column=0 text=Unable to Analyse Expression checktest == AAA: [Error: unable to resolve method using strict-mode: com.sample.DecisionTableTest$Message.AAA()] [Near : {... checktest == AAA ....}] because the following DRL is generated. rule "HelloWorld_12" when m:Message(checktest in (AAA), status == "Message.HELLO") ... i.e. double quotation of value ("AAA") specified in the cell is removed. If D column does not exist like Sample.xml(also included in reproducer) or rule template of D column is modified like "status == $param " (see SampleOK.xml), this does not happen. was: Reproducer is attached.with problematic spredsheet named SampleNG.xml. Compilation of this fails with the following error. java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=dtables/SampleNG.xls, line=8, column=0 text=Unable to Analyse Expression checktest == AAA: [Error: unable to resolve method using strict-mode: com.sample.DecisionTableTest$Message.AAA()] [Near : {... checktest == AAA ....}] because the following DRL is generated. rule "HelloWorld_12" when m:Message(checktest in(AAA), (checktest != "dummy") == "false") ... i.e. double quotation of value ("AAA") specified in the cell is removed. If D column does not exist like Sample.xml(also included in reproducer) or D column is modified like SampleOK.xml, this does not happen. Attachment: reproducer.zip > [GSS] compilation of spreadsheet fails with specific condition > -------------------------------------------------------------- > > Key: DROOLS-1279 > URL: https://issues.jboss.org/browse/DROOLS-1279 > Project: Drools > Issue Type: Bug > Components: build, decision tables > Affects Versions: 6.4.0.Final > Reporter: Hiroko Miura > Assignee: Petr Široký > Labels: support > Fix For: 6.5.0.Final > > Attachments: reproducer.zip > > > Reproducer is attached.with problematic spredsheet named SampleNG.xml. > Compilation of this fails with the following error. > java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=dtables/SampleNG.xls, line=8, column=0 > text=Unable to Analyse Expression checktest == AAA: > [Error: unable to resolve method using strict-mode: com.sample.DecisionTableTest$Message.AAA()] > [Near : {... checktest == AAA ....}] > because the following DRL is generated. > rule "HelloWorld_12" > when > m:Message(checktest in (AAA), status == "Message.HELLO") > ... > i.e. double quotation of value ("AAA") specified in the cell is removed. > > If D column does not exist like Sample.xml(also included in reproducer) or rule template of D column is modified like "status == $param " (see SampleOK.xml), this does not happen. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1279) [GSS] compilation of spreadsheet fails with specific condition

by Hiroko Miura (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1279?page=com.atlassian.jira.plugi... ] Hiroko Miura updated DROOLS-1279: --------------------------------- Attachment: (was: repoduser.zip) > [GSS] compilation of spreadsheet fails with specific condition > -------------------------------------------------------------- > > Key: DROOLS-1279 > URL: https://issues.jboss.org/browse/DROOLS-1279 > Project: Drools > Issue Type: Bug > Components: build, decision tables > Affects Versions: 6.4.0.Final > Reporter: Hiroko Miura > Assignee: Petr Široký > Labels: support > Fix For: 6.5.0.Final > > > Reproducer is attached.with problematic spredsheet named SampleNG.xml. > Compilation of this fails with the following error. > java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=dtables/SampleNG.xls, line=8, column=0 > text=Unable to Analyse Expression checktest == AAA: > [Error: unable to resolve method using strict-mode: com.sample.DecisionTableTest$Message.AAA()] > [Near : {... checktest == AAA ....}] > because the following DRL is generated. > rule "HelloWorld_12" > when > m:Message(checktest in(AAA), (checktest != "dummy") == "false") > ... > i.e. double quotation of value ("AAA") specified in the cell is removed. > > If D column does not exist like Sample.xml(also included in reproducer) or D column is modified like SampleOK.xml, this does not happen. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6890) Add Weld SPI dependency to the transactions module

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/WFLY-6890?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on WFLY-6890: ------------------------------------- [~gytis] - you need some more detail here to explain why this change is necessary... > Add Weld SPI dependency to the transactions module > -------------------------------------------------- > > Key: WFLY-6890 > URL: https://issues.jboss.org/browse/WFLY-6890 > Project: WildFly > Issue Type: Task > Components: Transactions > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 10.2.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7079) Further optimize size of fine session attribute names cache entry

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-7079: ---------------------------------- Summary: Further optimize size of fine session attribute names cache entry Key: WFLY-7079 URL: https://issues.jboss.org/browse/WFLY-7079 Project: WildFly Issue Type: Enhancement Components: Clustering Affects Versions: 10.1.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 11.0.0.Alpha1 1. Marshalling of AtomicInteger writes an unnecessary class descriptor, as no externalizer exists 2. Attribute IDs current require 4 bytes, but can be written using IndexExternalizer.VARIABLE -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7078) Further optimize size of fine session attribute names cache entry

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-7078?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-7078: ------------------------------- Description: 1. Marshalling of AtomicInteger writes an unnecessary class descriptor, as no externalizer exists 2. Attribute IDs current require 4 bytes, but can be written using IndexExternalizer.VARIABLE was: 1. Marshalling of AtomicInteger writes an unnecessary class descriptor 2. Attribute IDs current require 4 bytes, but can be written using IndexExternalizer.VARIABLE > Further optimize size of fine session attribute names cache entry > ----------------------------------------------------------------- > > Key: WFLY-7078 > URL: https://issues.jboss.org/browse/WFLY-7078 > Project: WildFly > Issue Type: Enhancement > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Alpha1 > > > 1. Marshalling of AtomicInteger writes an unnecessary class descriptor, as no externalizer exists > 2. Attribute IDs current require 4 bytes, but can be written using IndexExternalizer.VARIABLE -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7078) Further optimize size of fine session attribute names cache entry

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-7078: ---------------------------------- Summary: Further optimize size of fine session attribute names cache entry Key: WFLY-7078 URL: https://issues.jboss.org/browse/WFLY-7078 Project: WildFly Issue Type: Enhancement Components: Clustering Affects Versions: 10.1.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 11.0.0.Alpha1 1. Marshalling of AtomicInteger writes an unnecessary class descriptor 2. Attribute IDs current require 4 bytes, but can be written using IndexExternalizer.VARIABLE -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-263) ClassPool cannot read generated classes

by Shigeru Chiba (JIRA)

[ https://issues.jboss.org/browse/JASSIST-263?page=com.atlassian.jira.plugi... ] Shigeru Chiba edited comment on JASSIST-263 at 9/8/16 3:04 PM: --------------------------------------------------------------- That is right behavior. First of all, BuildingClassLoader does not keep a given class file by defineClass(). So returning no URL is correct behavior. To address this, ClassPool should keep it for further accesses but your implementation creates a new instance of ClassPool, which does not remember a class file generated before, whenever {{findClass}} is invoked. A quick fix is to make {{pool}} be a field in {{BuildClassLoader}}. was (Author: chiba): That is right behavior. First of all, BuildingClassLoader does not keep a given class file by defineClass(). So returning no URL is correct behavior. To address this, ClassPool should keep it for further accesses but your implementation creates a new instance of ClassPool, which does not remember a class file generated before. A quick fix is to make {{pool}} be a field in {{BuildClassLoader}}. > ClassPool cannot read generated classes > --------------------------------------- > > Key: JASSIST-263 > URL: https://issues.jboss.org/browse/JASSIST-263 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.20.0-GA > Reporter: Paul Pogonyshev > Assignee: Shigeru Chiba > Attachments: JavassistBug.java > > > ClassPool.get() cannot retrieve classes that are in turn generated at runtime. For example, if I try to define at runtime two classes, one of which extends another, the base will not be found, even though it can be retrieved just fine from my class loader. See the attached example. > As far as I could trace it, the issue comes from ClassPoolTail.find() returning a null URL for the class. This is understandable, since class definition doesn't exist as a file --- it is generated at runtime. However, ClassPool.get() should still succeed for classes that have no URL, yet can be found through its ClassLoader. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-263) ClassPool cannot read generated classes

by Shigeru Chiba (JIRA)

[ https://issues.jboss.org/browse/JASSIST-263?page=com.atlassian.jira.plugi... ] Shigeru Chiba commented on JASSIST-263: --------------------------------------- That is right behavior. First of all, BuildingClassLoader does not keep a given class file by defineClass(). So returning no URL is correct behavior. To address this, ClassPool should keep it for further accesses but your implementation creates a new instance of ClassPool, which does not remember a class file generated before. A quick fix is to make {{pool}} be a field in {{BuildClassLoader}}. > ClassPool cannot read generated classes > --------------------------------------- > > Key: JASSIST-263 > URL: https://issues.jboss.org/browse/JASSIST-263 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.20.0-GA > Reporter: Paul Pogonyshev > Assignee: Shigeru Chiba > Attachments: JavassistBug.java > > > ClassPool.get() cannot retrieve classes that are in turn generated at runtime. For example, if I try to define at runtime two classes, one of which extends another, the base will not be found, even though it can be retrieved just fine from my class loader. See the attached example. > As far as I could trace it, the issue comes from ClassPoolTail.find() returning a null URL for the class. This is understandable, since class definition doesn't exist as a file --- it is generated at runtime. However, ClassPool.get() should still succeed for classes that have no URL, yet can be found through its ClassLoader. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7077) logging profile with apache commons does not work

by Brad Maxwell (JIRA)

[ https://issues.jboss.org/browse/WFLY-7077?page=com.atlassian.jira.plugin.... ] Brad Maxwell moved JBEAP-5935 to WFLY-7077: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7077 (was: JBEAP-5935) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Logging (was: Logging) Target Release: (was: 7.1.0.GA) > logging profile with apache commons does not work > -------------------------------------------------- > > Key: WFLY-7077 > URL: https://issues.jboss.org/browse/WFLY-7077 > Project: WildFly > Issue Type: Bug > Components: Logging > Reporter: Brad Maxwell > Assignee: James Perkins > > All entry logs go to the log file of the first accessed application logging profile. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7075) proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization)

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-7075: ------------------------------------ >From JPA 2.1 SPEC section 7.6.1: {quote} If an extended persistence context of type SynchronizationType.UNSYNCHRONIZED has not been joined to the current JTA transaction, rollback of the JTA transaction will have no effect upon the persistence context. In general, it is recommended that a non-JTA datasource be specified for use by the persistence provider for a persistence context of type SynchronizationType.UNSYNCHRONIZED that has not been joined to a JTA transaction in order to alleviate the risk of integrating uncommitted changes into the persistence context in the event that the transaction is later rolled back. {quote} > proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization) > ------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7075 > URL: https://issues.jboss.org/browse/WFLY-7075 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.1.0.Final > Environment: *AppServer:* WildFly 10.1.0.Final > *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar > Reporter: Viacheslav Astapkovich > Assignee: Scott Marlow > Attachments: kitchensink-ear.rar > > > As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. > > *The obtained defect:* > A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. > The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) > *FIX:* > We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 > Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... > _Changes_: The method getSynchronizationType returns declared synchronization type. > *Consequences:* > We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. > Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. > It requires a declaration of synchronize persistence context. > We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. > However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. > *Our actions:* > We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). > This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. > _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... > *Example for reproduction:* > I modified quickstart example: [^kitchensink-ear.rar] > MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. > MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. > MemberRepository also perform join Transaction. > Questions from [~smarlow]: > - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. > We decided to use Container-managed EntityManager, because > - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components > - The container makes our job > We want to use the existing mechanism > *In Addition:* > Formally, this is out of JPA SPEC, but we have the following reasons: > - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". > But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. > ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) > - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1774) Use core-service=capability-registry to provide tab completion suggestions for model reference attributes

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-1774: ---------------------------------------- Summary: Use core-service=capability-registry to provide tab completion suggestions for model reference attributes Key: WFCORE-1774 URL: https://issues.jboss.org/browse/WFCORE-1774 Project: WildFly Core Issue Type: Enhancement Components: CLI Reporter: Brian Stansberry Assignee: Alexey Loubyansky A "model reference" attribute is one whose value points to some other aspect of the model, e.g. "socket-binding" => "http". With the capability and requirement function we are rolling out in the server[1] we have the ability for clients to understand what values are valid for the reference. This should be used in CLI tab completion. [~claudio4j] has utitlized this for UI suggestions in HAL so he or Harald can be a resource for the exact algorithm that has worked best. Here's the basics though: 1) This applies to attributes or operation params where the read-resource-description or read-operation-description includes a "capability-reference" field. The value of the field shows the static portion of the capability name. For example an attribute that's used for a socket binding name would show "org.wildfly.network.socket-binding". 2) The [/host=*]/core-service=capability resource shows information about what capabilities are available on the system. This includes 2 attributes "capabilities" and "possible-capabilities". The former shows the specific capabilities that are actually present; i.e. the resources that provide the capability are part of the configuration. The latter shows capabilities that could be present, given the installed extensions, if the relevant resources were added. That resource includes two operations "get-capability" and "get-provider-points" that can show more details about what resources provide a capability: {code} [standalone@embedded core-service=capability-registry] :get-provider-points(name=org.wildfly.network.socket-binding) { "outcome" => "success", "result" => ["/socket-binding-group=*/socket-binding=*"] } {code} That tells you that capabilities of type org.wildfly.network.socket-binding are registered by resources using address pattern /socket-binding-group=*/socket-binding=* 3) With that information the CLI can see what resources actually exist on the system and use the value portion of the final element of their address as the suggestion list for tab completion. HAL may be doing something slightly different from what I describe; they have concrete experience. It may be possible for the API exposed by core-service=capability-registry to be enhanced to make this easier. If you want something, please don't hesitate to ask Tomaz Cerar or myself. [1] https://docs.jboss.org/author/display/WFLY/Working+with+WildFly+Capabilities -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1774) Use core-service=capability-registry to provide tab completion suggestions for model reference attributes

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1774?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-1774: ---------------------------------------- Assignee: Jean-Francois Denise (was: Alexey Loubyansky) > Use core-service=capability-registry to provide tab completion suggestions for model reference attributes > --------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1774 > URL: https://issues.jboss.org/browse/WFCORE-1774 > Project: WildFly Core > Issue Type: Enhancement > Components: CLI > Reporter: Brian Stansberry > Assignee: Jean-Francois Denise > > A "model reference" attribute is one whose value points to some other aspect of the model, e.g. "socket-binding" => "http". With the capability and requirement function we are rolling out in the server[1] we have the ability for clients to understand what values are valid for the reference. This should be used in CLI tab completion. > [~claudio4j] has utitlized this for UI suggestions in HAL so he or Harald can be a resource for the exact algorithm that has worked best. Here's the basics though: > 1) This applies to attributes or operation params where the read-resource-description or read-operation-description includes a "capability-reference" field. The value of the field shows the static portion of the capability name. For example an attribute that's used for a socket binding name would show "org.wildfly.network.socket-binding". > 2) The [/host=*]/core-service=capability resource shows information about what capabilities are available on the system. This includes 2 attributes "capabilities" and "possible-capabilities". The former shows the specific capabilities that are actually present; i.e. the resources that provide the capability are part of the configuration. The latter shows capabilities that could be present, given the installed extensions, if the relevant resources were added. > That resource includes two operations "get-capability" and "get-provider-points" that can show more details about what resources provide a capability: > {code} > [standalone@embedded core-service=capability-registry] :get-provider-points(name=org.wildfly.network.socket-binding) > { > "outcome" => "success", > "result" => ["/socket-binding-group=*/socket-binding=*"] > } > {code} > That tells you that capabilities of type org.wildfly.network.socket-binding are registered by resources using address pattern /socket-binding-group=*/socket-binding=* > 3) With that information the CLI can see what resources actually exist on the system and use the value portion of the final element of their address as the suggestion list for tab completion. > HAL may be doing something slightly different from what I describe; they have concrete experience. > It may be possible for the API exposed by core-service=capability-registry to be enhanced to make this easier. If you want something, please don't hesitate to ask Tomaz Cerar or myself. > [1] https://docs.jboss.org/author/display/WFLY/Working+with+WildFly+Capabilities -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6127) Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context

by Viacheslav Astapkovich (JIRA)

[ https://issues.jboss.org/browse/WFLY-6127?page=com.atlassian.jira.plugin.... ] Viacheslav Astapkovich commented on WFLY-6127: ---------------------------------------------- "We have WildFly 10.1.0.Final contains the fix for the reported issue.": Unfortunately, in *wildfly-jpa-10.1.0.Final* we still always get SYNCHRONIZE when get Synchronization Type of _ExtendedEntityManager_. Even if we have UNSYNCHRONIZED EntityManager. *Example for reproduce:* https://issues.jboss.org/secure/attachment/12409264/12409264_kitchensink-... from WFLY-7075 (modified quickstart example). +MemberRepository+ create UNSYNCHRONIZE EntityManager, but we still get SYNCHRONIZED (printed as sysout). > Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context > ---------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-6127 > URL: https://issues.jboss.org/browse/WFLY-6127 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 9.0.2.Final, 10.0.0.Final > Reporter: Mazen Mahmoud > Assignee: Scott Marlow > Priority: Blocker > Fix For: 10.1.0.CR1, 10.1.0.Final > > Attachments: server-log.txt > > > SPEC: If a component is called and the JTA transaction is propagated into that component: > If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED > associated with the JTA transaction and the target component specifies a persistence context of type SynchronizationType.SYNCHRONIZED, the IllegalStateException is thrown by the container > We have a stateful session bean (SFB1) / PC: TRANSACTION/UNSYNCHRONIZED) > stateful session bean (SFB2) / PC: TRANSACTION/SYNCHRONIZED) > SFB1 method M1 (REQUIRED) calls SFB2 Method 2 (REQUIRED): > PC is propagated from SFB1 to SFB2 without any exception. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7075) proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization)

by kostd kostd (JIRA)

[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ] kostd kostd commented on WFLY-7075: ----------------------------------- [~smarlow] in JPA 2.2(if this will ever be). we like to read: {quote} If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED associated *and not yet joined* with the JTA transaction and the target component specifies a persistence context of type SynchronizationType.SYNCHRONIZED, the IllegalStateException is thrown by the container. {quote} Great thank for your time and advice :) > proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization) > ------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7075 > URL: https://issues.jboss.org/browse/WFLY-7075 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.1.0.Final > Environment: *AppServer:* WildFly 10.1.0.Final > *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar > Reporter: Viacheslav Astapkovich > Assignee: Scott Marlow > Attachments: kitchensink-ear.rar > > > As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. > > *The obtained defect:* > A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. > The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) > *FIX:* > We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 > Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... > _Changes_: The method getSynchronizationType returns declared synchronization type. > *Consequences:* > We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. > Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. > It requires a declaration of synchronize persistence context. > We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. > However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. > *Our actions:* > We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). > This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. > _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... > *Example for reproduction:* > I modified quickstart example: [^kitchensink-ear.rar] > MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. > MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. > MemberRepository also perform join Transaction. > Questions from [~smarlow]: > - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. > We decided to use Container-managed EntityManager, because > - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components > - The container makes our job > We want to use the existing mechanism > *In Addition:* > Formally, this is out of JPA SPEC, but we have the following reasons: > - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". > But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. > ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) > - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7076) Elytron introduces SSL/TLS protocol constraints

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7076?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-7076: ---------------------------------------- [~honza889] The subsystem is using the underscore as I think we are currently using the enum for validation, we need to allow the standard names to use. Also need to double check the level of validation we need, we can hard code a list of accepted Strings but need to see how that compares with our current filter. > Elytron introduces SSL/TLS protocol constraints > ----------------------------------------------- > > Key: WFLY-7076 > URL: https://issues.jboss.org/browse/WFLY-7076 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > > {noformat} > "protocols" => { > "type" => LIST, > "description" => "The enabled protocols.", > "expressions-allowed" => true, > "nillable" => false, > "allowed" => [ > "SSLv2", > "SSLv3", > "TLSv1", > "TLSv1_1", > "TLSv1_2", > "TLSv1_3" > ], > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {noformat} > Why elytron on this place is going to validate user input and map standard java values [1] into proprietary values? > Whereas on other similar places (KeyManager algorithm, TrustManager algorithm, Keystore types) it leaves up to user to set proper value. > IMO, with such mapping another place, where bugs can raise was introduced. EAP will be here always one step back compared to java. > Note, IBM java already today defines little bit different protocols set [2] > I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place. > [1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardN... > [2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7076) Elytron introduces SSL/TLS protocol constraints

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7076?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-7076: -------------------------------------- Assignee: Jan Kalina (was: Darran Lofthouse) > Elytron introduces SSL/TLS protocol constraints > ----------------------------------------------- > > Key: WFLY-7076 > URL: https://issues.jboss.org/browse/WFLY-7076 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > > {noformat} > "protocols" => { > "type" => LIST, > "description" => "The enabled protocols.", > "expressions-allowed" => true, > "nillable" => false, > "allowed" => [ > "SSLv2", > "SSLv3", > "TLSv1", > "TLSv1_1", > "TLSv1_2", > "TLSv1_3" > ], > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {noformat} > Why elytron on this place is going to validate user input and map standard java values [1] into proprietary values? > Whereas on other similar places (KeyManager algorithm, TrustManager algorithm, Keystore types) it leaves up to user to set proper value. > IMO, with such mapping another place, where bugs can raise was introduced. EAP will be here always one step back compared to java. > Note, IBM java already today defines little bit different protocols set [2] > I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place. > [1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardN... > [2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1127) SocketBindingManagerImpl$UnnamedRegistryImpl is overly picky about unbound sockets

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1127?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1127: ------------------------------------------ [~pferraro] ^^^ > SocketBindingManagerImpl$UnnamedRegistryImpl is overly picky about unbound sockets > ---------------------------------------------------------------------------------- > > Key: WFCORE-1127 > URL: https://issues.jboss.org/browse/WFCORE-1127 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.1.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 2.0.2.Final > > > A failure like this isn't necessary: > {code} > 08:02:23,475 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.jgroups.channel.ee.connector: org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee.connector: java.lang.IllegalStateException > at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:96) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.IllegalStateException > at org.jboss.as.network.SocketBindingManagerImpl$UnnamedRegistryImpl.unregisterBinding(SocketBindingManagerImpl.java:501) > at org.jboss.as.network.ManagedDatagramSocketBinding.close(ManagedDatagramSocketBinding.java:73) > at org.jboss.as.clustering.jgroups.ManagedSocketFactory.close(ManagedSocketFactory.java:148) > at org.jgroups.protocols.UDP.closeUnicastSocket(UDP.java:577) > at org.jgroups.protocols.UDP.destroySockets(UDP.java:429) > at org.jgroups.protocols.UDP.start(UDP.java:274) > at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965) > at org.jgroups.JChannel.startStack(JChannel.java:890) > at org.jgroups.JChannel._preConnect(JChannel.java:553) > at org.jgroups.JChannel.connect(JChannel.java:288) > at org.jgroups.JChannel.connect(JChannel.java:279) > at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:94) > ... 5 more > {code} > If there's no socket address, it should just move on. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1773) SynchServerOperation pulls down more config than necessary during slave reconnection to DC

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1773?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1773: ------------------------------------------ [~luck3y] Another thing to look at (also probably a separate issue) is why in that diff you showed me the original version of the cached-remote domain config had empty profile elements: {code} <profile name="full"/> <profile name="full-ha"/> {code} A slave should either have the profile or ignore it. It shouldn't have it but in an incomplete form. > SynchServerOperation pulls down more config than necessary during slave reconnection to DC > ------------------------------------------------------------------------------------------ > > Key: WFCORE-1773 > URL: https://issues.jboss.org/browse/WFCORE-1773 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Ken Wills > Assignee: Ken Wills > > When a slave disconnects and reconnects to the DC for the first time, a complete copy of the domain config is sent. If the slave is using the default ignore-unused-configuration semantics, it still adds all of the additional configuration. > An additional side issue is the full-ha subsystems are being added in reverse order. > More detail in comments here https://github.com/wildfly/wildfly-core/pull/1754. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1773) SynchServerOperation pulls down more config than necessary during slave reconnection to DC

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1773?page=com.atlassian.jira.plugi... ] Ken Wills commented on WFCORE-1773: ----------------------------------- [~simkam] Martin, FYI for you on this, as I know you've been working on testing in this area. > SynchServerOperation pulls down more config than necessary during slave reconnection to DC > ------------------------------------------------------------------------------------------ > > Key: WFCORE-1773 > URL: https://issues.jboss.org/browse/WFCORE-1773 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Ken Wills > Assignee: Ken Wills > > When a slave disconnects and reconnects to the DC for the first time, a complete copy of the domain config is sent. If the slave is using the default ignore-unused-configuration semantics, it still adds all of the additional configuration. > An additional side issue is the full-ha subsystems are being added in reverse order. > More detail in comments here https://github.com/wildfly/wildfly-core/pull/1754. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1773) SynchServerOperation pulls down more config than necessary during slave reconnection to DC

by Ken Wills (JIRA)

Ken Wills created WFCORE-1773: --------------------------------- Summary: SynchServerOperation pulls down more config than necessary during slave reconnection to DC Key: WFCORE-1773 URL: https://issues.jboss.org/browse/WFCORE-1773 Project: WildFly Core Issue Type: Enhancement Components: Domain Management Reporter: Ken Wills Assignee: Ken Wills When a slave disconnects and reconnects to the DC for the first time, a complete copy of the domain config is sent. If the slave is using the default ignore-unused-configuration semantics, it still adds all of the additional configuration. An additional side issue is the full-ha subsystems are being added in reverse order. More detail in comments here https://github.com/wildfly/wildfly-core/pull/1754. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7075) proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization)

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-7075: ------------------------------------ Regarding the lack of feedback on the JPA_SPEC-6 issue, do you disagree with the current JPA 2.1 spec wording in 7.6.4.1: {quote} If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED associated with the JTA transaction and the target component specifies a persistence context of type SynchronizationType.SYNCHRONIZED, the IllegalStateException is thrown by the container. {quote} >From the JPA_SPEC-6 issue, the description is: {quote} Whether or not to propagate a persistence context of type SynchronizationType.UNSYNCHRONIZED to a component with persistence context of type SynchronizationType.SYNCHRONIZED if the former has been joined to the JTA transaction. {quote} IMO, I think it could be useful for you to also express your opinion about JPA_SPEC-6 on the users(a)jpa-spec.java.net mailing list. You could link to the WFLY-7075 jira as well, in that discussion. Even if your feedback about JPA_SPEC-6 is late, it is always useful to discuss why a change could help you, so that the change might be considered in a future JPA spec version. > proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization) > ------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7075 > URL: https://issues.jboss.org/browse/WFLY-7075 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.1.0.Final > Environment: *AppServer:* WildFly 10.1.0.Final > *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar > Reporter: Viacheslav Astapkovich > Assignee: Scott Marlow > Attachments: kitchensink-ear.rar > > > As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. > > *The obtained defect:* > A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. > The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) > *FIX:* > We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 > Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... > _Changes_: The method getSynchronizationType returns declared synchronization type. > *Consequences:* > We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. > Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. > It requires a declaration of synchronize persistence context. > We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. > However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. > *Our actions:* > We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). > This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. > _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... > *Example for reproduction:* > I modified quickstart example: [^kitchensink-ear.rar] > MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. > MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. > MemberRepository also perform join Transaction. > Questions from [~smarlow]: > - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. > We decided to use Container-managed EntityManager, because > - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components > - The container makes our job > We want to use the existing mechanism > *In Addition:* > Formally, this is out of JPA SPEC, but we have the following reasons: > - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". > But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. > ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) > - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7075) proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization)

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ] Scott Marlow updated WFLY-7075: ------------------------------- Security: (was: Red Hat Internal) > proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization) > ------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7075 > URL: https://issues.jboss.org/browse/WFLY-7075 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.1.0.Final > Environment: *AppServer:* WildFly 10.1.0.Final > *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar > Reporter: Viacheslav Astapkovich > Assignee: Scott Marlow > Attachments: kitchensink-ear.rar > > > As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. > > *The obtained defect:* > A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. > The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) > *FIX:* > We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 > Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... > _Changes_: The method getSynchronizationType returns declared synchronization type. > *Consequences:* > We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. > Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. > It requires a declaration of synchronize persistence context. > We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. > However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. > *Our actions:* > We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). > This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. > _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... > *Example for reproduction:* > I modified quickstart example: [^kitchensink-ear.rar] > MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. > MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. > MemberRepository also perform join Transaction. > Questions from [~smarlow]: > - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. > We decided to use Container-managed EntityManager, because > - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components > - The container makes our job > We want to use the existing mechanism > *In Addition:* > Formally, this is out of JPA SPEC, but we have the following reasons: > - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". > But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. > ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) > - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7076) Elytron introduces SSL/TLS protocol constraints

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7076?page=com.atlassian.jira.plugin.... ] Martin Choma moved JBEAP-5932 to WFLY-7076: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7076 (was: JBEAP-5932) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: 11.0.0.Alpha1 (was: 7.1.0.DR4) > Elytron introduces SSL/TLS protocol constraints > ----------------------------------------------- > > Key: WFLY-7076 > URL: https://issues.jboss.org/browse/WFLY-7076 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > > {noformat} > "protocols" => { > "type" => LIST, > "description" => "The enabled protocols.", > "expressions-allowed" => true, > "nillable" => false, > "allowed" => [ > "SSLv2", > "SSLv3", > "TLSv1", > "TLSv1_1", > "TLSv1_2", > "TLSv1_3" > ], > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {noformat} > Why elytron on this place is going to validate user input and map standard java values [1] into proprietary values? > Whereas on other similar places (KeyManager algorithm, TrustManager algorithm, Keystore types) it leaves up to user to set proper value. > IMO, with such mapping another place, where bugs can raise was introduced. EAP will be here always one step back compared to java. > Note, IBM java already today defines little bit different protocols set [2] > I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place. > [1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardN... > [2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6127) Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context

by Viacheslav Astapkovich (JIRA)

[ https://issues.jboss.org/browse/WFLY-6127?page=com.atlassian.jira.plugin.... ] Viacheslav Astapkovich commented on WFLY-6127: ---------------------------------------------- Registered as: WFLY-7075 > Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context > ---------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-6127 > URL: https://issues.jboss.org/browse/WFLY-6127 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 9.0.2.Final, 10.0.0.Final > Reporter: Mazen Mahmoud > Assignee: Scott Marlow > Priority: Blocker > Fix For: 10.1.0.CR1, 10.1.0.Final > > Attachments: server-log.txt > > > SPEC: If a component is called and the JTA transaction is propagated into that component: > If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED > associated with the JTA transaction and the target component specifies a persistence context of type SynchronizationType.SYNCHRONIZED, the IllegalStateException is thrown by the container > We have a stateful session bean (SFB1) / PC: TRANSACTION/UNSYNCHRONIZED) > stateful session bean (SFB2) / PC: TRANSACTION/SYNCHRONIZED) > SFB1 method M1 (REQUIRED) calls SFB2 Method 2 (REQUIRED): > PC is propagated from SFB1 to SFB2 without any exception. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1127) SocketBindingManagerImpl$UnnamedRegistryImpl is overly picky about unbound sockets

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1127?page=com.atlassian.jira.plugi... ] Dan Berindei commented on WFCORE-1127: -------------------------------------- This is going to be a problem again with JGroups 4.0. JGroups always creates the socket first, and binds it later. {{ManagedSocketFactoryTest}} explicitly tests that unbound sockets are registered with the (mocked) {{SocketBindingManager.UnnamedBindingRegistry}}. JGroups prior to version 4.0 "fixes" this by always replacing the {{ManagedSocketFactory}} set by {{JChannelFactory.init()}} with its own {{DefaultSocketFactory}} in {{JChannel.startStack()}}. But JGroups 4.0 actually tries to use the {{SocketFactory}} injected by the JGroups subsystem, and fails with an {{IllegalStateException}}. > SocketBindingManagerImpl$UnnamedRegistryImpl is overly picky about unbound sockets > ---------------------------------------------------------------------------------- > > Key: WFCORE-1127 > URL: https://issues.jboss.org/browse/WFCORE-1127 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.1.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 2.0.2.Final > > > A failure like this isn't necessary: > {code} > 08:02:23,475 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.jgroups.channel.ee.connector: org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee.connector: java.lang.IllegalStateException > at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:96) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.IllegalStateException > at org.jboss.as.network.SocketBindingManagerImpl$UnnamedRegistryImpl.unregisterBinding(SocketBindingManagerImpl.java:501) > at org.jboss.as.network.ManagedDatagramSocketBinding.close(ManagedDatagramSocketBinding.java:73) > at org.jboss.as.clustering.jgroups.ManagedSocketFactory.close(ManagedSocketFactory.java:148) > at org.jgroups.protocols.UDP.closeUnicastSocket(UDP.java:577) > at org.jgroups.protocols.UDP.destroySockets(UDP.java:429) > at org.jgroups.protocols.UDP.start(UDP.java:274) > at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965) > at org.jgroups.JChannel.startStack(JChannel.java:890) > at org.jgroups.JChannel._preConnect(JChannel.java:553) > at org.jgroups.JChannel.connect(JChannel.java:288) > at org.jgroups.JChannel.connect(JChannel.java:279) > at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:94) > ... 5 more > {code} > If there's no socket address, it should just move on. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1772) /core-service=capability-registry:get-provider-points only returning a single provider point.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1772?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-1772: ------------------------------------- Labels: affects_elytron (was: ) > /core-service=capability-registry:get-provider-points only returning a single provider point. > --------------------------------------------------------------------------------------------- > > Key: WFCORE-1772 > URL: https://issues.jboss.org/browse/WFCORE-1772 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Environment: This was reproduced using wildfly/master running the standalone-elytron.xml configuration. > Reporter: Darran Lofthouse > Assignee: Tomaz Cerar > Labels: affects_elytron > Fix For: 3.0.0.Alpha8 > > > Running the following: - > {noformat} > [standalone@localhost:9990 /] /core-service=capability-registry:get-provider-points(name=org.wildfly.security.security-realm) > { > "outcome" => "success", > "result" => ["/subsystem=elytron/filesystem-realm=*"] > } > {noformat} > However there are other resources that can provide this capability e.g. > {noformat} > [standalone@localhost:9990 /] ./subsystem=elytron/properties-realm=*:read-resource-description > { > "outcome" => "success", > "result" => [{ > "address" => [ > ("subsystem" => "elytron"), > ("properties-realm" => "*") > ], > "outcome" => "success", > "result" => { > "description" => "A security realm definition backed by properties files.", > "capabilities" => [{ > "name" => "org.wildfly.security.security-realm", > "dynamic" => true > }], > "attributes" => { > "groups-attribute" => { > "type" => STRING, > "description" => "The name of the attribute in the returned AuthorizationIdentity that should contain the group membership information for the identity.", > "expressions-allowed" => true, > "nillable" => true, > "default" => "groups", > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > "groups-properties" => { > "type" => OBJECT, > "description" => "The properties file containing the users and their groups.", > "expressions-allowed" => false, > "nillable" => true, > "value-type" => { > "path" => { > "type" => STRING, > "description" => "The path to the file containing the users and their groups.", > "expressions-allowed" => true, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L > }, > "relative-to" => { > "type" => STRING, > "description" => "The pre-defined path the path is relative to.", > "expressions-allowed" => true, > "nillable" => true, > "requires" => ["path"], > "min-length" => 1L, > "max-length" => 2147483647L > } > }, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > "plain-text" => { > "type" => BOOLEAN, > "description" => "Are the passwords store in plain text within the properties file?", > "expressions-allowed" => true, > "nillable" => true, > "default" => false, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > "synchronized" => { > "type" => STRING, > "description" => "The time the properties files that back this realm were last loaded.", > "expressions-allowed" => false, > "nillable" => false, > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-only", > "storage" => "runtime" > }, > "users-properties" => { > "type" => OBJECT, > "description" => "The properties file containing the users and their passwords.", > "expressions-allowed" => false, > "nillable" => false, > "value-type" => { > "path" => { > "type" => STRING, > "description" => "The path to the file containing the users and their passwords.", > "expressions-allowed" => true, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L > }, > "relative-to" => { > "type" => STRING, > "description" => "The pre-defined path the path is relative to.", > "expressions-allowed" => true, > "nillable" => true, > "requires" => ["path"], > "min-length" => 1L, > "max-length" => 2147483647L > } > }, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > } > }, > "operations" => undefined, > "notifications" => undefined, > "children" => {} > } > }] > } > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1772) /core-service=capability-registry:get-provider-points only returning a single provider point.

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-1772: ---------------------------------------- Summary: /core-service=capability-registry:get-provider-points only returning a single provider point. Key: WFCORE-1772 URL: https://issues.jboss.org/browse/WFCORE-1772 Project: WildFly Core Issue Type: Bug Components: Domain Management Environment: This was reproduced using wildfly/master running the standalone-elytron.xml configuration. Reporter: Darran Lofthouse Assignee: Tomaz Cerar Fix For: 3.0.0.Alpha8 Running the following: - {noformat} [standalone@localhost:9990 /] /core-service=capability-registry:get-provider-points(name=org.wildfly.security.security-realm) { "outcome" => "success", "result" => ["/subsystem=elytron/filesystem-realm=*"] } {noformat} However there are other resources that can provide this capability e.g. {noformat} [standalone@localhost:9990 /] ./subsystem=elytron/properties-realm=*:read-resource-description { "outcome" => "success", "result" => [{ "address" => [ ("subsystem" => "elytron"), ("properties-realm" => "*") ], "outcome" => "success", "result" => { "description" => "A security realm definition backed by properties files.", "capabilities" => [{ "name" => "org.wildfly.security.security-realm", "dynamic" => true }], "attributes" => { "groups-attribute" => { "type" => STRING, "description" => "The name of the attribute in the returned AuthorizationIdentity that should contain the group membership information for the identity.", "expressions-allowed" => true, "nillable" => true, "default" => "groups", "min-length" => 1L, "max-length" => 2147483647L, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "resource-services" }, "groups-properties" => { "type" => OBJECT, "description" => "The properties file containing the users and their groups.", "expressions-allowed" => false, "nillable" => true, "value-type" => { "path" => { "type" => STRING, "description" => "The path to the file containing the users and their groups.", "expressions-allowed" => true, "nillable" => true, "min-length" => 1L, "max-length" => 2147483647L }, "relative-to" => { "type" => STRING, "description" => "The pre-defined path the path is relative to.", "expressions-allowed" => true, "nillable" => true, "requires" => ["path"], "min-length" => 1L, "max-length" => 2147483647L } }, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "resource-services" }, "plain-text" => { "type" => BOOLEAN, "description" => "Are the passwords store in plain text within the properties file?", "expressions-allowed" => true, "nillable" => true, "default" => false, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "resource-services" }, "synchronized" => { "type" => STRING, "description" => "The time the properties files that back this realm were last loaded.", "expressions-allowed" => false, "nillable" => false, "min-length" => 1L, "max-length" => 2147483647L, "access-type" => "read-only", "storage" => "runtime" }, "users-properties" => { "type" => OBJECT, "description" => "The properties file containing the users and their passwords.", "expressions-allowed" => false, "nillable" => false, "value-type" => { "path" => { "type" => STRING, "description" => "The path to the file containing the users and their passwords.", "expressions-allowed" => true, "nillable" => true, "min-length" => 1L, "max-length" => 2147483647L }, "relative-to" => { "type" => STRING, "description" => "The pre-defined path the path is relative to.", "expressions-allowed" => true, "nillable" => true, "requires" => ["path"], "min-length" => 1L, "max-length" => 2147483647L } }, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "resource-services" } }, "operations" => undefined, "notifications" => undefined, "children" => {} } }] } {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1771) CLI - Tab completion in composite operation throws IAE

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1771?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-1771: ----------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1784 > CLI - Tab completion in composite operation throws IAE > ------------------------------------------------------ > > Key: WFCORE-1771 > URL: https://issues.jboss.org/browse/WFCORE-1771 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 3.0.0.Alpha7 > Reporter: Michal Petrov > Assignee: Jean-Francois Denise > > Getting an exception when trying to make a composite operation > {code} > [standalone@localhost:9990 /] :composite(steps=[{aException in thread "Aesh Process Loop 1409160703" java.lang.IllegalArgumentException > at org.jboss.dmr.ModelValue.getKeys(ModelValue.java:139) > at org.jboss.dmr.ModelNode.keys(ModelNode.java:1378) > at org.jboss.as.cli.impl.ValueTypeCompleter$ValueTypeCallbackHandler.getCandidates(ValueTypeCompleter.java:502) > at org.jboss.as.cli.impl.ValueTypeCompleter.complete(ValueTypeCompleter.java:332) > at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:254) > at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:74) > at org.jboss.as.cli.CommandCompleter.doComplete(CommandCompleter.java:134) > at org.jboss.as.cli.CommandCompleter.complete(CommandCompleter.java:63) > at org.jboss.as.cli.impl.Console$Factory$1$1.complete(Console.java:143) > at org.jboss.aesh.console.AeshCompletionHandler.complete(AeshCompletionHandler.java:155) > at org.jboss.aesh.console.AeshInputProcessor.complete(AeshInputProcessor.java:423) > at org.jboss.aesh.console.AeshInputProcessor.parseOperation(AeshInputProcessor.java:165) > at org.jboss.aesh.console.Console.processInternalOperation(Console.java:773) > at org.jboss.aesh.console.Console.execute(Console.java:733) > at org.jboss.aesh.console.Console.access$900(Console.java:73) > at org.jboss.aesh.console.Console$6.run(Console.java:642) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > {code} > Happens only for certain strings, e.g. > * {{:composite(steps=\[{a<TAB>}} fails > * {{:composite(steps=\[a<TAB>}} doesn't fail (suggests "," or "]") > * {{:composite(steps=\[a=<TAB>}} fails -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7074) Unable to add cached-connection-manager after removing it once

by Martin Simka (JIRA)

Martin Simka created WFLY-7074: ---------------------------------- Summary: Unable to add cached-connection-manager after removing it once Key: WFLY-7074 URL: https://issues.jboss.org/browse/WFLY-7074 Project: WildFly Issue Type: Bug Components: JCA Affects Versions: 8.0.0.Beta1 Reporter: Martin Simka {{<cached-connection-manager>}} is enabled in jca subsystem by default: {code:xml} <subsystem xmlns="urn:jboss:domain:jca:1.1"> ... <cached-connection-manager /> </subsystem> {code} However, it is unable to re-enable {{<cached-connection-manager>}} once it is disabled. CLI command fails to add it due to duplicate resource. {code} [standalone@localhost:9990 /] /subsystem=jca/cached-connection-manager=cached-connection-manager:remove { "outcome" => "success", "response-headers" => { "operation-requires-reload" => true, "process-state" => "reload-required" } } [standalone@localhost:9990 /] :reload { "outcome" => "success", "result" => undefined } [standalone@localhost:9990 /] /subsystem=jca/cached-connection-manager=cached-connection-manager:add { "outcome" => "failed", "failure-description" => "JBAS014803: Duplicate resource [ (\"subsystem\" => \"jca\"), (\"cached-connection-manager\" => \"cached-connection-manager\") ]", "rolled-back" => true } {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1008) KieServer to update container for SNAPSHOT kjar

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1008?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-1008. --------------------------------- Resolution: Cannot Reproduce Bug As I wrote in my last comment I'm not able to reproduce this issue. In case this is still a problem also on latest drools version feel free to reopen this ticket providing a complete reproducer (maybe setting up your environment in a docker image?) > KieServer to update container for SNAPSHOT kjar > ----------------------------------------------- > > Key: DROOLS-1008 > URL: https://issues.jboss.org/browse/DROOLS-1008 > Project: Drools > Issue Type: Feature Request > Components: kie server > Affects Versions: 6.2.0.Final, 6.3.0.Final > Reporter: Andrew Collins > Assignee: Mario Fusco > Attachments: snapshot_kjar_reproducer.patch > > > General: > When a kjar has a snapshot version, kie-server will not react to new snapshot versions deployed to a remote artifact repository. The remote artifact repository is only queried the first time after JVM startup, regardless of settings.xml snapshot updatePolicy setting. Retrieving a new snapshot version is only possible through use of KieScanner.scanNow() or recycling the JVM, which will both fetch the new artifact from the remote repository and reload the kmodule in the KieServer JVM. > Steps to reproduce: > * KieServer and Business Central deployed to separate JVMs, pointing to independent maven repositories. Snapshot updatePolicy should be "always" in KieServer settings.xml. > * Deploy new kjar snapshot from Business Central to remote artifactory. (unique version "1") > * Start KieServer (verify new snapshot version is pulled from remote) > * Deploy new kjar snapnshot. (unique version "2") > Expected behavior: > * Creating a new container, or invoking updateReleaseId() on existing container will pull latest snapshot from remote artifactory. > Actual Behavior > * Creating a new container, or invoking updateReleaseId() on existing container, does not query remote artifactory for latest snapshots. > Workaround: > * Forcing a KieScanner.scanNow() will fetch new snapshot from remote artifactory. > * Or, restarting KieScanner JVM will fetch new snapshot from remote artifactory. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7029) RemoteFailoverTestCast#testGracefulShutdownConcurrentFailover fails with "ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations."

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7029?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-7029: --------------------------------- Labels: clean_shutdown (was: ) > RemoteFailoverTestCast#testGracefulShutdownConcurrentFailover fails with "ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations." > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7029 > URL: https://issues.jboss.org/browse/WFLY-7029 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Richard Achmatowicz > Labels: clean_shutdown > > https://ci.wildfly.org/viewLog.html?buildId=24851&tab=buildResultsDiv&bui... > {noformat} > 04:31:43,323 INFO [org.jboss.as.test.clustering.NodeUtil] (main) Stopping container=container-0, timeout=15 > 04:31:43,324 INFO [org.jboss.as.arquillian.container.controller.ClientWildFlyContainerController] (main) Manual stopping of a server instance with timeout=15 > &amp#27;[0m04:31:43,338 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0211: Suspending server with 15000 ms timeout. > &amp#27;[0m04:31:43,343 INFO [org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler] (Remoting "config-based-ejb-client-endpoint" task-10) Retrying invocation which failed on node node-0 with exception:: javax.ejb.NoSuchEJBException: No such EJB[appname=,modulename=remote-failover-test,distinctname=,beanname=SlowToDestroyStatefulIncrementorBean,viewclassname=org.jboss.as.test.clustering.cluster.ejb.remote.bean.Incrementor] > at org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler.processMessage(NoSuchEJBExceptionResponseHandler.java:64) > at org.jboss.ejb.client.remoting.ChannelAssociation.processResponse(ChannelAssociation.java:386) > at org.jboss.ejb.client.remoting.ChannelAssociation$ResponseReceiver.handleMessage(ChannelAssociation.java:498) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > &amp#27;[0m04:31:43,345 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' > &amp#27;[0m&amp#27;[0m04:31:43,430 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping > &amp#27;[0m&amp#27;[0m04:31:43,436 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 29) MODCLUSTER000002: Initiating mod_cluster shutdown > &amp#27;[0m&amp#27;[0m04:31:43,445 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 74) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:/ConnectionFactory > &amp#27;[0m&amp#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000080: Disconnecting JGroups channel hibernate > &amp#27;[0m&amp#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher for channel hibernate > &amp#27;[0m&amp#27;[0m04:31:43,463 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000080: Disconnecting JGroups channel server > &amp#27;[0m&amp#27;[0m04:31:43,464 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000082: Stopping the RpcDispatcher for channel server > &amp#27;[0m&amp#27;[0m04:31:43,471 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000029: Passivating all entries to disk > &amp#27;[0m&amp#27;[0m04:31:43,472 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000030: Passivated 2 entries in 0 milliseconds > &amp#27;[0m&amp#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel web > &amp#27;[0m&amp#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel web > &amp#27;[0m&amp#27;[0m04:31:43,502 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 29) WFLYCLINF0003: Stopped remote-failover-test.jar cache from ejb container > &amp#27;[0m&amp#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel testDbPersistence > &amp#27;[0m&amp#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel testDbPersistence > &amp#27;[0m&amp#27;[33m04:31:43,502 WARN [org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler] (thread-11,ee,node-0) ISPN000071: Caught exception when handling command LockControlCommand{cache=remote-failover-test.jar, keys=[UnknownSessionID [6951504948515351686656515249505365655750686851525048706670486766]], flags=[FORCE_WRITE_LOCK], unlock=false, gtx=GlobalTransaction:<node-1>:48:remote}: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > at org.jgroups.JChannel.up(JChannel.java:738) > at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120) > at org.jgroups.stack.Protocol.up(Protocol.java:380) > at org.jgroups.protocols.FORK.up(FORK.java:114) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070) > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD.up(FD.java:260) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) > at org.jgroups.protocols.Discovery.up(Discovery.java:296) > at org.jgroups.protocols.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52) > at java.lang.Thread.run(Thread.java:745) > &amp#27;[0m&amp#27;[0m04:31:43,517 INFO [org.wildfly.extension.messaging-activemq] (MSC service thread 1-2) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory > &amp#27;[0m&amp#27;[0m04:31:43,517 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > &amp#27;[0m&amp#27;[0m04:31:43,518 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA] > &amp#27;[0m&amp#27;[0m04:31:43,535 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-8) WFLYJCA0019: Stopped Driver service with driver-name = h2 > &amp#27;[0m&amp#27;[0m04:31:43,547 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 2) WFLYCLINF0003: Stopped client-mappings cache from ejb container > &amp#27;[0m04:31:43,565 INFO [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-14) EJBCLIENT000016: Channel Channel ID b007a55b (outbound) of Remoting connection 017c35ab to /0:0:0:0:0:0:0:1:8080 of endpoint "config-based-ejb-client-endpoint" <1c33eee> can no longer process messages > &amp#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000080: Disconnecting JGroups channel ejb > &amp#27;[0m&amp#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000082: Stopping the RpcDispatcher for channel ejb > &amp#27;[0m&amp#27;[0m04:31:43,575 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 35) AMQ151003: resource adaptor stopped > &amp#27;[0m&amp#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow AJP listener ajp suspending > &amp#27;[0m&amp#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [::1]:8009 > &amp#27;[0m&amp#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTPS listener https suspending > &amp#27;[0m&amp#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [::1]:8443 > &amp#27;[0m&amp#27;[31m04:31:43,585 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-11) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace > at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:795) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642) > at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602) > at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577) > at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) > at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962) > at org.infinispan.remoting.transport.jgroups.RspListFuture.futureDone(RspListFuture.java:31) > at org.jgroups.blocks.Request.checkCompletion(Request.java:152) > at org.jgroups.blocks.GroupRequest.receiveResponse(GroupRequest.java:116) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:427) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > at org.jgroups.JChannel.up(JChannel.java:738) > at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120) > at org.jgroups.stack.Protocol.up(Protocol.java:380) > at org.jgroups.protocols.FORK.up(FORK.java:114) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070) > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD.up(FD.java:260) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) > at org.jgroups.protocols.Discovery.up(Discovery.java:296) > at org.jgroups.protocols.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.infinispan.commons.CacheException: Problems invoking command. > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.exceptionHandlingCommand(BasePerCacheInboundInvocationHandler.java:106) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:101) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > ... 27 more > Caused by: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > ... 33 more > &amp#27;[0m&amp#27;[31m04:31:43,588 ERROR [org.jboss.as.ejb3.invocation] (default task-11) WFLYEJB0034: EJB Invocation failed on component SlowToDestroyStatefulIncrementorBean for method public abstract org.jboss.as.test.clustering.cluster.ejb.remote.bean.Result org.jboss.as.test.clustering.cluster.ejb.remote.bean.Incrementor.increment(): javax.ejb.EJBException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace > at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:328) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:201) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:263) > at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213) > at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76) > at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace > at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:795) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642) > at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602) > at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577) > at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) > at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962) > at org.infinispan.remoting.transport.jgroups.RspListFuture.futureDone(RspListFuture.java:31) > at org.jgroups.blocks.Request.checkCompletion(Request.java:152) > at org.jgroups.blocks.GroupRequest.receiveResponse(GroupRequest.java:116) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:427) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > at org.jgroups.JChannel.up(JChannel.java:738) > at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120) > at org.jgroups.stack.Protocol.up(Protocol.java:380) > at org.jgroups.protocols.FORK.up(FORK.java:114) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070) > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD.up(FD.java:260) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) > at org.jgroups.protocols.Discovery.up(Discovery.java:296) > at org.jgroups.protocols.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52) > ... 1 more > Caused by: org.infinispan.commons.CacheException: Problems invoking command. > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.exceptionHandlingCommand(BasePerCacheInboundInvocationHandler.java:106) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:101) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > ... 27 more > Caused by: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > ... 33 more > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1008) KieServer to update container for SNAPSHOT kjar

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1008?page=com.atlassian.jira.plugi... ] Mario Fusco commented on DROOLS-1008: ------------------------------------- I'm still investigating this purely on the kie-ci side. I already had a few tests using snapshots. Moreover in one of them I tried to replace {code:java} scanner.scanNow(); {code} with {code:java} kieContainer.updateToVersion( releaseId ); {code} here https://github.com/droolsjbpm/drools/blob/master/kie-ci/src/test/java/org... but still the test works as expected. [~acollins] I'm assuming that when you wrote updateReleaseId() you actually meant updateToVersion( releaseId ). if this is the case I'm still unable to reproduce this problem, at least as a unit test inside kie-ci. I'll now try to set up an environment as similar as possible to the one you described and check if can I reproduce this issue in that way. > KieServer to update container for SNAPSHOT kjar > ----------------------------------------------- > > Key: DROOLS-1008 > URL: https://issues.jboss.org/browse/DROOLS-1008 > Project: Drools > Issue Type: Feature Request > Components: kie server > Affects Versions: 6.2.0.Final, 6.3.0.Final > Reporter: Andrew Collins > Assignee: Mario Fusco > Attachments: snapshot_kjar_reproducer.patch > > > General: > When a kjar has a snapshot version, kie-server will not react to new snapshot versions deployed to a remote artifact repository. The remote artifact repository is only queried the first time after JVM startup, regardless of settings.xml snapshot updatePolicy setting. Retrieving a new snapshot version is only possible through use of KieScanner.scanNow() or recycling the JVM, which will both fetch the new artifact from the remote repository and reload the kmodule in the KieServer JVM. > Steps to reproduce: > * KieServer and Business Central deployed to separate JVMs, pointing to independent maven repositories. Snapshot updatePolicy should be "always" in KieServer settings.xml. > * Deploy new kjar snapshot from Business Central to remote artifactory. (unique version "1") > * Start KieServer (verify new snapshot version is pulled from remote) > * Deploy new kjar snapnshot. (unique version "2") > Expected behavior: > * Creating a new container, or invoking updateReleaseId() on existing container will pull latest snapshot from remote artifactory. > Actual Behavior > * Creating a new container, or invoking updateReleaseId() on existing container, does not query remote artifactory for latest snapshots. > Workaround: > * Forcing a KieScanner.scanNow() will fetch new snapshot from remote artifactory. > * Or, restarting KieScanner JVM will fetch new snapshot from remote artifactory. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7073) elytron key/trust-managers incosistency between dmr and xsd

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7073?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-7073: ---------------------------------------- [~honza889] Passing this one your way as it is a subsystem issue, however we may want to pick up the work to redesign the provider-loader resource first as the final design for that resource(s) may influence how we really want to reference it. > elytron key/trust-managers incosistency between dmr and xsd > ----------------------------------------------------------- > > Key: WFLY-7073 > URL: https://issues.jboss.org/browse/WFLY-7073 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Jan Kalina > > For key/trust-managers in dmr model, there is "provider-loader" attribute [1], however xsd defines provider attribute [2] for key/trust-managers. > Probably if user could define both provider and provider-loader, that would be the best. > [1] > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/key-managers=server2:add( > algorithm key-store password provider-loader > {noformat} > [2] > https://github.com/wildfly-security/elytron-subsystem/blob/master/src/mai... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7073) elytron key/trust-managers incosistency between dmr and xsd

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7073?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-7073: -------------------------------------- Assignee: Jan Kalina (was: Darran Lofthouse) > elytron key/trust-managers incosistency between dmr and xsd > ----------------------------------------------------------- > > Key: WFLY-7073 > URL: https://issues.jboss.org/browse/WFLY-7073 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Jan Kalina > > For key/trust-managers in dmr model, there is "provider-loader" attribute [1], however xsd defines provider attribute [2] for key/trust-managers. > Probably if user could define both provider and provider-loader, that would be the best. > [1] > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/key-managers=server2:add( > algorithm key-store password provider-loader > {noformat} > [2] > https://github.com/wildfly-security/elytron-subsystem/blob/master/src/mai... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7073) elytron key/trust-managers incosistency between dmr and xsd

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7073?page=com.atlassian.jira.plugin.... ] Martin Choma moved JBEAP-5928 to WFLY-7073: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7073 (was: JBEAP-5928) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: (was: 7.1.0.DR4) > elytron key/trust-managers incosistency between dmr and xsd > ----------------------------------------------------------- > > Key: WFLY-7073 > URL: https://issues.jboss.org/browse/WFLY-7073 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > > For key/trust-managers in dmr model, there is "provider-loader" attribute [1], however xsd defines provider attribute [2] for key/trust-managers. > Probably if user could define both provider and provider-loader, that would be the best. > [1] > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/key-managers=server2:add( > algorithm key-store password provider-loader > {noformat} > [2] > https://github.com/wildfly-security/elytron-subsystem/blob/master/src/mai... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7029) RemoteFailoverTestCast#testGracefulShutdownConcurrentFailover fails with "ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations."

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/WFLY-7029?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on WFLY-7029: ------------------------------------ The remote node is supposed to catch {{IllegalLifecycleStateException}} and replace the exception with a {{CacheNotFoundResponse}} (ISPN-5539). However, this time the exception happens in {{BlockingRunnable.isReady()}}, outside of {{BaseBlockingRunnable.run()}}, so the {{IllegalLifecycleStateException}} is never caught and is sent directly to the originator. I've created ISPN-7008 to track this. > RemoteFailoverTestCast#testGracefulShutdownConcurrentFailover fails with "ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations." > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7029 > URL: https://issues.jboss.org/browse/WFLY-7029 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Richard Achmatowicz > > https://ci.wildfly.org/viewLog.html?buildId=24851&tab=buildResultsDiv&bui... > {noformat} > 04:31:43,323 INFO [org.jboss.as.test.clustering.NodeUtil] (main) Stopping container=container-0, timeout=15 > 04:31:43,324 INFO [org.jboss.as.arquillian.container.controller.ClientWildFlyContainerController] (main) Manual stopping of a server instance with timeout=15 > &amp#27;[0m04:31:43,338 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0211: Suspending server with 15000 ms timeout. > &amp#27;[0m04:31:43,343 INFO [org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler] (Remoting "config-based-ejb-client-endpoint" task-10) Retrying invocation which failed on node node-0 with exception:: javax.ejb.NoSuchEJBException: No such EJB[appname=,modulename=remote-failover-test,distinctname=,beanname=SlowToDestroyStatefulIncrementorBean,viewclassname=org.jboss.as.test.clustering.cluster.ejb.remote.bean.Incrementor] > at org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler.processMessage(NoSuchEJBExceptionResponseHandler.java:64) > at org.jboss.ejb.client.remoting.ChannelAssociation.processResponse(ChannelAssociation.java:386) > at org.jboss.ejb.client.remoting.ChannelAssociation$ResponseReceiver.handleMessage(ChannelAssociation.java:498) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > &amp#27;[0m04:31:43,345 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' > &amp#27;[0m&amp#27;[0m04:31:43,430 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping > &amp#27;[0m&amp#27;[0m04:31:43,436 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 29) MODCLUSTER000002: Initiating mod_cluster shutdown > &amp#27;[0m&amp#27;[0m04:31:43,445 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 74) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:/ConnectionFactory > &amp#27;[0m&amp#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000080: Disconnecting JGroups channel hibernate > &amp#27;[0m&amp#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher for channel hibernate > &amp#27;[0m&amp#27;[0m04:31:43,463 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000080: Disconnecting JGroups channel server > &amp#27;[0m&amp#27;[0m04:31:43,464 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000082: Stopping the RpcDispatcher for channel server > &amp#27;[0m&amp#27;[0m04:31:43,471 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000029: Passivating all entries to disk > &amp#27;[0m&amp#27;[0m04:31:43,472 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000030: Passivated 2 entries in 0 milliseconds > &amp#27;[0m&amp#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel web > &amp#27;[0m&amp#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel web > &amp#27;[0m&amp#27;[0m04:31:43,502 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 29) WFLYCLINF0003: Stopped remote-failover-test.jar cache from ejb container > &amp#27;[0m&amp#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel testDbPersistence > &amp#27;[0m&amp#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel testDbPersistence > &amp#27;[0m&amp#27;[33m04:31:43,502 WARN [org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler] (thread-11,ee,node-0) ISPN000071: Caught exception when handling command LockControlCommand{cache=remote-failover-test.jar, keys=[UnknownSessionID [6951504948515351686656515249505365655750686851525048706670486766]], flags=[FORCE_WRITE_LOCK], unlock=false, gtx=GlobalTransaction:<node-1>:48:remote}: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > at org.jgroups.JChannel.up(JChannel.java:738) > at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120) > at org.jgroups.stack.Protocol.up(Protocol.java:380) > at org.jgroups.protocols.FORK.up(FORK.java:114) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070) > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD.up(FD.java:260) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) > at org.jgroups.protocols.Discovery.up(Discovery.java:296) > at org.jgroups.protocols.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52) > at java.lang.Thread.run(Thread.java:745) > &amp#27;[0m&amp#27;[0m04:31:43,517 INFO [org.wildfly.extension.messaging-activemq] (MSC service thread 1-2) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory > &amp#27;[0m&amp#27;[0m04:31:43,517 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > &amp#27;[0m&amp#27;[0m04:31:43,518 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA] > &amp#27;[0m&amp#27;[0m04:31:43,535 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-8) WFLYJCA0019: Stopped Driver service with driver-name = h2 > &amp#27;[0m&amp#27;[0m04:31:43,547 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 2) WFLYCLINF0003: Stopped client-mappings cache from ejb container > &amp#27;[0m04:31:43,565 INFO [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-14) EJBCLIENT000016: Channel Channel ID b007a55b (outbound) of Remoting connection 017c35ab to /0:0:0:0:0:0:0:1:8080 of endpoint "config-based-ejb-client-endpoint" <1c33eee> can no longer process messages > &amp#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000080: Disconnecting JGroups channel ejb > &amp#27;[0m&amp#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000082: Stopping the RpcDispatcher for channel ejb > &amp#27;[0m&amp#27;[0m04:31:43,575 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 35) AMQ151003: resource adaptor stopped > &amp#27;[0m&amp#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow AJP listener ajp suspending > &amp#27;[0m&amp#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [::1]:8009 > &amp#27;[0m&amp#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTPS listener https suspending > &amp#27;[0m&amp#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [::1]:8443 > &amp#27;[0m&amp#27;[31m04:31:43,585 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-11) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace > at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:795) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642) > at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602) > at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577) > at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) > at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962) > at org.infinispan.remoting.transport.jgroups.RspListFuture.futureDone(RspListFuture.java:31) > at org.jgroups.blocks.Request.checkCompletion(Request.java:152) > at org.jgroups.blocks.GroupRequest.receiveResponse(GroupRequest.java:116) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:427) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > at org.jgroups.JChannel.up(JChannel.java:738) > at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120) > at org.jgroups.stack.Protocol.up(Protocol.java:380) > at org.jgroups.protocols.FORK.up(FORK.java:114) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070) > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD.up(FD.java:260) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) > at org.jgroups.protocols.Discovery.up(Discovery.java:296) > at org.jgroups.protocols.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.infinispan.commons.CacheException: Problems invoking command. > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.exceptionHandlingCommand(BasePerCacheInboundInvocationHandler.java:106) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:101) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > ... 27 more > Caused by: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > ... 33 more > &amp#27;[0m&amp#27;[31m04:31:43,588 ERROR [org.jboss.as.ejb3.invocation] (default task-11) WFLYEJB0034: EJB Invocation failed on component SlowToDestroyStatefulIncrementorBean for method public abstract org.jboss.as.test.clustering.cluster.ejb.remote.bean.Result org.jboss.as.test.clustering.cluster.ejb.remote.bean.Incrementor.increment(): javax.ejb.EJBException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace > at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:328) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:201) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:263) > at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213) > at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76) > at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace > at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:795) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642) > at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602) > at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577) > at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) > at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962) > at org.infinispan.remoting.transport.jgroups.RspListFuture.futureDone(RspListFuture.java:31) > at org.jgroups.blocks.Request.checkCompletion(Request.java:152) > at org.jgroups.blocks.GroupRequest.receiveResponse(GroupRequest.java:116) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:427) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > at org.jgroups.JChannel.up(JChannel.java:738) > at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120) > at org.jgroups.stack.Protocol.up(Protocol.java:380) > at org.jgroups.protocols.FORK.up(FORK.java:114) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070) > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD.up(FD.java:260) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) > at org.jgroups.protocols.Discovery.up(Discovery.java:296) > at org.jgroups.protocols.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52) > ... 1 more > Caused by: org.infinispan.commons.CacheException: Problems invoking command. > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.exceptionHandlingCommand(BasePerCacheInboundInvocationHandler.java:106) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:101) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > ... 27 more > Caused by: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > ... 33 more > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1281) [GSS] (6..4.x) compilation of spreadsheet fails with specific condition

by Hiroko Miura (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1281?page=com.atlassian.jira.plugi... ] Hiroko Miura deleted DROOLS-1281: --------------------------------- > [GSS] (6..4.x) compilation of spreadsheet fails with specific condition > ----------------------------------------------------------------------- > > Key: DROOLS-1281 > URL: https://issues.jboss.org/browse/DROOLS-1281 > Project: Drools > Issue Type: Bug > Reporter: Hiroko Miura > Assignee: Mario Fusco > Labels: support > > Platform JIRA for https://issues.jboss.org/browse/DROOLS-1279 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1556) Poor handling of 'required', 'nillable' and 'alternatives' in AttributeDefinition

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1556?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1556: ------------------------------------- Description: The handling of the notions of 'required' and 'nillable' don't comply with the specs in https://docs.jboss.org/author/display/WFLY/Description+of+the+Management+..., particularly the "Description of an Attribute" part, where the 'required' and 'alternatives' fields are well described, with their relationship spelled out, while 'nillable' doesn't appear at all. Then in "Description of an Operation Parameter or Return Value" nillable is specified, although I think those descriptions could be tightened up in general. The read-resource-description output for an attribute doesn't show "required" at all. After a fair bit of thinking, I've finally recalled why the two separate notions of "required" and "nillable" exist in the first place. The "required" and "alternatives" pieces go together. Is something required? And then if it is required, an alternative satisfies. So you can have two attributes/params, both required, but they are alternatives so one is defined and the other is not. And this is an ok thing. And then 'nillable' comes in to help clients understand in a simple way whether they need to account for the possibility an undefined value. Basically: nillable = !required || alternatives != null Right now, nillable is implemented as nillable = !required There are a number of problems I see with AttributeDefinition: 1) We don't output the 'required' metadata unless it's an operation param being described. This is contrary to spec. However we shouldn't fix this unless we can have meaningful values for 'required', ones where the value can be true but the attribute/param can still have an undefined value, due to an alternative being present. If we can't fix that, there's no point outputting required as it's just redundant with what we output for 'nillable'. 2) We do output the 'nillable' metadata, even for attribute descriptions, where it isn't in the spec. But in this case I think we change the spec, as dropping nillable would be an incompatible change. 3) We don't properly validate the "required but has alternatives case." This can't be validated solely with ParameterValidator impls as those only see a single attribute value and don't have contextual information about other attributes/params. To get around this limitation, devs are saying that attributes with alternatives "allowNull" which is equivalent to saying they are not required. But they are required! So I think a fix for this will require AttributeDefinition itself to validate the overall resource model or operation object, and skip calling the ParameterValidator if the attribute/param is undefined and an alternative is defined. 4) AttributeDefinition and AbstractAttributeDefinitionBuilder unfortunately have a getter/setter/constructor param for property "allowNull" instead of a property named "required". This is unfortunate because "allowNull" intuitively maps to "nillable", but "required" is a much more useful thing to set. The value of "nillable" can be derived from a "required" setting and an "alternatives" setting, but the value of required cannot be so derived. I think a fix for this would probably start from 4), deprecating setAllowNull, adding get/setRequired and changing the meaning of the AD(Builder) constructor param to "required". The effect of this would be that all current code setting "allowNull" would now be setting a new "required" field. This should be a non-breaking change as in current code that's the effect anyway. Next would be to fix 3), by changing how AD validates. Next would be to change the metadata we output, such that "required" is always present and the "nillable" value is !required || alternatives != null. And change the spec accordingly. Last, in a separate task, would be to find attributes that were configuring "allowNull = true" solely to allow validation to pass when alternatives are present, and fix them to say "required=false". was: The handling of the notions of 'required' and 'nillable' don't comply with the specs in https://docs.jboss.org/author/display/WFLY10/Description+of+the+Managemen..., particularly the "Description of an Attribute" part, where the 'required' and 'alternatives' fields are well described, with their relationship spelled out, while 'nillable' doesn't appear at all. Then in "Description of an Operation Parameter or Return Value" nillable is specified, although I think those descriptions could be tightened up in general. The read-resource-description output for an attribute doesn't show "required" at all. After a fair bit of thinking, I've finally recalled why the two separate notions of "required" and "nillable" exist in the first place. The "required" and "alternatives" pieces go together. Is something required? And then if it is required, an alternative satisfies. So you can have two attributes/params, both required, but they are alternatives so one is defined and the other is not. And this is an ok thing. And then 'nillable' comes in to help clients understand in a simple way whether they need to account for the possibility an undefined value. Basically: nillable = !required || alternatives != null Right now, nillable is implemented as nillable = !required There are a number of problems I see with AttributeDefinition: 1) We don't output the 'required' metadata unless it's an operation param being described. This is contrary to spec. However we shouldn't fix this unless we can have meaningful values for 'required', ones where the value can be true but the attribute/param can still have an undefined value, due to an alternative being present. If we can't fix that, there's no point outputting required as it's just redundant with what we output for 'nillable'. 2) We do output the 'nillable' metadata, even for attribute descriptions, where it isn't in the spec. But in this case I think we change the spec, as dropping nillable would be an incompatible change. 3) We don't properly validate the "required but has alternatives case." This can't be validated solely with ParameterValidator impls as those only see a single attribute value and don't have contextual information about other attributes/params. To get around this limitation, devs are saying that attributes with alternatives "allowNull" which is equivalent to saying they are not required. But they are required! So I think a fix for this will require AttributeDefinition itself to validate the overall resource model or operation object, and skip calling the ParameterValidator if the attribute/param is undefined and an alternative is defined. 4) AttributeDefinition and AbstractAttributeDefinitionBuilder unfortunately have a getter/setter/constructor param for property "allowNull" instead of a property named "required". This is unfortunate because "allowNull" intuitively maps to "nillable", but "required" is a much more useful thing to set. The value of "nillable" can be derived from a "required" setting and an "alternatives" setting, but the value of required cannot be so derived. I think a fix for this would probably start from 4), deprecating setAllowNull, adding get/setRequired and changing the meaning of the AD(Builder) constructor param to "required". The effect of this would be that all current code setting "allowNull" would now be setting a new "required" field. This should be a non-breaking change as in current code that's the effect anyway. Next would be to fix 3), by changing how AD validates. Next would be to change the metadata we output, such that "required" is always present and the "nillable" value is !required || alternatives != null. And change the spec accordingly. Last, in a separate task, would be to find attributes that were configuring "allowNull = true" solely to allow validation to pass when alternatives are present, and fix them to say "required=false". > Poor handling of 'required', 'nillable' and 'alternatives' in AttributeDefinition > --------------------------------------------------------------------------------- > > Key: WFCORE-1556 > URL: https://issues.jboss.org/browse/WFCORE-1556 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > The handling of the notions of 'required' and 'nillable' don't comply with the specs in https://docs.jboss.org/author/display/WFLY/Description+of+the+Management+..., particularly the "Description of an Attribute" part, where the 'required' and 'alternatives' fields are well described, with their relationship spelled out, while 'nillable' doesn't appear at all. Then in "Description of an Operation Parameter or Return Value" nillable is specified, although I think those descriptions could be tightened up in general. > The read-resource-description output for an attribute doesn't show "required" at all. > After a fair bit of thinking, I've finally recalled why the two separate notions of "required" and "nillable" exist in the first place. > The "required" and "alternatives" pieces go together. Is something required? And then if it is required, an alternative satisfies. So you can have two attributes/params, both required, but they are alternatives so one is defined and the other is not. And this is an ok thing. > And then 'nillable' comes in to help clients understand in a simple way whether they need to account for the possibility an undefined value. Basically: > nillable = !required || alternatives != null > Right now, nillable is implemented as > nillable = !required > There are a number of problems I see with AttributeDefinition: > 1) We don't output the 'required' metadata unless it's an operation param being described. This is contrary to spec. However we shouldn't fix this unless we can have meaningful values for 'required', ones where the value can be true but the attribute/param can still have an undefined value, due to an alternative being present. If we can't fix that, there's no point outputting required as it's just redundant with what we output for 'nillable'. > 2) We do output the 'nillable' metadata, even for attribute descriptions, where it isn't in the spec. But in this case I think we change the spec, as dropping nillable would be an incompatible change. > 3) We don't properly validate the "required but has alternatives case." This can't be validated solely with ParameterValidator impls as those only see a single attribute value and don't have contextual information about other attributes/params. To get around this limitation, devs are saying that attributes with alternatives "allowNull" which is equivalent to saying they are not required. But they are required! So I think a fix for this will require AttributeDefinition itself to validate the overall resource model or operation object, and skip calling the ParameterValidator if the attribute/param is undefined and an alternative is defined. > 4) AttributeDefinition and AbstractAttributeDefinitionBuilder unfortunately have a getter/setter/constructor param for property "allowNull" instead of a property named "required". This is unfortunate because "allowNull" intuitively maps to "nillable", but "required" is a much more useful thing to set. The value of "nillable" can be derived from a "required" setting and an "alternatives" setting, but the value of required cannot be so derived. > I think a fix for this would probably start from 4), deprecating setAllowNull, adding get/setRequired and changing the meaning of the AD(Builder) constructor param to "required". The effect of this would be that all current code setting "allowNull" would now be setting a new "required" field. This should be a non-breaking change as in current code that's the effect anyway. > Next would be to fix 3), by changing how AD validates. > Next would be to change the metadata we output, such that "required" is always present and the "nillable" value is !required || alternatives != null. And change the spec accordingly. > Last, in a separate task, would be to find attributes that were configuring "allowNull = true" solely to allow validation to pass when alternatives are present, and fix them to say "required=false". -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1281) [GSS] (6..4.x) compilation of spreadsheet fails with specific condition

by Hiroko Miura (JIRA)

Hiroko Miura created DROOLS-1281: ------------------------------------ Summary: [GSS] (6..4.x) compilation of spreadsheet fails with specific condition Key: DROOLS-1281 URL: https://issues.jboss.org/browse/DROOLS-1281 Project: Drools Issue Type: Bug Components: decision tables Affects Versions: 6.4.0.Final Reporter: Hiroko Miura Assignee: Mario Fusco Fix For: 6.5.0.Final Platform JIRA for https://issues.jboss.org/browse/DROOLS-1279 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1281) [GSS] (6..4.x) compilation of spreadsheet fails with specific condition

by Hiroko Miura (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1281?page=com.atlassian.jira.plugi... ] Hiroko Miura updated DROOLS-1281: --------------------------------- Labels: support (was: ) > [GSS] (6..4.x) compilation of spreadsheet fails with specific condition > ----------------------------------------------------------------------- > > Key: DROOLS-1281 > URL: https://issues.jboss.org/browse/DROOLS-1281 > Project: Drools > Issue Type: Bug > Components: decision tables > Affects Versions: 6.4.0.Final > Reporter: Hiroko Miura > Assignee: Mario Fusco > Labels: support > Fix For: 6.5.0.Final > > > Platform JIRA for https://issues.jboss.org/browse/DROOLS-1279 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1771) CLI - Tab completion in composite operation throws IAE

by Alexey Loubyansky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1771?page=com.atlassian.jira.plugi... ] Alexey Loubyansky reassigned WFCORE-1771: ----------------------------------------- Assignee: Jean-Francois Denise (was: Alexey Loubyansky) Jeff, could you please look into this one? Thanks. > CLI - Tab completion in composite operation throws IAE > ------------------------------------------------------ > > Key: WFCORE-1771 > URL: https://issues.jboss.org/browse/WFCORE-1771 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 3.0.0.Alpha7 > Reporter: Michal Petrov > Assignee: Jean-Francois Denise > > Getting an exception when trying to make a composite operation > {code} > [standalone@localhost:9990 /] :composite(steps=[{aException in thread "Aesh Process Loop 1409160703" java.lang.IllegalArgumentException > at org.jboss.dmr.ModelValue.getKeys(ModelValue.java:139) > at org.jboss.dmr.ModelNode.keys(ModelNode.java:1378) > at org.jboss.as.cli.impl.ValueTypeCompleter$ValueTypeCallbackHandler.getCandidates(ValueTypeCompleter.java:502) > at org.jboss.as.cli.impl.ValueTypeCompleter.complete(ValueTypeCompleter.java:332) > at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:254) > at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:74) > at org.jboss.as.cli.CommandCompleter.doComplete(CommandCompleter.java:134) > at org.jboss.as.cli.CommandCompleter.complete(CommandCompleter.java:63) > at org.jboss.as.cli.impl.Console$Factory$1$1.complete(Console.java:143) > at org.jboss.aesh.console.AeshCompletionHandler.complete(AeshCompletionHandler.java:155) > at org.jboss.aesh.console.AeshInputProcessor.complete(AeshInputProcessor.java:423) > at org.jboss.aesh.console.AeshInputProcessor.parseOperation(AeshInputProcessor.java:165) > at org.jboss.aesh.console.Console.processInternalOperation(Console.java:773) > at org.jboss.aesh.console.Console.execute(Console.java:733) > at org.jboss.aesh.console.Console.access$900(Console.java:73) > at org.jboss.aesh.console.Console$6.run(Console.java:642) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > {code} > Happens only for certain strings, e.g. > * {{:composite(steps=\[{a<TAB>}} fails > * {{:composite(steps=\[a<TAB>}} doesn't fail (suggests "," or "]") > * {{:composite(steps=\[a=<TAB>}} fails -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1771) CLI - Tab completion in composite operation throws IAE

by Michal Petrov (JIRA)

Michal Petrov created WFCORE-1771: ------------------------------------- Summary: CLI - Tab completion in composite operation throws IAE Key: WFCORE-1771 URL: https://issues.jboss.org/browse/WFCORE-1771 Project: WildFly Core Issue Type: Bug Components: CLI Affects Versions: 3.0.0.Alpha7 Reporter: Michal Petrov Assignee: Alexey Loubyansky Getting an exception when trying to make a composite operation {code} [standalone@localhost:9990 /] :composite(steps=[{aException in thread "Aesh Process Loop 1409160703" java.lang.IllegalArgumentException at org.jboss.dmr.ModelValue.getKeys(ModelValue.java:139) at org.jboss.dmr.ModelNode.keys(ModelNode.java:1378) at org.jboss.as.cli.impl.ValueTypeCompleter$ValueTypeCallbackHandler.getCandidates(ValueTypeCompleter.java:502) at org.jboss.as.cli.impl.ValueTypeCompleter.complete(ValueTypeCompleter.java:332) at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:254) at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:74) at org.jboss.as.cli.CommandCompleter.doComplete(CommandCompleter.java:134) at org.jboss.as.cli.CommandCompleter.complete(CommandCompleter.java:63) at org.jboss.as.cli.impl.Console$Factory$1$1.complete(Console.java:143) at org.jboss.aesh.console.AeshCompletionHandler.complete(AeshCompletionHandler.java:155) at org.jboss.aesh.console.AeshInputProcessor.complete(AeshInputProcessor.java:423) at org.jboss.aesh.console.AeshInputProcessor.parseOperation(AeshInputProcessor.java:165) at org.jboss.aesh.console.Console.processInternalOperation(Console.java:773) at org.jboss.aesh.console.Console.execute(Console.java:733) at org.jboss.aesh.console.Console.access$900(Console.java:73) at org.jboss.aesh.console.Console$6.run(Console.java:642) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) {code} Happens only for certain strings, e.g. * {{:composite(steps=\[{a<TAB>}} fails * {{:composite(steps=\[a<TAB>}} doesn't fail (suggests "," or "]") * {{:composite(steps=\[a=<TAB>}} fails -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1279) [GSS] compilation of spreadsheet fails with specific condition

by Hiroko Miura (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1279?page=com.atlassian.jira.plugi... ] Hiroko Miura updated DROOLS-1279: --------------------------------- Fix Version/s: 6.5.0.Final Labels: support (was: ) > [GSS] compilation of spreadsheet fails with specific condition > -------------------------------------------------------------- > > Key: DROOLS-1279 > URL: https://issues.jboss.org/browse/DROOLS-1279 > Project: Drools > Issue Type: Bug > Components: build, decision tables > Affects Versions: 6.4.0.Final > Reporter: Hiroko Miura > Assignee: Petr Široký > Labels: support > Fix For: 6.5.0.Final > > Attachments: repoduser.zip > > > Reproducer is attached.with problematic spredsheet named SampleNG.xml. > Compilation of this fails with the following error. > java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=dtables/SampleNG.xls, line=8, column=0 > text=Unable to Analyse Expression checktest == AAA: > [Error: unable to resolve method using strict-mode: com.sample.DecisionTableTest$Message.AAA()] > [Near : {... checktest == AAA ....}] > because the following DRL is generated. > rule "HelloWorld_12" > when > m:Message(checktest in(AAA), (checktest != "dummy") == "false") > ... > i.e. double quotation of value ("AAA") specified in the cell is removed. > > If D column does not exist like Sample.xml(also included in reproducer) or D column is modified like SampleOK.xml, this does not happen. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-952) Use WildFly Common for null param checks

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-952?page=com.atlassian.jira.plugin... ] Brian Stansberry reassigned WFCORE-952: --------------------------------------- Assignee: David Lloyd Resolution: Done > Use WildFly Common for null param checks > ---------------------------------------- > > Key: WFCORE-952 > URL: https://issues.jboss.org/browse/WFCORE-952 > Project: WildFly Core > Issue Type: Task > Reporter: David Lloyd > Assignee: David Lloyd > Priority: Minor > Fix For: 3.0.0.Alpha8 > > > For each module, do the following: > * Locate any/all null param check methods in the log msg > * Replace them with calls to org.wildfly.common.Assert#checkNotNullParam or related method as needed > * Replace the old null param check method with a comment that reserves the ID and shows that it was previously used for that purpose -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1280) further document state machine, thread-safety and include diagrams

by Matteo Mortari (JIRA)

Matteo Mortari created DROOLS-1280: -------------------------------------- Summary: further document state machine, thread-safety and include diagrams Key: DROOLS-1280 URL: https://issues.jboss.org/browse/DROOLS-1280 Project: Drools Issue Type: Enhancement Reporter: Matteo Mortari Assignee: Matteo Mortari Priority: Minor Spin-off remaining linked documentation work from [DROOLS-1272] for: Include docs on state machine and thread safety Flow charts and state diagrams Ensure the N&N section describing state machine and thread-safety is correctly reflected in section of the manual. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1272) document Rule Execution Modes - no doc exists for fireUntilHalt

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1272?page=com.atlassian.jira.plugi... ] Matteo Mortari updated DROOLS-1272: ----------------------------------- Comment: was deleted (was: TBD: * Include docs on state machine and thread safety * flow charts and state diagrams ?) > document Rule Execution Modes - no doc exists for fireUntilHalt > --------------------------------------------------------------- > > Key: DROOLS-1272 > URL: https://issues.jboss.org/browse/DROOLS-1272 > Project: Drools > Issue Type: Enhancement > Components: docs > Affects Versions: 6.1.0.Final, 6.2.0.Final, 6.3.0.Final, 6.4.0.Final > Reporter: Matteo Mortari > Assignee: Matteo Mortari > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1234) Monitoring framework improvements

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1234?page=com.atlassian.jira.plugi... ] Matteo Mortari commented on DROOLS-1234: ---------------------------------------- Commits performed at this DROOLS-1234 level for N&N documentation update to reflect all changes in sub-tasks. > Monitoring framework improvements > --------------------------------- > > Key: DROOLS-1234 > URL: https://issues.jboss.org/browse/DROOLS-1234 > Project: Drools > Issue Type: Enhancement > Components: core engine, kie server > Affects Versions: 6.4.0.Final > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Fix For: 6.5.0.Final, 7.0.0.Final > > > For the following tasks: > # MBean naming rework > # MBean aggregation of statistics mechanism, without putting overhead on the running KieSessions > # currently statistics are provided as-a-List for historical reasons, but as JMX support Table, rework them as a JMX Table -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1269) RHQ / JON plug-in display wrong hierarchy and repeatedly nesting KieSession under KieBase

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1269?page=com.atlassian.jira.plugi... ] Matteo Mortari commented on DROOLS-1269: ---------------------------------------- Fixed for correct nesting and correct hierarchy display by cascading manually the {{\{kcontainerId\}}} variable. Specifically, the hierarchy now is: {code} KieContainer + KieBase + KieSession {code} The KieBase: take the {{\{kcontainerId\}}} variable from the parent, and re-exposes it as a new variable "kcId", at the level of the KieBase itself. In turn, now the KieSession can access to {{\{kcId\}}} variable, effectively and for any pragmatic effect representing the KieContainer from the grand-parent. Functional test result on RHQ / JON : !screenshot-1.png|thumbnail! In the screenshot, the JVisualVM is show the correct nesting of the KieSession under their respective KieBases. Now the hierarchy is correctly reflected on the RHQ/JON plug-in, and the KieSession are correctly nested only under the KieBase they actually belongs to. > RHQ / JON plug-in display wrong hierarchy and repeatedly nesting KieSession under KieBase > ----------------------------------------------------------------------------------------- > > Key: DROOLS-1269 > URL: https://issues.jboss.org/browse/DROOLS-1269 > Project: Drools > Issue Type: Bug > Components: integration > Affects Versions: 6.1.0.Final, 6.2.0.Final, 6.3.0.Final, 6.4.0.Final > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Minor > Fix For: 6.5.0.Final, 7.0.0.Final > > Attachments: rhqjon.png, screenshot-1.png > > > ... regardless of the real KieBase they actually belong to. > Ref example screenshot: > !rhqjon.png|thumbnail! -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1269) RHQ / JON plug-in display wrong hierarchy and repeatedly nesting KieSession under KieBase

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1269?page=com.atlassian.jira.plugi... ] Matteo Mortari updated DROOLS-1269: ----------------------------------- Fix Version/s: 6.5.0.Final 7.0.0.Final > RHQ / JON plug-in display wrong hierarchy and repeatedly nesting KieSession under KieBase > ----------------------------------------------------------------------------------------- > > Key: DROOLS-1269 > URL: https://issues.jboss.org/browse/DROOLS-1269 > Project: Drools > Issue Type: Bug > Components: integration > Affects Versions: 6.1.0.Final, 6.2.0.Final, 6.3.0.Final, 6.4.0.Final > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Minor > Fix For: 6.5.0.Final, 7.0.0.Final > > Attachments: rhqjon.png, screenshot-1.png > > > ... regardless of the real KieBase they actually belong to. > Ref example screenshot: > !rhqjon.png|thumbnail! -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1269) RHQ / JON plug-in display wrong hierarchy and repeatedly nesting KieSession under KieBase

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1269?page=com.atlassian.jira.plugi... ] Matteo Mortari updated DROOLS-1269: ----------------------------------- Attachment: screenshot-1.png > RHQ / JON plug-in display wrong hierarchy and repeatedly nesting KieSession under KieBase > ----------------------------------------------------------------------------------------- > > Key: DROOLS-1269 > URL: https://issues.jboss.org/browse/DROOLS-1269 > Project: Drools > Issue Type: Bug > Components: integration > Affects Versions: 6.1.0.Final, 6.2.0.Final, 6.3.0.Final, 6.4.0.Final > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Minor > Attachments: rhqjon.png, screenshot-1.png > > > ... regardless of the real KieBase they actually belong to. > Ref example screenshot: > !rhqjon.png|thumbnail! -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1237) MBean currently provide statistics as-a-List for historical reasons, but as JMX support Table, rework them as a JMX Table

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1237?page=com.atlassian.jira.plugi... ] Matteo Mortari updated DROOLS-1237: ----------------------------------- Component/s: core engine kie server > MBean currently provide statistics as-a-List for historical reasons, but as JMX support Table, rework them as a JMX Table > ------------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-1237 > URL: https://issues.jboss.org/browse/DROOLS-1237 > Project: Drools > Issue Type: Sub-task > Components: core engine, kie server > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Fix For: 6.5.0.Final, 7.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1237) MBean currently provide statistics as-a-List for historical reasons, but as JMX support Table, rework them as a JMX Table

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1237?page=com.atlassian.jira.plugi... ] Matteo Mortari updated DROOLS-1237: ----------------------------------- Fix Version/s: 6.5.0.Final 7.0.0.Final > MBean currently provide statistics as-a-List for historical reasons, but as JMX support Table, rework them as a JMX Table > ------------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-1237 > URL: https://issues.jboss.org/browse/DROOLS-1237 > Project: Drools > Issue Type: Sub-task > Components: core engine, kie server > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Fix For: 6.5.0.Final, 7.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1236) MBean aggregation of statistics mechanism, without putting overhead on the running KieSessions

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1236?page=com.atlassian.jira.plugi... ] Matteo Mortari updated DROOLS-1236: ----------------------------------- Fix Version/s: 6.5.0.Final 7.0.0.Final > MBean aggregation of statistics mechanism, without putting overhead on the running KieSessions > ---------------------------------------------------------------------------------------------- > > Key: DROOLS-1236 > URL: https://issues.jboss.org/browse/DROOLS-1236 > Project: Drools > Issue Type: Sub-task > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Fix For: 6.5.0.Final, 7.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1236) MBean aggregation of statistics mechanism, without putting overhead on the running KieSessions

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1236?page=com.atlassian.jira.plugi... ] Matteo Mortari updated DROOLS-1236: ----------------------------------- Component/s: core engine kie server > MBean aggregation of statistics mechanism, without putting overhead on the running KieSessions > ---------------------------------------------------------------------------------------------- > > Key: DROOLS-1236 > URL: https://issues.jboss.org/browse/DROOLS-1236 > Project: Drools > Issue Type: Sub-task > Components: core engine, kie server > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Fix For: 6.5.0.Final, 7.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2099) TP: one single thread pool

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2099?page=com.atlassian.jira.plugin.... ] Bela Ban reopened JGRP-2099: ---------------------------- Investigate using ForkJoinPool instead of ThreadPoolExecutor (see Dan's comment) > TP: one single thread pool > -------------------------- > > Key: JGRP-2099 > URL: https://issues.jboss.org/browse/JGRP-2099 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently, TP has 4 thread pools: > * OOB > * Regular > * Internal > * Timer (used by TimeScheduler3) > The reason for this was mainly to prevent certain types of tasks from getting dropped due to a full pool. However, this can be changed by (1) making the pool have no queue and (2) handling the RejectedExecutionException (e.g. by spawning a new thread, or upping the max-threads value) for (e.g.) INTERNAL messages and timer tasks. > This not only simplify configuration (1 config section rather than 4), but also reduces the size of TP (removal of accessors, attributes). Things might also become a bit faster as a result. > The new common pool would have the following characteristics: > * Default rejection policy of "abort" (so we can handle pool exhaustion) > * No queue ({{SynchronousQueue}}), so new threads up to max-threads are created if none of the existing ones are available. The queue config attribute will be removed > * Catch RejectedExecutionException for INTERNAL messages and timer tasks. A new thread will be spawned on a RejectedExecutionException. This will be used mainly by INTERNAL messages and timer tasks > * Alternatively, we could increase max-threads (if {{ergonomics==true}}) if we get a constant rate of these exceptions -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2099) TP: one single thread pool

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2099?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2099: -------------------------------- Thanks for the input, Dan, I'll take a look at FJP. > TP: one single thread pool > -------------------------- > > Key: JGRP-2099 > URL: https://issues.jboss.org/browse/JGRP-2099 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently, TP has 4 thread pools: > * OOB > * Regular > * Internal > * Timer (used by TimeScheduler3) > The reason for this was mainly to prevent certain types of tasks from getting dropped due to a full pool. However, this can be changed by (1) making the pool have no queue and (2) handling the RejectedExecutionException (e.g. by spawning a new thread, or upping the max-threads value) for (e.g.) INTERNAL messages and timer tasks. > This not only simplify configuration (1 config section rather than 4), but also reduces the size of TP (removal of accessors, attributes). Things might also become a bit faster as a result. > The new common pool would have the following characteristics: > * Default rejection policy of "abort" (so we can handle pool exhaustion) > * No queue ({{SynchronousQueue}}), so new threads up to max-threads are created if none of the existing ones are available. The queue config attribute will be removed > * Catch RejectedExecutionException for INTERNAL messages and timer tasks. A new thread will be spawned on a RejectedExecutionException. This will be used mainly by INTERNAL messages and timer tasks > * Alternatively, we could increase max-threads (if {{ergonomics==true}}) if we get a constant rate of these exceptions -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2099) TP: one single thread pool

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/JGRP-2099?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on JGRP-2099: ------------------------------------ If you want to use a single thread pool, I recommend looking into {{ForkJoinPool}} - that's the one I'm thinking of switching Infinispan to. One of the things I like about FJP is that when you have to block, you can use {{ManagedBlocker}} to tell the pool it should allocate a new thread. FJP is also much better than using a classical {{ThreadPoolExecutor}} with a {{SynchronousQueue}} when it comes to context switches: {{SQ.add()}} has to block until a worker thread is free, so for each task either the submitter wakes up a worker, or the submitter parks, then a worker finishes a task and wakes up the submitter. When you use a FJP pool, and the submitter thread is from the same FJP, it will just add the task to its own queue, and the task may be processed without involving any other threads. I've read a long time ago about about an extreme version of this, a variation of {{WithinThreadExecutor}} that queues the task in a thread-local and always runs the tasks on the same thread. (Well, if you run on your own {{Thread}} subclass, you don't technically need a thread-local.) Sounds very interesting, but I think the FJP approach is more practical :) > TP: one single thread pool > -------------------------- > > Key: JGRP-2099 > URL: https://issues.jboss.org/browse/JGRP-2099 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently, TP has 4 thread pools: > * OOB > * Regular > * Internal > * Timer (used by TimeScheduler3) > The reason for this was mainly to prevent certain types of tasks from getting dropped due to a full pool. However, this can be changed by (1) making the pool have no queue and (2) handling the RejectedExecutionException (e.g. by spawning a new thread, or upping the max-threads value) for (e.g.) INTERNAL messages and timer tasks. > This not only simplify configuration (1 config section rather than 4), but also reduces the size of TP (removal of accessors, attributes). Things might also become a bit faster as a result. > The new common pool would have the following characteristics: > * Default rejection policy of "abort" (so we can handle pool exhaustion) > * No queue ({{SynchronousQueue}}), so new threads up to max-threads are created if none of the existing ones are available. The queue config attribute will be removed > * Catch RejectedExecutionException for INTERNAL messages and timer tasks. A new thread will be spawned on a RejectedExecutionException. This will be used mainly by INTERNAL messages and timer tasks > * Alternatively, we could increase max-threads (if {{ergonomics==true}}) if we get a constant rate of these exceptions -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2100) Timer: don't submit non-blocking tasks to the thread pool

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/JGRP-2100?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on JGRP-2100: ------------------------------------ I see a potential problem with this approach: even if a task is non-blocking, it could use a lot of CPU. Using the same example of a {{UNICAST3}} retransmission task, if the xmit table is big enough, iterating through the receiver table for 100s of receivers could use too much of the timer thread's CPU allotment. Having said that, I think the most flexible approach would be to run all tasks on the timer's single thread, and have the tasks themselves decide whether they need to delegate some work to another thread or not. They could even return a `CompletableFuture<Void>`, if you want to make sure you don't re-run the same periodic task until the previous run has finished. > Timer: don't submit non-blocking tasks to the thread pool > --------------------------------------------------------- > > Key: JGRP-2100 > URL: https://issues.jboss.org/browse/JGRP-2100 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently, {{TimeScheduler3}} has a runner thread which continually takes tasks from a {{DelayQueue}} and submits them to the thread pool. > If a task is non-blocking, this is not necessary; instead the task can be run on the runner's thread. This will reduce the number of thread created in the thread pool. > Investigate whether it is possible to mark tasks as blocking or non-blocking. Example: an {{AgeOutCache}} task is always non-blocking. A {{UNICAST3}} or {{NAKACK2}} retransmission task is (potentially) blocking if {{TCP}} is used as transport and non-blocking if for example {{UDP}} or {{TCP_NIO2}} are used. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2100) Timer: don't submit non-blocking tasks to the thread pool

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2100?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2100: -------------------------------- Instead of subclassing {{Runnable}} with something like {{BlockableRunnable}}, an additional parameter {{can_block}} will be added to methods {{execute()}}, {{schedule()}}, {{scheduleWithFixedDelay()}}, {{scheduleAtFixedRate()}} and {{scheduleRecurringTask()}}. Extending {{Runnable}} would not allow for simple lambdas to be used, but instead inner classes would have to be created. > Timer: don't submit non-blocking tasks to the thread pool > --------------------------------------------------------- > > Key: JGRP-2100 > URL: https://issues.jboss.org/browse/JGRP-2100 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently, {{TimeScheduler3}} has a runner thread which continually takes tasks from a {{DelayQueue}} and submits them to the thread pool. > If a task is non-blocking, this is not necessary; instead the task can be run on the runner's thread. This will reduce the number of thread created in the thread pool. > Investigate whether it is possible to mark tasks as blocking or non-blocking. Example: an {{AgeOutCache}} task is always non-blocking. A {{UNICAST3}} or {{NAKACK2}} retransmission task is (potentially) blocking if {{TCP}} is used as transport and non-blocking if for example {{UDP}} or {{TCP_NIO2}} are used. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1770) Wildfly 10.1.0.FINAL does not start as a windows service

by Arthur Borsboom (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1770?page=com.atlassian.jira.plugi... ] Arthur Borsboom commented on WFCORE-1770: ----------------------------------------- Hi Tom, I see you have closed this bug report without a comment. Does this mean that this is fixed? When I download this file: http://download.jboss.org/wildfly/10.1.0.Final/wildfly-10.1.0.Final.zip the file wildfly-10.1.0.Final/docs/contrib/scripts/service/service.bat still contains these two lines {code:title=wildfly-10.1.0.Final/docs/contrib/scripts/service/service.bat|borderStyle=solid} rem NO quotes around the description here ! set DESCRIPTION="WildFly Application Server" {code} which should be {code:title=wildfly-10.1.0.Final/docs/contrib/scripts/service/service.bat|borderStyle=solid} set DESCRIPTION=WildFly Application Server {code} > Wildfly 10.1.0.FINAL does not start as a windows service > -------------------------------------------------------- > > Key: WFCORE-1770 > URL: https://issues.jboss.org/browse/WFCORE-1770 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Reporter: Arthur Borsboom > Assignee: Tomaz Cerar > Priority: Minor > Fix For: 3.0.0.Alpha6 > > > The service.bat batch file to install Wildfly as a WIndows Service (still) contains a small error, preventing the service being added correctly. > This bug has been reported before and also has been reported as fixed. However the bug is still there. > WFCORE-1719 > The funny thing is that the batch file even describes in a REM statement that the line "SET DESCRIPTION" should not contain quotes. So, the fix is described, but just not applied. :) > Please remove the quotes in the next release. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6402) EJBs accessible too early (spec violation)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-6402?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-6402: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1319040, https://bugzilla.redhat.com/show_bug.cgi?id=1350355, https://bugzilla.redhat.com/show_bug.cgi?id=1310908, https://bugzilla.redhat.com/show_bug.cgi?id=1359884 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1319040, https://bugzilla.redhat.com/show_bug.cgi?id=1350355, https://bugzilla.redhat.com/show_bug.cgi?id=1310908) > EJBs accessible too early (spec violation) > ------------------------------------------ > > Key: WFLY-6402 > URL: https://issues.jboss.org/browse/WFLY-6402 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final > Reporter: Brad Maxwell > Assignee: Fedor Gavrilov > Labels: downstream_dependency > Attachments: auto-test-reproducer.zip > > > {code} > EJB 3.1 spec, section 4.8.1: > "If the Startup annotation appears on the Singleton bean class or if the Singleton has been designated via the deployment descriptor as requiring eager initialization, the container must initialize the Singleton bean instance during the application startup sequence. The container must initialize all such startup-time Singletons before any external client requests (that is, client requests originating outside of the application) are delivered to any enterprise bean components in the application. > {code} > Wildlfy does not implement this correctly, and allows calls to other EJBs before a @Startup @Singleton finishes its @PostConstruct call. > This Jira ticket handles two PR's on WFLY: > https://github.com/wildfly/wildfly/pull/8824 (that is already merged) > and https://github.com/wildfly/wildfly/pull/8989 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7071) Changing default-realm of Elytron security-domain through CLI can put the server configuration to wrong state

by Harald Pehl (JIRA)

[ https://issues.jboss.org/browse/WFLY-7071?page=com.atlassian.jira.plugin.... ] Harald Pehl commented on WFLY-7071: ----------------------------------- Agreed. We should add some kind of client side validation for default-realms of security domains. I filed HAL-1179 to track this. > Changing default-realm of Elytron security-domain through CLI can put the server configuration to wrong state > ------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7071 > URL: https://issues.jboss.org/browse/WFLY-7071 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Jan Kalina > > Values of write-attribute operation for default-realm of Elytron security-domain are not checked. It means that CLI allows users to set application server to wrong state. The same happens if realm, which is considered as default-realm, is removed from used security-domain realms. CLI should deny write attribute operation with wrong value (in the same way as it works for another security-domain attributes). > After reload, server is not started and following logs occur in console: > {code} > ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 25) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("security-domain" => "ApplicationDomain") > ]) - failure description: "WFLYELY00013: The default_realm 'WrongRealm' is not in the list or realms referenced by this domain." > ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem elytron boot operations" > ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: "\"WFLYCTL0193: Failed executing subsystem elytron boot operations\"" > FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7065) Wrong description of logical-role-mapper in model

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7065?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-7065: -------------------------------------- Assignee: Jan Kalina (was: Darran Lofthouse) > Wrong description of logical-role-mapper in model > ------------------------------------------------- > > Key: WFLY-7065 > URL: https://issues.jboss.org/browse/WFLY-7065 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > > In output of > {noformat} > /subsystem=elytron:read-resource-description(recursive=true) > {noformat} > , there is wrong description of logical-role-mapper _A role mapper definition where a constant set of roles is always returned._ , what is probably copied from constant-role-mapper. > In XSD, there is more proper description _A RoleMapper definition for a RoleMapper that performs a logical operation using two refereced RoleMappers._ -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7066) Wrong description of simple-regex-realm-mapper / mapped-regex-realm-mapper in model

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7066?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-7066: -------------------------------------- Assignee: Jan Kalina (was: Darran Lofthouse) > Wrong description of simple-regex-realm-mapper / mapped-regex-realm-mapper in model > ----------------------------------------------------------------------------------- > > Key: WFLY-7066 > URL: https://issues.jboss.org/browse/WFLY-7066 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > > In output of {noformat}/subsystem=elytron:read-resource-description(recursive=true){noformat} , there is wrong description of simple-regex-realm-mapper / mapped-regex-realm-mapper _"Definition of a custom RealmMapper"_ , what is probably copied from custom-realm-mapper. > In XSD, there is more proper > * mapped-regex-realm-mapper: _"A RealmMapper implementaion that first uses a regular expression to extract the realm name, this is then converted using the configured mapping of realm names."_ > * simple-regex-realm-mapper: _"A simple RealmMapper definition that attempts to extract the realm name using the capture group from the regular expression, if that does not provide a match then the delegate RealmMapper is used instead."_ -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7071) Changing default-realm of Elytron security-domain through CLI can put the server configuration to wrong state

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7071?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-7071: ---------------------------------------- [~harald.pehl] / [~claudio4j] In this case the default-realm attribute in the security domain is required to reference one of the referenced security realms, we need some checking in our subsystem to ensure the selected realm is already referenced but as this is slightly outside capabilities and requirements I think worth flagging in case anything else is needed to make it easier to maintain integrity from admin clients. > Changing default-realm of Elytron security-domain through CLI can put the server configuration to wrong state > ------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7071 > URL: https://issues.jboss.org/browse/WFLY-7071 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Jan Kalina > > Values of write-attribute operation for default-realm of Elytron security-domain are not checked. It means that CLI allows users to set application server to wrong state. The same happens if realm, which is considered as default-realm, is removed from used security-domain realms. CLI should deny write attribute operation with wrong value (in the same way as it works for another security-domain attributes). > After reload, server is not started and following logs occur in console: > {code} > ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 25) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("security-domain" => "ApplicationDomain") > ]) - failure description: "WFLYELY00013: The default_realm 'WrongRealm' is not in the list or realms referenced by this domain." > ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem elytron boot operations" > ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: "\"WFLYCTL0193: Failed executing subsystem elytron boot operations\"" > FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7071) Changing default-realm of Elytron security-domain through CLI can put the server configuration to wrong state

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7071?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-7071: -------------------------------------- Assignee: Jan Kalina (was: Darran Lofthouse) > Changing default-realm of Elytron security-domain through CLI can put the server configuration to wrong state > ------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7071 > URL: https://issues.jboss.org/browse/WFLY-7071 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Jan Kalina > > Values of write-attribute operation for default-realm of Elytron security-domain are not checked. It means that CLI allows users to set application server to wrong state. The same happens if realm, which is considered as default-realm, is removed from used security-domain realms. CLI should deny write attribute operation with wrong value (in the same way as it works for another security-domain attributes). > After reload, server is not started and following logs occur in console: > {code} > ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 25) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("security-domain" => "ApplicationDomain") > ]) - failure description: "WFLYELY00013: The default_realm 'WrongRealm' is not in the list or realms referenced by this domain." > ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem elytron boot operations" > ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: "\"WFLYCTL0193: Failed executing subsystem elytron boot operations\"" > FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1770) Wildfly 10.1.0.FINAL does not start as a windows service

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1770?page=com.atlassian.jira.plugi... ] Tomaz Cerar closed WFCORE-1770. ------------------------------- Fix Version/s: 3.0.0.Alpha6 Assignee: Tomaz Cerar (was: Jason Greene) Resolution: Duplicate Issue fixed in WFCORE-1719 > Wildfly 10.1.0.FINAL does not start as a windows service > -------------------------------------------------------- > > Key: WFCORE-1770 > URL: https://issues.jboss.org/browse/WFCORE-1770 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Reporter: Arthur Borsboom > Assignee: Tomaz Cerar > Priority: Minor > Fix For: 3.0.0.Alpha6 > > > The service.bat batch file to install Wildfly as a WIndows Service (still) contains a small error, preventing the service being added correctly. > This bug has been reported before and also has been reported as fixed. However the bug is still there. > WFCORE-1719 > The funny thing is that the batch file even describes in a REM statement that the line "SET DESCRIPTION" should not contain quotes. So, the fix is described, but just not applied. :) > Please remove the quotes in the next release. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1770) Wildfly 10.1.0.FINAL does not start as a windows service

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1770?page=com.atlassian.jira.plugi... ] Tomaz Cerar updated WFCORE-1770: -------------------------------- Description: The service.bat batch file to install Wildfly as a WIndows Service (still) contains a small error, preventing the service being added correctly. This bug has been reported before and also has been reported as fixed. However the bug is still there. WFCORE-1719 The funny thing is that the batch file even describes in a REM statement that the line "SET DESCRIPTION" should not contain quotes. So, the fix is described, but just not applied. :) Please remove the quotes in the next release. was: The service.bat batch file to install Wildfly as a WIndows Service (still) contains a small error, preventing the service being added correctly. This bug has been reported before and also has been reported as fixed. However the bug is still there. https://issues.jboss.org/browse/WFCORE-1719 The funny thing is that the batch file even describes in a REM statement that the line "SET DESCRIPTION" should not contain quotes. So, the fix is described, but just not applied. :) Please remove the quotes in the next release. > Wildfly 10.1.0.FINAL does not start as a windows service > -------------------------------------------------------- > > Key: WFCORE-1770 > URL: https://issues.jboss.org/browse/WFCORE-1770 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Reporter: Arthur Borsboom > Assignee: Jason Greene > Priority: Minor > Fix For: 3.0.0.Alpha6 > > > The service.bat batch file to install Wildfly as a WIndows Service (still) contains a small error, preventing the service being added correctly. > This bug has been reported before and also has been reported as fixed. However the bug is still there. > WFCORE-1719 > The funny thing is that the batch file even describes in a REM statement that the line "SET DESCRIPTION" should not contain quotes. So, the fix is described, but just not applied. :) > Please remove the quotes in the next release. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1770) Wildfly 10.1.0.FINAL does not start as a windows service

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1770?page=com.atlassian.jira.plugi... ] Tomaz Cerar moved WFLY-7072 to WFCORE-1770: ------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-1770 (was: WFLY-7072) Component/s: Scripts (was: Server) Affects Version/s: (was: 10.1.0.Final) > Wildfly 10.1.0.FINAL does not start as a windows service > -------------------------------------------------------- > > Key: WFCORE-1770 > URL: https://issues.jboss.org/browse/WFCORE-1770 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Reporter: Arthur Borsboom > Assignee: Jason Greene > Priority: Minor > > The service.bat batch file to install Wildfly as a WIndows Service (still) contains a small error, preventing the service being added correctly. > This bug has been reported before and also has been reported as fixed. However the bug is still there. > https://issues.jboss.org/browse/WFCORE-1719 > The funny thing is that the batch file even describes in a REM statement that the line "SET DESCRIPTION" should not contain quotes. So, the fix is described, but just not applied. :) > Please remove the quotes in the next release. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-271) EJB authentication via Kerberos does not work with wildfly-security-api

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-271?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-271: --------------------------------- Priority: Major (was: Critical) > EJB authentication via Kerberos does not work with wildfly-security-api > ----------------------------------------------------------------------- > > Key: ELY-271 > URL: https://issues.jboss.org/browse/ELY-271 > Project: WildFly Elytron > Issue Type: Bug > Components: SASL > Affects Versions: 1.0.0.Alpha3 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Fix For: 1.1.0.CR1 > > Attachments: client.zip, server.jar > > > EJB authentication via Kerberos does not work for projects using EJB Client with dependency on org.wildfly:wildfly-security-api. EJB invocation failed with exception: > {noformat} > java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed: > GSSAPI: javax.security.sasl.SaslException: ELY05108: [GSSAPI] Unable to create response token [Caused by javax.security.sasl.SaslException: ELY05127: [GSSAPI] No security layer supported by server but maximum message size received: "65536"] > at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:92) > at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:80) > at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51) > at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:158) > at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:115) > at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createIdentifiableEjbClientContext(EjbNamingContext.java:258) > at org.jboss.ejb.client.naming.ejb.EjbNamingContext.setupScopedEjbClientContextIfNeeded(EjbNamingContext.java:123) > at org.jboss.ejb.client.naming.ejb.EjbNamingContext.<init>(EjbNamingContext.java:98) > at org.jboss.ejb.client.naming.ejb.ejbURLContextFactory.getObjectInstance(ejbURLContextFactory.java:38) > at javax.naming.spi.NamingManager.getURLObject(NamingManager.java:601) > at javax.naming.spi.NamingManager.getURLContext(NamingManager.java:550) > at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:345) > at javax.naming.InitialContext.lookup(InitialContext.java:417) > at client.Client.main(Client.java:19) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297) > at java.lang.Thread.run(Thread.java:745) > Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed: > GSSAPI: javax.security.sasl.SaslException: ELY05108: [GSSAPI] Unable to create response token [Caused by javax.security.sasl.SaslException: ELY05127: [GSSAPI] No security layer supported by server but maximum message size received: "65536"] > at org.jboss.remoting3.remote.ClientConnectionOpenListener.allMechanismsFailed(ClientConnectionOpenListener.java:114) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:393) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:243) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:199) > at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:113) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) > 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:88) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) > at ...asynchronous invocation...(Unknown Source) > at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:388) > at org.jboss.ejb.client.remoting.EndpointPool$PooledEndpoint.connect(EndpointPool.java:192) > at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:153) > at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:133) > at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:78) > ... 18 more > {noformat} > Note: > Dependency org.wildfly:wildfly-security-api has transitive dependency on org.wildfly.security:wildfly-elytron. Artifact wildfly-elytron using service org.wildfly.security.sasl.gssapi.GssapiClientFactory which is added via Java SPI as javax.security.sasl.SaslClientService. Adding this service causes that Kerberos authentication is handled by org.wildfly.security.sasl.gssapi.GssapiClient which leads to authentication failures. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1279) [GSS] compilation of spreadsheet fails with specific condition

by Hiroko Miura (JIRA)

Hiroko Miura created DROOLS-1279: ------------------------------------ Summary: [GSS] compilation of spreadsheet fails with specific condition Key: DROOLS-1279 URL: https://issues.jboss.org/browse/DROOLS-1279 Project: Drools Issue Type: Bug Components: build, decision tables Affects Versions: 6.4.0.Final Reporter: Hiroko Miura Assignee: Petr Široký Attachments: repoduser.zip Reproducer is attached.with problematic spredsheet named SampleNG.xml. Compilation of this fails with the following error. java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=dtables/SampleNG.xls, line=8, column=0 text=Unable to Analyse Expression checktest == AAA: [Error: unable to resolve method using strict-mode: com.sample.DecisionTableTest$Message.AAA()] [Near : {... checktest == AAA ....}] because the following DRL is generated. rule "HelloWorld_12" when m:Message(checktest in(AAA), (checktest != "dummy") == "false") ... i.e. double quotation of value ("AAA") specified in the cell is removed. If D column does not exist like Sample.xml(also included in reproducer) or D column is modified like SampleOK.xml, this does not happen. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-271) EJB authentication via Kerberos does not work with wildfly-security-api

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/ELY-271?page=com.atlassian.jira.plugin.sy... ] Ondrej Lukas commented on ELY-271: ---------------------------------- We hit this issue in EAP 7.1.0.DR4. Hence I increase priority. > EJB authentication via Kerberos does not work with wildfly-security-api > ----------------------------------------------------------------------- > > Key: ELY-271 > URL: https://issues.jboss.org/browse/ELY-271 > Project: WildFly Elytron > Issue Type: Bug > Components: SASL > Affects Versions: 1.0.0.Alpha3 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Minor > Fix For: 1.1.0.CR1 > > Attachments: client.zip, server.jar > > > EJB authentication via Kerberos does not work for projects using EJB Client with dependency on org.wildfly:wildfly-security-api. EJB invocation failed with exception: > {noformat} > java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed: > GSSAPI: javax.security.sasl.SaslException: ELY05108: [GSSAPI] Unable to create response token [Caused by javax.security.sasl.SaslException: ELY05127: [GSSAPI] No security layer supported by server but maximum message size received: "65536"] > at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:92) > at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:80) > at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51) > at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:158) > at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:115) > at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createIdentifiableEjbClientContext(EjbNamingContext.java:258) > at org.jboss.ejb.client.naming.ejb.EjbNamingContext.setupScopedEjbClientContextIfNeeded(EjbNamingContext.java:123) > at org.jboss.ejb.client.naming.ejb.EjbNamingContext.<init>(EjbNamingContext.java:98) > at org.jboss.ejb.client.naming.ejb.ejbURLContextFactory.getObjectInstance(ejbURLContextFactory.java:38) > at javax.naming.spi.NamingManager.getURLObject(NamingManager.java:601) > at javax.naming.spi.NamingManager.getURLContext(NamingManager.java:550) > at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:345) > at javax.naming.InitialContext.lookup(InitialContext.java:417) > at client.Client.main(Client.java:19) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297) > at java.lang.Thread.run(Thread.java:745) > Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed: > GSSAPI: javax.security.sasl.SaslException: ELY05108: [GSSAPI] Unable to create response token [Caused by javax.security.sasl.SaslException: ELY05127: [GSSAPI] No security layer supported by server but maximum message size received: "65536"] > at org.jboss.remoting3.remote.ClientConnectionOpenListener.allMechanismsFailed(ClientConnectionOpenListener.java:114) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:393) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:243) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:199) > at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:113) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) > 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:88) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) > at ...asynchronous invocation...(Unknown Source) > at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:388) > at org.jboss.ejb.client.remoting.EndpointPool$PooledEndpoint.connect(EndpointPool.java:192) > at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:153) > at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:133) > at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:78) > ... 18 more > {noformat} > Note: > Dependency org.wildfly:wildfly-security-api has transitive dependency on org.wildfly.security:wildfly-elytron. Artifact wildfly-elytron using service org.wildfly.security.sasl.gssapi.GssapiClientFactory which is added via Java SPI as javax.security.sasl.SaslClientService. Adding this service causes that Kerberos authentication is handled by org.wildfly.security.sasl.gssapi.GssapiClient which leads to authentication failures. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-271) EJB authentication via Kerberos does not work with wildfly-security-api

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/ELY-271?page=com.atlassian.jira.plugin.sy... ] Ondrej Lukas updated ELY-271: ----------------------------- Priority: Critical (was: Minor) > EJB authentication via Kerberos does not work with wildfly-security-api > ----------------------------------------------------------------------- > > Key: ELY-271 > URL: https://issues.jboss.org/browse/ELY-271 > Project: WildFly Elytron > Issue Type: Bug > Components: SASL > Affects Versions: 1.0.0.Alpha3 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 1.1.0.CR1 > > Attachments: client.zip, server.jar > > > EJB authentication via Kerberos does not work for projects using EJB Client with dependency on org.wildfly:wildfly-security-api. EJB invocation failed with exception: > {noformat} > java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed: > GSSAPI: javax.security.sasl.SaslException: ELY05108: [GSSAPI] Unable to create response token [Caused by javax.security.sasl.SaslException: ELY05127: [GSSAPI] No security layer supported by server but maximum message size received: "65536"] > at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:92) > at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:80) > at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51) > at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:158) > at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:115) > at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createIdentifiableEjbClientContext(EjbNamingContext.java:258) > at org.jboss.ejb.client.naming.ejb.EjbNamingContext.setupScopedEjbClientContextIfNeeded(EjbNamingContext.java:123) > at org.jboss.ejb.client.naming.ejb.EjbNamingContext.<init>(EjbNamingContext.java:98) > at org.jboss.ejb.client.naming.ejb.ejbURLContextFactory.getObjectInstance(ejbURLContextFactory.java:38) > at javax.naming.spi.NamingManager.getURLObject(NamingManager.java:601) > at javax.naming.spi.NamingManager.getURLContext(NamingManager.java:550) > at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:345) > at javax.naming.InitialContext.lookup(InitialContext.java:417) > at client.Client.main(Client.java:19) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297) > at java.lang.Thread.run(Thread.java:745) > Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed: > GSSAPI: javax.security.sasl.SaslException: ELY05108: [GSSAPI] Unable to create response token [Caused by javax.security.sasl.SaslException: ELY05127: [GSSAPI] No security layer supported by server but maximum message size received: "65536"] > at org.jboss.remoting3.remote.ClientConnectionOpenListener.allMechanismsFailed(ClientConnectionOpenListener.java:114) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:393) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:243) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:199) > at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:113) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) > 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:88) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) > at ...asynchronous invocation...(Unknown Source) > at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:388) > at org.jboss.ejb.client.remoting.EndpointPool$PooledEndpoint.connect(EndpointPool.java:192) > at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:153) > at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:133) > at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:78) > ... 18 more > {noformat} > Note: > Dependency org.wildfly:wildfly-security-api has transitive dependency on org.wildfly.security:wildfly-elytron. Artifact wildfly-elytron using service org.wildfly.security.sasl.gssapi.GssapiClientFactory which is added via Java SPI as javax.security.sasl.SaslClientService. Adding this service causes that Kerberos authentication is handled by org.wildfly.security.sasl.gssapi.GssapiClient which leads to authentication failures. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1569) NPE when executing a full-replace-deployment operation followed by an add operation for the same deployment

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1569?page=com.atlassian.jira.plugi... ] Chao Wang reassigned WFCORE-1569: --------------------------------- Assignee: Chao Wang (was: Ken Wills) > NPE when executing a full-replace-deployment operation followed by an add operation for the same deployment > ----------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1569 > URL: https://issues.jboss.org/browse/WFCORE-1569 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: James Perkins > Assignee: Chao Wang > Attachments: issue-reproducer.zip > > > Executing the {{full-replace-deployment}} operation on a domain deployment works correctly if it's a single operation (even in a composite operation). In a composite operation where an {{add}} operation is executed to add the deployment to a server-group(s) after the {{full-replace-deployment}} an NPE is thrown because the previous resource is {{null}} since it did not exist. > {code:java|title=org.jboss.as.server.deployment.DeploymentFullReplaceHandler} > // WFCORE-495 remove and call context.addResource() as below to add new resource with updated PERSISTENT value > final ModelNode deploymentModel = context.removeResource(PathAddress.pathAddress(deploymentPath)).getModel(); > {code} > The {{context.removeResource()}} returns {{null}} since the deployment was not deployed on the server in the server-group. > From debugging it looks like the full composite operation is passed to each server in a server group. For obvious reasons if the {{add}} operation is done before the {{full-replace-deployment}} operation the composite operation is successful. > The easy workaround is just to ignore missing deployments in the {{org.jboss.as.server.deployment.DeploymentFullReplaceHandler}} OSH and log a debug or trace message indicating it was skipped because the deployment did not previously exist on the server. However this may need to be done at the HC operation routing level. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7072) Wildfly 10.1.0.FINAL does not start as a windows service

by Arthur Borsboom (JIRA)

Arthur Borsboom created WFLY-7072: ------------------------------------- Summary: Wildfly 10.1.0.FINAL does not start as a windows service Key: WFLY-7072 URL: https://issues.jboss.org/browse/WFLY-7072 Project: WildFly Issue Type: Bug Components: Server Affects Versions: 10.1.0.Final Reporter: Arthur Borsboom Assignee: Jason Greene Priority: Minor The service.bat batch file to install Wildfly as a WIndows Service (still) contains a small error, preventing the service being added correctly. This bug has been reported before and also has been reported as fixed. However the bug is still there. https://issues.jboss.org/browse/WFCORE-1719 The funny thing is that the batch file even describes in a REM statement that the line "SET DESCRIPTION" should not contain quotes. So, the fix is described, but just not applied. :) Please remove the quotes in the next release. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6960) SFSB concurrent access timeout when the bean defines CDI producer for another SFSB

by Enrique González Martínez (JIRA)

[ https://issues.jboss.org/browse/WFLY-6960?page=com.atlassian.jira.plugin.... ] Enrique González Martínez commented on WFLY-6960: ------------------------------------------------- The rest of the stacktrace... {code} Caused by: org.jboss.weld.exceptions.CreationException: WELD-000079: Could not instantiate a proxy for a session bean: Session bean [class org.github.jboss.test.weld.SFBean2 with qualifiers [@Any @Default]; local interfaces are [SFBean2] Proxy: class org.github.jboss.test.weld.SFBean2$Proxy$_$$_Weld$EnterpriseProxy$ at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.newInstance(SessionBeanProxyInstantiator.java:72) at org.jboss.weld.bean.SessionBean.create(SessionBean.java:149) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.get(ContextualInstanceStrategy.java:178) at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99) at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125) at org.github.jboss.test.weld.SFBean2$Proxy$_$$_WeldClientProxy.foo(Unknown Source) at org.github.jboss.test.weld.SFBean3.test(SFBean3.java:19) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:125) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64) at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) ... 85 more Caused by: java.lang.IllegalStateException: WFLYEE0042: No logró construir la instancia del componente at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163) at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:150) at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75) at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134) at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:145) at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75) at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88) at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:135) at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:75) at org.jboss.as.ejb3.cache.simple.SimpleCache.create(SimpleCache.java:118) at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238) at org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.<init>(StatefulSessionObjectReferenceImpl.java:70) at org.jboss.as.weld.services.bootstrap.WeldEjbServices.resolveEjb(WeldEjbServices.java:53) at org.jboss.weld.bean.SessionBean.createReference(SessionBean.java:230) at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:84) at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:64) at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.createEnterpriseTargetBeanInstance(SessionBeanProxyInstantiator.java:80) at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.newInstance(SessionBeanProxyInstantiator.java:61) ... 127 more {code} > SFSB concurrent access timeout when the bean defines CDI producer for another SFSB > ---------------------------------------------------------------------------------- > > Key: WFLY-6960 > URL: https://issues.jboss.org/browse/WFLY-6960 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final, 10.1.0.CR1 > Reporter: Tomas Remes > Assignee: Enrique González Martínez > > In the given scenario there are two calls to {{org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor#processInvocation}} in the same thread. In the first call the {{OwnableReentrantLock}} is obtained but it couldn't be reentered in the second call. This results to: > {noformat} > 14:54:21,184 ERROR [org.jboss.as.ejb3.invocation] (pool-2-thread-2) WFLYEJB0034: EJB Invocation failed on component SFBean1 for method public org.jboss.weld.tests.ejb.stateful.producer.Foo org.jboss.weld.tests.ejb.stateful.producer.SFBean1.produceString(): javax.ejb.ConcurrentAccessTimeoutException: WFLYEJB0228: EJB 3.1 FR 4.3.14.1 concurrent access timeout on SFBean1 - could not obtain lock within 5000 MILLISECONDS > at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:86) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) > at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64) > at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195) > at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean1$$$view5.produceString(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:436) > at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127) > at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) > at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean1$Proxy$_$$_Weld$EnterpriseProxy$.produceString(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.producer.ProducerMethodProducer.produce(ProducerMethodProducer.java:99) > at org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:161) > at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:181) > at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:70) > at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) > at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) > at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742) > at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:842) > at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92) > at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:378) > at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:389) > at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:71) > at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) > at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:73) > at org.jboss.weld.injection.producer.ejb.SessionBeanInjectionTarget.inject(SessionBeanInjectionTarget.java:140) > at org.jboss.as.weld.injection.WeldInjectionContext.inject(WeldInjectionContext.java:39) > at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:51) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:263) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.notSupported(CMTTxInterceptor.java:308) > at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:62) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.jpa.interceptor.SFSBPreCreateInterceptor.processInvocation(SFSBPreCreateInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:150) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75) > at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:145) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75) > at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:135) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:75) > at org.jboss.as.ejb3.cache.simple.SimpleCache.create(SimpleCache.java:118) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238) > at org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.<init>(StatefulSessionObjectReferenceImpl.java:70) > at org.jboss.as.weld.services.bootstrap.WeldEjbServices.resolveEjb(WeldEjbServices.java:53) > at org.jboss.weld.bean.SessionBean.createReference(SessionBean.java:230) > at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:83) > at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:63) > at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.createEnterpriseTargetBeanInstance(SessionBeanProxyInstantiator.java:80) > at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.newInstance(SessionBeanProxyInstantiator.java:61) > at org.jboss.weld.bean.SessionBean.create(SessionBean.java:149) > at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96) > at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) > at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.get(ContextualInstanceStrategy.java:178) > at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) > at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99) > at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean2$Proxy$_$$_WeldClientProxy.foo(Unknown Source) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean3.ping(SFBean3.java:19) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) > at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) > at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) > at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:125) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) > at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64) > at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195) > at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$$$view6.ping(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:436) > at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127) > at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) > at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$Proxy$_$$_Weld$EnterpriseProxy$.ping(Unknown Source) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$Proxy$_$$_WeldClientProxy.ping(Unknown Source) > at org.jboss.weld.tests.ejb.stateful.producer.ConcurrentAccessTest.test(ConcurrentAccessTest.java:31) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7018) Valid Wildfly 10.0.0.Final DataSource fails in Wildfly 10.1.0.Final

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-7018?page=com.atlassian.jira.plugin.... ] Lin Gao commented on WFLY-7018: ------------------------------- Oh, right, forgive me. I forget that another linked issue: WFLY-6200 is not resolved yet, the connection-url is still mandatory now. :P {noformat} Question 1: It sounds like Wildfly DataSources will be configured differently in future, with different cli commands. Is this correct? {noformat} I think it is still the same CLI command, just with ability to specify the --connection-properties now. {noformat} Question 2: Is there a better work-around than the above example, so that I can get a Wildfly 10.0.0.Final DataSource working again in Wildfly 10.1.0.Final? {noformat} I think no better option for now without WFLY-6200 fixed. {noformat} Question 3: Could you provide a sample Wildfly 10.1.0.Final DataSource XML configuration (<subsystem xmlns="urn:jboss:domain:datasources:4.0"></subsystem>) that would work? {noformat} Without fixing of WFLY-6200, the sample in the bug description is one way that works, which uses DataSource to get database connection. Another possible configuration can be: {code:xml} <subsystem xmlns="urn:jboss:domain:datasources:4.0"> <datasources> <datasource jndi-name="java:/MY_APP_DS" pool-name="Postgres_MY_APP_DS"> <connection-url>jdbc:postgresql://localhost:5432/myapp</connection-url> <driver>postgres</driver> <security> <user-name>myapp</user-name> <password>myapp</password> </security> <validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/> </validation> </datasource> <drivers> <driver name="postgres" module="org.postgres"> <driver-class>org.postgresql.Driver</driver-class> <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class> </driver> </drivers> </datasources> </subsystem> {code} where I removed the {{datasource-class}} from {{driver}} element. So it will try to use DriverManager.getConnection() to get database connection. {noformat} Question 4: Could you provide a sample Wildfly 10.1.0.Final DataSource CLI configuration that would work? {noformat} Actually there is only one extra parameter to specify: {code:java} data-source add \ --name=MyDS \ --driver-name=postgresql \ --jndi-name=java:jboss/jdbc/MyDS \ --user-name=wildfly \ --password=**** \ --connection-url=jdbc:postgresql://localhost:5432/wildfly \ --connection-properties={"url"=>"jdbc:postgresql://localhost:5432/wildfly"} {code} NOTE: I need to define both {{--connection-url}} and {{--connection-properties}} now before WFLY-6200 gets fixed. I think IronJacamar should be more tolerant on usage the datasoruce-class or connection-url, but I need to discuss it with Jesper and Stefano before we can get the conclusion on that. > Valid Wildfly 10.0.0.Final DataSource fails in Wildfly 10.1.0.Final > ------------------------------------------------------------------- > > Key: WFLY-7018 > URL: https://issues.jboss.org/browse/WFLY-7018 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 10.1.0.Final > Reporter: Mark S > Assignee: Lin Gao > > My current Wildfly 10.0.0.Final (Non-XA) Datasource configuration will not work for Wildfly 10.1.0.Final. See the "Steps to Reproduce" section. > The stacktrace points to here: > * https://source.jboss.org/browse/IronJacamar/adapters/src/main/java/org/jb... > * https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.3.4.Final/a... > h3. The work-around > h3. Wildfly 10.1.0.Final Datasource configuration via CLI > {code} > # No parameter to set a connection property value. > {code} > h3. Wildfly 10.1.0.Final Datasource configuration via XML (standalone-full.xml) > Note the addition of {{<connection-property name="databaseName">myapp</connection-property>}} > {code:xml} > <subsystem xmlns="urn:jboss:domain:datasources:4.0"> > <datasources> > <datasource jndi-name="java:/MY_APP_DS" pool-name="Postgres_MY_APP_DS"> > <connection-url>jdbc:postgresql://localhost:5432/myapp</connection-url> > <connection-property name="databaseName">myapp</connection-property> > <driver>postgres</driver> > <security> > <user-name>myapp</user-name> > <password>myapp</password> > </security> > <validation> > <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/> > <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/> > </validation> > </datasource> > <drivers> > <driver name="postgres" module="org.postgres"> > <driver-class>org.postgresql.Driver</driver-class> > <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class> > <datasource-class>org.postgresql.ds.PGSimpleDataSource</datasource-class> > </driver> > </drivers> > </datasources> > </subsystem> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7071) Changing default-realm of Elytron security-domain through CLI can put the server configuration to wrong state

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-7071: ---------------------------------- Summary: Changing default-realm of Elytron security-domain through CLI can put the server configuration to wrong state Key: WFLY-7071 URL: https://issues.jboss.org/browse/WFLY-7071 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Values of write-attribute operation for default-realm of Elytron security-domain are not checked. It means that CLI allows users to set application server to wrong state. The same happens if realm, which is considered as default-realm, is removed from used security-domain realms. CLI should deny write attribute operation with wrong value (in the same way as it works for another security-domain attributes). After reload, server is not started and following logs occur in console: {code} ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 25) WFLYCTL0013: Operation ("add") failed - address: ([ ("subsystem" => "elytron"), ("security-domain" => "ApplicationDomain") ]) - failure description: "WFLYELY00013: The default_realm 'WrongRealm' is not in the list or realms referenced by this domain." ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem elytron boot operations" ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: "\"WFLYCTL0193: Failed executing subsystem elytron boot operations\"" FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1769) DomainRootDefinition.RolloutPlanValidator is throwing OFE when it should just be an assert

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-1769: ---------------------------------------- Summary: DomainRootDefinition.RolloutPlanValidator is throwing OFE when it should just be an assert Key: WFCORE-1769 URL: https://issues.jboss.org/browse/WFCORE-1769 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor Fix For: 3.0.0.Alpha8 The ParameterValidator javadoc declares the 'value' parameter cannot be null, so a null param value should result in an AssertionError or an IAE. But RolloutPlanValidator is throwing an OFE. OFE should be used for user errors (i.e. invalid requests), not coding mistakes. The data passed to a validator is not under the control of the user; passing a null means a coding mistake. The caller of a ParameterValidator is the kernel, not outside code, so we are not validating unknown inputs. So an assert is fine; no need for an IAE. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7029) RemoteFailoverTestCast#testGracefulShutdownConcurrentFailover fails with "ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations."

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/WFLY-7029?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz edited comment on WFLY-7029 at 9/7/16 3:28 PM: ------------------------------------------------------------------- I don't see why a get() or a put() should fail as long as at least one of the nodes holding the bean entries is available. Isn't this a bug for ISPN? [~dan.berindei] Any ideas on this one? was (Author: rachmato): I don't see why a get() or a put() should fail as long as at least one of the nodes holding the bean entries is available. Isn't this a bug for ISPN? > RemoteFailoverTestCast#testGracefulShutdownConcurrentFailover fails with "ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations." > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7029 > URL: https://issues.jboss.org/browse/WFLY-7029 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Richard Achmatowicz > > https://ci.wildfly.org/viewLog.html?buildId=24851&tab=buildResultsDiv&bui... > {noformat} > 04:31:43,323 INFO [org.jboss.as.test.clustering.NodeUtil] (main) Stopping container=container-0, timeout=15 > 04:31:43,324 INFO [org.jboss.as.arquillian.container.controller.ClientWildFlyContainerController] (main) Manual stopping of a server instance with timeout=15 > &amp#27;[0m04:31:43,338 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0211: Suspending server with 15000 ms timeout. > &amp#27;[0m04:31:43,343 INFO [org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler] (Remoting "config-based-ejb-client-endpoint" task-10) Retrying invocation which failed on node node-0 with exception:: javax.ejb.NoSuchEJBException: No such EJB[appname=,modulename=remote-failover-test,distinctname=,beanname=SlowToDestroyStatefulIncrementorBean,viewclassname=org.jboss.as.test.clustering.cluster.ejb.remote.bean.Incrementor] > at org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler.processMessage(NoSuchEJBExceptionResponseHandler.java:64) > at org.jboss.ejb.client.remoting.ChannelAssociation.processResponse(ChannelAssociation.java:386) > at org.jboss.ejb.client.remoting.ChannelAssociation$ResponseReceiver.handleMessage(ChannelAssociation.java:498) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > &amp#27;[0m04:31:43,345 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' > &amp#27;[0m&amp#27;[0m04:31:43,430 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping > &amp#27;[0m&amp#27;[0m04:31:43,436 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 29) MODCLUSTER000002: Initiating mod_cluster shutdown > &amp#27;[0m&amp#27;[0m04:31:43,445 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 74) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:/ConnectionFactory > &amp#27;[0m&amp#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000080: Disconnecting JGroups channel hibernate > &amp#27;[0m&amp#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher for channel hibernate > &amp#27;[0m&amp#27;[0m04:31:43,463 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000080: Disconnecting JGroups channel server > &amp#27;[0m&amp#27;[0m04:31:43,464 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000082: Stopping the RpcDispatcher for channel server > &amp#27;[0m&amp#27;[0m04:31:43,471 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000029: Passivating all entries to disk > &amp#27;[0m&amp#27;[0m04:31:43,472 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000030: Passivated 2 entries in 0 milliseconds > &amp#27;[0m&amp#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel web > &amp#27;[0m&amp#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel web > &amp#27;[0m&amp#27;[0m04:31:43,502 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 29) WFLYCLINF0003: Stopped remote-failover-test.jar cache from ejb container > &amp#27;[0m&amp#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel testDbPersistence > &amp#27;[0m&amp#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel testDbPersistence > &amp#27;[0m&amp#27;[33m04:31:43,502 WARN [org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler] (thread-11,ee,node-0) ISPN000071: Caught exception when handling command LockControlCommand{cache=remote-failover-test.jar, keys=[UnknownSessionID [6951504948515351686656515249505365655750686851525048706670486766]], flags=[FORCE_WRITE_LOCK], unlock=false, gtx=GlobalTransaction:<node-1>:48:remote}: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > at org.jgroups.JChannel.up(JChannel.java:738) > at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120) > at org.jgroups.stack.Protocol.up(Protocol.java:380) > at org.jgroups.protocols.FORK.up(FORK.java:114) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070) > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD.up(FD.java:260) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) > at org.jgroups.protocols.Discovery.up(Discovery.java:296) > at org.jgroups.protocols.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52) > at java.lang.Thread.run(Thread.java:745) > &amp#27;[0m&amp#27;[0m04:31:43,517 INFO [org.wildfly.extension.messaging-activemq] (MSC service thread 1-2) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory > &amp#27;[0m&amp#27;[0m04:31:43,517 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > &amp#27;[0m&amp#27;[0m04:31:43,518 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA] > &amp#27;[0m&amp#27;[0m04:31:43,535 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-8) WFLYJCA0019: Stopped Driver service with driver-name = h2 > &amp#27;[0m&amp#27;[0m04:31:43,547 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 2) WFLYCLINF0003: Stopped client-mappings cache from ejb container > &amp#27;[0m04:31:43,565 INFO [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-14) EJBCLIENT000016: Channel Channel ID b007a55b (outbound) of Remoting connection 017c35ab to /0:0:0:0:0:0:0:1:8080 of endpoint "config-based-ejb-client-endpoint" <1c33eee> can no longer process messages > &amp#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000080: Disconnecting JGroups channel ejb > &amp#27;[0m&amp#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000082: Stopping the RpcDispatcher for channel ejb > &amp#27;[0m&amp#27;[0m04:31:43,575 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 35) AMQ151003: resource adaptor stopped > &amp#27;[0m&amp#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow AJP listener ajp suspending > &amp#27;[0m&amp#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [::1]:8009 > &amp#27;[0m&amp#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTPS listener https suspending > &amp#27;[0m&amp#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [::1]:8443 > &amp#27;[0m&amp#27;[31m04:31:43,585 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-11) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace > at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:795) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642) > at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602) > at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577) > at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) > at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962) > at org.infinispan.remoting.transport.jgroups.RspListFuture.futureDone(RspListFuture.java:31) > at org.jgroups.blocks.Request.checkCompletion(Request.java:152) > at org.jgroups.blocks.GroupRequest.receiveResponse(GroupRequest.java:116) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:427) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > at org.jgroups.JChannel.up(JChannel.java:738) > at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120) > at org.jgroups.stack.Protocol.up(Protocol.java:380) > at org.jgroups.protocols.FORK.up(FORK.java:114) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070) > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD.up(FD.java:260) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) > at org.jgroups.protocols.Discovery.up(Discovery.java:296) > at org.jgroups.protocols.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.infinispan.commons.CacheException: Problems invoking command. > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.exceptionHandlingCommand(BasePerCacheInboundInvocationHandler.java:106) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:101) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > ... 27 more > Caused by: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > ... 33 more > &amp#27;[0m&amp#27;[31m04:31:43,588 ERROR [org.jboss.as.ejb3.invocation] (default task-11) WFLYEJB0034: EJB Invocation failed on component SlowToDestroyStatefulIncrementorBean for method public abstract org.jboss.as.test.clustering.cluster.ejb.remote.bean.Result org.jboss.as.test.clustering.cluster.ejb.remote.bean.Incrementor.increment(): javax.ejb.EJBException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace > at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:328) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:201) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:263) > at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213) > at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76) > at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace > at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:795) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642) > at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602) > at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577) > at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) > at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962) > at org.infinispan.remoting.transport.jgroups.RspListFuture.futureDone(RspListFuture.java:31) > at org.jgroups.blocks.Request.checkCompletion(Request.java:152) > at org.jgroups.blocks.GroupRequest.receiveResponse(GroupRequest.java:116) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:427) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > at org.jgroups.JChannel.up(JChannel.java:738) > at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120) > at org.jgroups.stack.Protocol.up(Protocol.java:380) > at org.jgroups.protocols.FORK.up(FORK.java:114) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070) > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD.up(FD.java:260) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) > at org.jgroups.protocols.Discovery.up(Discovery.java:296) > at org.jgroups.protocols.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52) > ... 1 more > Caused by: org.infinispan.commons.CacheException: Problems invoking command. > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.exceptionHandlingCommand(BasePerCacheInboundInvocationHandler.java:106) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:101) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > ... 27 more > Caused by: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > ... 33 more > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-955) Regression in parsing username in LdapExtLoginModule

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/SECURITY-955?page=com.atlassian.jira.plug... ] Ilia Vassilev updated SECURITY-955: ----------------------------------- Git Pull Request: https://github.com/picketbox/picketbox/pull/64 > Regression in parsing username in LdapExtLoginModule > ---------------------------------------------------- > > Key: SECURITY-955 > URL: https://issues.jboss.org/browse/SECURITY-955 > Project: PicketBox > Issue Type: Bug > Affects Versions: PicketBox_5_0_0.Alpha3 > Reporter: Ondrej Lukas > Assignee: Ilia Vassilev > Priority: Blocker > > In case when customers using LdapExtLoginModule with option parseUsername=true but without option usernameBeginString (i.e. usernameBeginString=null) then all users cannot be successfully authenticated into application. Authentication failure is caused by hidden internal NPE. > It is the same issue as was reported in [1], but fix is missing in current EAP 7.1 version of PicketBox (5.0.0.Alpha3). > We request blocker flag because: > * Valid configuration which works for 7.0.x becomes invalid after migration to 7.1.0 > * All users cannot authenticate to application despite of valid EAP configuration > * Authetication failure caused by NPE is logged to server log > Thrown NPE: > {code} > java.lang.NullPointerException > at org.jboss.security.auth.spi.LdapExtLoginModule.getUsername(LdapExtLoginModule.java:963) > at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:342) > at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:283) > {code} > [1] https://issues.jboss.org/browse/JBEAP-364?focusedCommentId=13160168&page=... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7029) RemoteFailoverTestCast#testGracefulShutdownConcurrentFailover fails with "ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations."

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/WFLY-7029?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz edited comment on WFLY-7029 at 9/7/16 3:26 PM: ------------------------------------------------------------------- I don't see why a get() or a put() should fail as long as at least one of the nodes holding the bean entries is available. Isn't this a bug for ISPN? was (Author: rachmato): I don't see why a get() or a put() should fail as long as at least one of the nodes holding the bean entries is available. Isn't this a bug for ISPN? > RemoteFailoverTestCast#testGracefulShutdownConcurrentFailover fails with "ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations." > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7029 > URL: https://issues.jboss.org/browse/WFLY-7029 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Richard Achmatowicz > > https://ci.wildfly.org/viewLog.html?buildId=24851&tab=buildResultsDiv&bui... > {noformat} > 04:31:43,323 INFO [org.jboss.as.test.clustering.NodeUtil] (main) Stopping container=container-0, timeout=15 > 04:31:43,324 INFO [org.jboss.as.arquillian.container.controller.ClientWildFlyContainerController] (main) Manual stopping of a server instance with timeout=15 > &amp#27;[0m04:31:43,338 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0211: Suspending server with 15000 ms timeout. > &amp#27;[0m04:31:43,343 INFO [org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler] (Remoting "config-based-ejb-client-endpoint" task-10) Retrying invocation which failed on node node-0 with exception:: javax.ejb.NoSuchEJBException: No such EJB[appname=,modulename=remote-failover-test,distinctname=,beanname=SlowToDestroyStatefulIncrementorBean,viewclassname=org.jboss.as.test.clustering.cluster.ejb.remote.bean.Incrementor] > at org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler.processMessage(NoSuchEJBExceptionResponseHandler.java:64) > at org.jboss.ejb.client.remoting.ChannelAssociation.processResponse(ChannelAssociation.java:386) > at org.jboss.ejb.client.remoting.ChannelAssociation$ResponseReceiver.handleMessage(ChannelAssociation.java:498) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > &amp#27;[0m04:31:43,345 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' > &amp#27;[0m&amp#27;[0m04:31:43,430 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping > &amp#27;[0m&amp#27;[0m04:31:43,436 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 29) MODCLUSTER000002: Initiating mod_cluster shutdown > &amp#27;[0m&amp#27;[0m04:31:43,445 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 74) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:/ConnectionFactory > &amp#27;[0m&amp#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000080: Disconnecting JGroups channel hibernate > &amp#27;[0m&amp#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher for channel hibernate > &amp#27;[0m&amp#27;[0m04:31:43,463 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000080: Disconnecting JGroups channel server > &amp#27;[0m&amp#27;[0m04:31:43,464 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000082: Stopping the RpcDispatcher for channel server > &amp#27;[0m&amp#27;[0m04:31:43,471 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000029: Passivating all entries to disk > &amp#27;[0m&amp#27;[0m04:31:43,472 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000030: Passivated 2 entries in 0 milliseconds > &amp#27;[0m&amp#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel web > &amp#27;[0m&amp#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel web > &amp#27;[0m&amp#27;[0m04:31:43,502 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 29) WFLYCLINF0003: Stopped remote-failover-test.jar cache from ejb container > &amp#27;[0m&amp#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel testDbPersistence > &amp#27;[0m&amp#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel testDbPersistence > &amp#27;[0m&amp#27;[33m04:31:43,502 WARN [org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler] (thread-11,ee,node-0) ISPN000071: Caught exception when handling command LockControlCommand{cache=remote-failover-test.jar, keys=[UnknownSessionID [6951504948515351686656515249505365655750686851525048706670486766]], flags=[FORCE_WRITE_LOCK], unlock=false, gtx=GlobalTransaction:<node-1>:48:remote}: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > at org.jgroups.JChannel.up(JChannel.java:738) > at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120) > at org.jgroups.stack.Protocol.up(Protocol.java:380) > at org.jgroups.protocols.FORK.up(FORK.java:114) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070) > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD.up(FD.java:260) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) > at org.jgroups.protocols.Discovery.up(Discovery.java:296) > at org.jgroups.protocols.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52) > at java.lang.Thread.run(Thread.java:745) > &amp#27;[0m&amp#27;[0m04:31:43,517 INFO [org.wildfly.extension.messaging-activemq] (MSC service thread 1-2) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory > &amp#27;[0m&amp#27;[0m04:31:43,517 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > &amp#27;[0m&amp#27;[0m04:31:43,518 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA] > &amp#27;[0m&amp#27;[0m04:31:43,535 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-8) WFLYJCA0019: Stopped Driver service with driver-name = h2 > &amp#27;[0m&amp#27;[0m04:31:43,547 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 2) WFLYCLINF0003: Stopped client-mappings cache from ejb container > &amp#27;[0m04:31:43,565 INFO [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-14) EJBCLIENT000016: Channel Channel ID b007a55b (outbound) of Remoting connection 017c35ab to /0:0:0:0:0:0:0:1:8080 of endpoint "config-based-ejb-client-endpoint" <1c33eee> can no longer process messages > &amp#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000080: Disconnecting JGroups channel ejb > &amp#27;[0m&amp#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000082: Stopping the RpcDispatcher for channel ejb > &amp#27;[0m&amp#27;[0m04:31:43,575 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 35) AMQ151003: resource adaptor stopped > &amp#27;[0m&amp#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow AJP listener ajp suspending > &amp#27;[0m&amp#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [::1]:8009 > &amp#27;[0m&amp#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTPS listener https suspending > &amp#27;[0m&amp#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [::1]:8443 > &amp#27;[0m&amp#27;[31m04:31:43,585 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-11) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace > at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:795) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642) > at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602) > at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577) > at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) > at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962) > at org.infinispan.remoting.transport.jgroups.RspListFuture.futureDone(RspListFuture.java:31) > at org.jgroups.blocks.Request.checkCompletion(Request.java:152) > at org.jgroups.blocks.GroupRequest.receiveResponse(GroupRequest.java:116) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:427) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > at org.jgroups.JChannel.up(JChannel.java:738) > at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120) > at org.jgroups.stack.Protocol.up(Protocol.java:380) > at org.jgroups.protocols.FORK.up(FORK.java:114) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070) > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD.up(FD.java:260) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) > at org.jgroups.protocols.Discovery.up(Discovery.java:296) > at org.jgroups.protocols.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.infinispan.commons.CacheException: Problems invoking command. > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.exceptionHandlingCommand(BasePerCacheInboundInvocationHandler.java:106) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:101) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > ... 27 more > Caused by: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > ... 33 more > &amp#27;[0m&amp#27;[31m04:31:43,588 ERROR [org.jboss.as.ejb3.invocation] (default task-11) WFLYEJB0034: EJB Invocation failed on component SlowToDestroyStatefulIncrementorBean for method public abstract org.jboss.as.test.clustering.cluster.ejb.remote.bean.Result org.jboss.as.test.clustering.cluster.ejb.remote.bean.Incrementor.increment(): javax.ejb.EJBException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace > at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:328) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:201) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:263) > at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213) > at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76) > at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace > at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:795) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642) > at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602) > at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577) > at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) > at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962) > at org.infinispan.remoting.transport.jgroups.RspListFuture.futureDone(RspListFuture.java:31) > at org.jgroups.blocks.Request.checkCompletion(Request.java:152) > at org.jgroups.blocks.GroupRequest.receiveResponse(GroupRequest.java:116) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:427) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > at org.jgroups.JChannel.up(JChannel.java:738) > at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120) > at org.jgroups.stack.Protocol.up(Protocol.java:380) > at org.jgroups.protocols.FORK.up(FORK.java:114) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070) > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD.up(FD.java:260) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) > at org.jgroups.protocols.Discovery.up(Discovery.java:296) > at org.jgroups.protocols.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52) > ... 1 more > Caused by: org.infinispan.commons.CacheException: Problems invoking command. > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.exceptionHandlingCommand(BasePerCacheInboundInvocationHandler.java:106) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:101) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > ... 27 more > Caused by: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > ... 33 more > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7029) RemoteFailoverTestCast#testGracefulShutdownConcurrentFailover fails with "ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations."

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/WFLY-7029?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz commented on WFLY-7029: ------------------------------------------- I don't see why a get() or a put() should fail as long as at least one of the nodes holding the bean entries is available. Isn't this a bug for ISPN? > RemoteFailoverTestCast#testGracefulShutdownConcurrentFailover fails with "ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations." > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7029 > URL: https://issues.jboss.org/browse/WFLY-7029 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Richard Achmatowicz > > https://ci.wildfly.org/viewLog.html?buildId=24851&tab=buildResultsDiv&bui... > {noformat} > 04:31:43,323 INFO [org.jboss.as.test.clustering.NodeUtil] (main) Stopping container=container-0, timeout=15 > 04:31:43,324 INFO [org.jboss.as.arquillian.container.controller.ClientWildFlyContainerController] (main) Manual stopping of a server instance with timeout=15 > &amp#27;[0m04:31:43,338 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0211: Suspending server with 15000 ms timeout. > &amp#27;[0m04:31:43,343 INFO [org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler] (Remoting "config-based-ejb-client-endpoint" task-10) Retrying invocation which failed on node node-0 with exception:: javax.ejb.NoSuchEJBException: No such EJB[appname=,modulename=remote-failover-test,distinctname=,beanname=SlowToDestroyStatefulIncrementorBean,viewclassname=org.jboss.as.test.clustering.cluster.ejb.remote.bean.Incrementor] > at org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler.processMessage(NoSuchEJBExceptionResponseHandler.java:64) > at org.jboss.ejb.client.remoting.ChannelAssociation.processResponse(ChannelAssociation.java:386) > at org.jboss.ejb.client.remoting.ChannelAssociation$ResponseReceiver.handleMessage(ChannelAssociation.java:498) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > &amp#27;[0m04:31:43,345 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' > &amp#27;[0m&amp#27;[0m04:31:43,430 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping > &amp#27;[0m&amp#27;[0m04:31:43,436 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 29) MODCLUSTER000002: Initiating mod_cluster shutdown > &amp#27;[0m&amp#27;[0m04:31:43,445 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 74) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:/ConnectionFactory > &amp#27;[0m&amp#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000080: Disconnecting JGroups channel hibernate > &amp#27;[0m&amp#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher for channel hibernate > &amp#27;[0m&amp#27;[0m04:31:43,463 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000080: Disconnecting JGroups channel server > &amp#27;[0m&amp#27;[0m04:31:43,464 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000082: Stopping the RpcDispatcher for channel server > &amp#27;[0m&amp#27;[0m04:31:43,471 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000029: Passivating all entries to disk > &amp#27;[0m&amp#27;[0m04:31:43,472 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000030: Passivated 2 entries in 0 milliseconds > &amp#27;[0m&amp#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel web > &amp#27;[0m&amp#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel web > &amp#27;[0m&amp#27;[0m04:31:43,502 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 29) WFLYCLINF0003: Stopped remote-failover-test.jar cache from ejb container > &amp#27;[0m&amp#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel testDbPersistence > &amp#27;[0m&amp#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel testDbPersistence > &amp#27;[0m&amp#27;[33m04:31:43,502 WARN [org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler] (thread-11,ee,node-0) ISPN000071: Caught exception when handling command LockControlCommand{cache=remote-failover-test.jar, keys=[UnknownSessionID [6951504948515351686656515249505365655750686851525048706670486766]], flags=[FORCE_WRITE_LOCK], unlock=false, gtx=GlobalTransaction:<node-1>:48:remote}: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > at org.jgroups.JChannel.up(JChannel.java:738) > at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120) > at org.jgroups.stack.Protocol.up(Protocol.java:380) > at org.jgroups.protocols.FORK.up(FORK.java:114) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070) > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD.up(FD.java:260) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) > at org.jgroups.protocols.Discovery.up(Discovery.java:296) > at org.jgroups.protocols.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52) > at java.lang.Thread.run(Thread.java:745) > &amp#27;[0m&amp#27;[0m04:31:43,517 INFO [org.wildfly.extension.messaging-activemq] (MSC service thread 1-2) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory > &amp#27;[0m&amp#27;[0m04:31:43,517 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > &amp#27;[0m&amp#27;[0m04:31:43,518 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA] > &amp#27;[0m&amp#27;[0m04:31:43,535 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-8) WFLYJCA0019: Stopped Driver service with driver-name = h2 > &amp#27;[0m&amp#27;[0m04:31:43,547 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 2) WFLYCLINF0003: Stopped client-mappings cache from ejb container > &amp#27;[0m04:31:43,565 INFO [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-14) EJBCLIENT000016: Channel Channel ID b007a55b (outbound) of Remoting connection 017c35ab to /0:0:0:0:0:0:0:1:8080 of endpoint "config-based-ejb-client-endpoint" <1c33eee> can no longer process messages > &amp#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000080: Disconnecting JGroups channel ejb > &amp#27;[0m&amp#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000082: Stopping the RpcDispatcher for channel ejb > &amp#27;[0m&amp#27;[0m04:31:43,575 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 35) AMQ151003: resource adaptor stopped > &amp#27;[0m&amp#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow AJP listener ajp suspending > &amp#27;[0m&amp#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [::1]:8009 > &amp#27;[0m&amp#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTPS listener https suspending > &amp#27;[0m&amp#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [::1]:8443 > &amp#27;[0m&amp#27;[31m04:31:43,585 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-11) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace > at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:795) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642) > at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602) > at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577) > at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) > at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962) > at org.infinispan.remoting.transport.jgroups.RspListFuture.futureDone(RspListFuture.java:31) > at org.jgroups.blocks.Request.checkCompletion(Request.java:152) > at org.jgroups.blocks.GroupRequest.receiveResponse(GroupRequest.java:116) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:427) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > at org.jgroups.JChannel.up(JChannel.java:738) > at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120) > at org.jgroups.stack.Protocol.up(Protocol.java:380) > at org.jgroups.protocols.FORK.up(FORK.java:114) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070) > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD.up(FD.java:260) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) > at org.jgroups.protocols.Discovery.up(Discovery.java:296) > at org.jgroups.protocols.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.infinispan.commons.CacheException: Problems invoking command. > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.exceptionHandlingCommand(BasePerCacheInboundInvocationHandler.java:106) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:101) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > ... 27 more > Caused by: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > ... 33 more > &amp#27;[0m&amp#27;[31m04:31:43,588 ERROR [org.jboss.as.ejb3.invocation] (default task-11) WFLYEJB0034: EJB Invocation failed on component SlowToDestroyStatefulIncrementorBean for method public abstract org.jboss.as.test.clustering.cluster.ejb.remote.bean.Result org.jboss.as.test.clustering.cluster.ejb.remote.bean.Incrementor.increment(): javax.ejb.EJBException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace > at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:328) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:201) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:263) > at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213) > at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76) > at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace > at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:795) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642) > at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602) > at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577) > at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) > at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962) > at org.infinispan.remoting.transport.jgroups.RspListFuture.futureDone(RspListFuture.java:31) > at org.jgroups.blocks.Request.checkCompletion(Request.java:152) > at org.jgroups.blocks.GroupRequest.receiveResponse(GroupRequest.java:116) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:427) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > at org.jgroups.JChannel.up(JChannel.java:738) > at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120) > at org.jgroups.stack.Protocol.up(Protocol.java:380) > at org.jgroups.protocols.FORK.up(FORK.java:114) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070) > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD.up(FD.java:260) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) > at org.jgroups.protocols.Discovery.up(Discovery.java:296) > at org.jgroups.protocols.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52) > ... 1 more > Caused by: org.infinispan.commons.CacheException: Problems invoking command. > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.exceptionHandlingCommand(BasePerCacheInboundInvocationHandler.java:106) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:101) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > ... 27 more > Caused by: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > ... 33 more > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7029) RemoteFailoverTestCast#testGracefulShutdownConcurrentFailover fails with "ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations."

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/WFLY-7029?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz edited comment on WFLY-7029 at 9/7/16 3:20 PM: ------------------------------------------------------------------- I've had another look at this from the EJB side. There are actually 5 cache accesses to the cache remote-failover-test.jar(dist_sync) for each invocation. All five of these accesses are wrapped into one Infinispan transaction by Paul's Batch mechanism. The calls look like this: In StatefulComponentInstanceInterceptor: - we call DistributableCache.get() to get the StatefulSessionComponent instance to be used in the invocation - this results in two get()s: one for the bean value and one for the group value In StatefulSessionSynchronizationInterceptor: - we call DistributableCache.release() to free the StatefulSessionComponent instance used in the invocation - this results in two get()s: one for the bean value and one for the group value - this also results in one put, to save the changes made in the invocation to the cache These are all in one transaction. It's not possible as far as I can tell, which of these invocations caused the failure. So, for each invocation, these five cache operations should be in the same ISPN transaction. was (Author: rachmato): I've had another look at this from the EJB side. There are actually 5 cache accesses to the cache remote-failover-test.jar(dist_sync) for each invocation. All five of these accesses are wrapped into one Infinispan transaction by Paul's Batch mechanism. The calls look like this: In StatefulComponentInstanceInterceptor: - we call DistributableCache.get() to get the StatefulSessionComponent instance to be used in the invocation - this results in two get()s: one for the bean value and one for the group value In StatefulSessionSynchronizationInterceptor: - we call DistributableCache.release() to free the StatefulSessionComponent instance used in the invocation - this results in two get()s: one for the bean value and one for the group value - this also results in one put, to save the changes made in the invocation to the cache These are all in one transaction. It's not possible as far as I can tell, which of these invocations caused the failure. So, for each invocation, these five cache operations should be in the same ISPN transaction. > RemoteFailoverTestCast#testGracefulShutdownConcurrentFailover fails with "ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations." > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7029 > URL: https://issues.jboss.org/browse/WFLY-7029 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Richard Achmatowicz > > https://ci.wildfly.org/viewLog.html?buildId=24851&tab=buildResultsDiv&bui... > {noformat} > 04:31:43,323 INFO [org.jboss.as.test.clustering.NodeUtil] (main) Stopping container=container-0, timeout=15 > 04:31:43,324 INFO [org.jboss.as.arquillian.container.controller.ClientWildFlyContainerController] (main) Manual stopping of a server instance with timeout=15 > &amp#27;[0m04:31:43,338 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0211: Suspending server with 15000 ms timeout. > &amp#27;[0m04:31:43,343 INFO [org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler] (Remoting "config-based-ejb-client-endpoint" task-10) Retrying invocation which failed on node node-0 with exception:: javax.ejb.NoSuchEJBException: No such EJB[appname=,modulename=remote-failover-test,distinctname=,beanname=SlowToDestroyStatefulIncrementorBean,viewclassname=org.jboss.as.test.clustering.cluster.ejb.remote.bean.Incrementor] > at org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler.processMessage(NoSuchEJBExceptionResponseHandler.java:64) > at org.jboss.ejb.client.remoting.ChannelAssociation.processResponse(ChannelAssociation.java:386) > at org.jboss.ejb.client.remoting.ChannelAssociation$ResponseReceiver.handleMessage(ChannelAssociation.java:498) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > &amp#27;[0m04:31:43,345 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' > &amp#27;[0m&amp#27;[0m04:31:43,430 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping > &amp#27;[0m&amp#27;[0m04:31:43,436 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 29) MODCLUSTER000002: Initiating mod_cluster shutdown > &amp#27;[0m&amp#27;[0m04:31:43,445 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 74) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:/ConnectionFactory > &amp#27;[0m&amp#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000080: Disconnecting JGroups channel hibernate > &amp#27;[0m&amp#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher for channel hibernate > &amp#27;[0m&amp#27;[0m04:31:43,463 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000080: Disconnecting JGroups channel server > &amp#27;[0m&amp#27;[0m04:31:43,464 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000082: Stopping the RpcDispatcher for channel server > &amp#27;[0m&amp#27;[0m04:31:43,471 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000029: Passivating all entries to disk > &amp#27;[0m&amp#27;[0m04:31:43,472 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000030: Passivated 2 entries in 0 milliseconds > &amp#27;[0m&amp#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel web > &amp#27;[0m&amp#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel web > &amp#27;[0m&amp#27;[0m04:31:43,502 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 29) WFLYCLINF0003: Stopped remote-failover-test.jar cache from ejb container > &amp#27;[0m&amp#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel testDbPersistence > &amp#27;[0m&amp#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel testDbPersistence > &amp#27;[0m&amp#27;[33m04:31:43,502 WARN [org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler] (thread-11,ee,node-0) ISPN000071: Caught exception when handling command LockControlCommand{cache=remote-failover-test.jar, keys=[UnknownSessionID [6951504948515351686656515249505365655750686851525048706670486766]], flags=[FORCE_WRITE_LOCK], unlock=false, gtx=GlobalTransaction:<node-1>:48:remote}: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > at org.jgroups.JChannel.up(JChannel.java:738) > at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120) > at org.jgroups.stack.Protocol.up(Protocol.java:380) > at org.jgroups.protocols.FORK.up(FORK.java:114) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070) > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD.up(FD.java:260) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) > at org.jgroups.protocols.Discovery.up(Discovery.java:296) > at org.jgroups.protocols.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52) > at java.lang.Thread.run(Thread.java:745) > &amp#27;[0m&amp#27;[0m04:31:43,517 INFO [org.wildfly.extension.messaging-activemq] (MSC service thread 1-2) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory > &amp#27;[0m&amp#27;[0m04:31:43,517 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > &amp#27;[0m&amp#27;[0m04:31:43,518 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA] > &amp#27;[0m&amp#27;[0m04:31:43,535 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-8) WFLYJCA0019: Stopped Driver service with driver-name = h2 > &amp#27;[0m&amp#27;[0m04:31:43,547 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 2) WFLYCLINF0003: Stopped client-mappings cache from ejb container > &amp#27;[0m04:31:43,565 INFO [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-14) EJBCLIENT000016: Channel Channel ID b007a55b (outbound) of Remoting connection 017c35ab to /0:0:0:0:0:0:0:1:8080 of endpoint "config-based-ejb-client-endpoint" <1c33eee> can no longer process messages > &amp#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000080: Disconnecting JGroups channel ejb > &amp#27;[0m&amp#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000082: Stopping the RpcDispatcher for channel ejb > &amp#27;[0m&amp#27;[0m04:31:43,575 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 35) AMQ151003: resource adaptor stopped > &amp#27;[0m&amp#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow AJP listener ajp suspending > &amp#27;[0m&amp#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [::1]:8009 > &amp#27;[0m&amp#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTPS listener https suspending > &amp#27;[0m&amp#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [::1]:8443 > &amp#27;[0m&amp#27;[31m04:31:43,585 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-11) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace > at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:795) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642) > at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602) > at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577) > at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) > at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962) > at org.infinispan.remoting.transport.jgroups.RspListFuture.futureDone(RspListFuture.java:31) > at org.jgroups.blocks.Request.checkCompletion(Request.java:152) > at org.jgroups.blocks.GroupRequest.receiveResponse(GroupRequest.java:116) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:427) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > at org.jgroups.JChannel.up(JChannel.java:738) > at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120) > at org.jgroups.stack.Protocol.up(Protocol.java:380) > at org.jgroups.protocols.FORK.up(FORK.java:114) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070) > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD.up(FD.java:260) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) > at org.jgroups.protocols.Discovery.up(Discovery.java:296) > at org.jgroups.protocols.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.infinispan.commons.CacheException: Problems invoking command. > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.exceptionHandlingCommand(BasePerCacheInboundInvocationHandler.java:106) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:101) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > ... 27 more > Caused by: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > ... 33 more > &amp#27;[0m&amp#27;[31m04:31:43,588 ERROR [org.jboss.as.ejb3.invocation] (default task-11) WFLYEJB0034: EJB Invocation failed on component SlowToDestroyStatefulIncrementorBean for method public abstract org.jboss.as.test.clustering.cluster.ejb.remote.bean.Result org.jboss.as.test.clustering.cluster.ejb.remote.bean.Incrementor.increment(): javax.ejb.EJBException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace > at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:328) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:201) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:263) > at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213) > at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76) > at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace > at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:795) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642) > at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602) > at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577) > at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) > at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962) > at org.infinispan.remoting.transport.jgroups.RspListFuture.futureDone(RspListFuture.java:31) > at org.jgroups.blocks.Request.checkCompletion(Request.java:152) > at org.jgroups.blocks.GroupRequest.receiveResponse(GroupRequest.java:116) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:427) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > at org.jgroups.JChannel.up(JChannel.java:738) > at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120) > at org.jgroups.stack.Protocol.up(Protocol.java:380) > at org.jgroups.protocols.FORK.up(FORK.java:114) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070) > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD.up(FD.java:260) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) > at org.jgroups.protocols.Discovery.up(Discovery.java:296) > at org.jgroups.protocols.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52) > ... 1 more > Caused by: org.infinispan.commons.CacheException: Problems invoking command. > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.exceptionHandlingCommand(BasePerCacheInboundInvocationHandler.java:106) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:101) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > ... 27 more > Caused by: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > ... 33 more > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7029) RemoteFailoverTestCast#testGracefulShutdownConcurrentFailover fails with "ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations."

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/WFLY-7029?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz edited comment on WFLY-7029 at 9/7/16 3:15 PM: ------------------------------------------------------------------- I've had another look at this from the EJB side. There are actually 5 cache accesses to the cache remote-failover-test.jar(dist_sync) for each invocation. All five of these accesses are wrapped into one Infinispan transaction by Paul's Batch mechanism. The calls look like this: In StatefulComponentInstanceInterceptor: - we call DistributableCache.get() to get the StatefulSessionComponent instance to be used in the invocation - this results in two get()s: one for the bean value and one for the group value In StatefulSessionSynchronizationInterceptor: - we call DistributableCache.release() to free the StatefulSessionComponent instance used in the invocation - this results in two get()s: one for the bean value and one for the group value - this also results in one put, to save the changes made in the invocation to the cache These are all in one transaction. It's not possible as far as I can tell, which of these invocations caused the failure. So, for each invocation, these five cache operations should be in the same ISPN transaction. was (Author: rachmato): I've had another look at this from the EJB side. There are actually 5 cache accesses to the cache remote-failover-test.jar(dist_sync) for each invocation. All five of these accesses are wrapped into one Infinispan transaction by Paul's Batch mechanism. The calls look like this: In StatefulComponentInstanceInterceptor: - we call DistributableCache.get() to get the StatefulSessionComponent instance to be used in the invocation - this results in two get()s: one for the bean value and one for the group value In StatefulSessionSynchronizationInterceptor: - we call DistributableCache.release() to free the StatefulSessionComponent instance used in the invocation - this results in two get()s: one for the bean value and one for the group value - this also results in one put, to save the changes made in the invocation to the cache These are all in one transaction. It's not possible as far as I can tell, which of these invocations caused the failure. So, for each invocation, these five cache operations should be in the same transaction. > RemoteFailoverTestCast#testGracefulShutdownConcurrentFailover fails with "ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations." > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7029 > URL: https://issues.jboss.org/browse/WFLY-7029 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Richard Achmatowicz > > https://ci.wildfly.org/viewLog.html?buildId=24851&tab=buildResultsDiv&bui... > {noformat} > 04:31:43,323 INFO [org.jboss.as.test.clustering.NodeUtil] (main) Stopping container=container-0, timeout=15 > 04:31:43,324 INFO [org.jboss.as.arquillian.container.controller.ClientWildFlyContainerController] (main) Manual stopping of a server instance with timeout=15 > &amp#27;[0m04:31:43,338 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0211: Suspending server with 15000 ms timeout. > &amp#27;[0m04:31:43,343 INFO [org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler] (Remoting "config-based-ejb-client-endpoint" task-10) Retrying invocation which failed on node node-0 with exception:: javax.ejb.NoSuchEJBException: No such EJB[appname=,modulename=remote-failover-test,distinctname=,beanname=SlowToDestroyStatefulIncrementorBean,viewclassname=org.jboss.as.test.clustering.cluster.ejb.remote.bean.Incrementor] > at org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler.processMessage(NoSuchEJBExceptionResponseHandler.java:64) > at org.jboss.ejb.client.remoting.ChannelAssociation.processResponse(ChannelAssociation.java:386) > at org.jboss.ejb.client.remoting.ChannelAssociation$ResponseReceiver.handleMessage(ChannelAssociation.java:498) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > &amp#27;[0m04:31:43,345 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' > &amp#27;[0m&amp#27;[0m04:31:43,430 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping > &amp#27;[0m&amp#27;[0m04:31:43,436 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 29) MODCLUSTER000002: Initiating mod_cluster shutdown > &amp#27;[0m&amp#27;[0m04:31:43,445 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 74) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:/ConnectionFactory > &amp#27;[0m&amp#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000080: Disconnecting JGroups channel hibernate > &amp#27;[0m&amp#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher for channel hibernate > &amp#27;[0m&amp#27;[0m04:31:43,463 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000080: Disconnecting JGroups channel server > &amp#27;[0m&amp#27;[0m04:31:43,464 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000082: Stopping the RpcDispatcher for channel server > &amp#27;[0m&amp#27;[0m04:31:43,471 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000029: Passivating all entries to disk > &amp#27;[0m&amp#27;[0m04:31:43,472 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000030: Passivated 2 entries in 0 milliseconds > &amp#27;[0m&amp#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel web > &amp#27;[0m&amp#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel web > &amp#27;[0m&amp#27;[0m04:31:43,502 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 29) WFLYCLINF0003: Stopped remote-failover-test.jar cache from ejb container > &amp#27;[0m&amp#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel testDbPersistence > &amp#27;[0m&amp#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel testDbPersistence > &amp#27;[0m&amp#27;[33m04:31:43,502 WARN [org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler] (thread-11,ee,node-0) ISPN000071: Caught exception when handling command LockControlCommand{cache=remote-failover-test.jar, keys=[UnknownSessionID [6951504948515351686656515249505365655750686851525048706670486766]], flags=[FORCE_WRITE_LOCK], unlock=false, gtx=GlobalTransaction:<node-1>:48:remote}: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > at org.jgroups.JChannel.up(JChannel.java:738) > at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120) > at org.jgroups.stack.Protocol.up(Protocol.java:380) > at org.jgroups.protocols.FORK.up(FORK.java:114) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070) > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD.up(FD.java:260) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) > at org.jgroups.protocols.Discovery.up(Discovery.java:296) > at org.jgroups.protocols.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52) > at java.lang.Thread.run(Thread.java:745) > &amp#27;[0m&amp#27;[0m04:31:43,517 INFO [org.wildfly.extension.messaging-activemq] (MSC service thread 1-2) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory > &amp#27;[0m&amp#27;[0m04:31:43,517 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > &amp#27;[0m&amp#27;[0m04:31:43,518 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA] > &amp#27;[0m&amp#27;[0m04:31:43,535 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-8) WFLYJCA0019: Stopped Driver service with driver-name = h2 > &amp#27;[0m&amp#27;[0m04:31:43,547 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 2) WFLYCLINF0003: Stopped client-mappings cache from ejb container > &amp#27;[0m04:31:43,565 INFO [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-14) EJBCLIENT000016: Channel Channel ID b007a55b (outbound) of Remoting connection 017c35ab to /0:0:0:0:0:0:0:1:8080 of endpoint "config-based-ejb-client-endpoint" <1c33eee> can no longer process messages > &amp#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000080: Disconnecting JGroups channel ejb > &amp#27;[0m&amp#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000082: Stopping the RpcDispatcher for channel ejb > &amp#27;[0m&amp#27;[0m04:31:43,575 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 35) AMQ151003: resource adaptor stopped > &amp#27;[0m&amp#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow AJP listener ajp suspending > &amp#27;[0m&amp#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [::1]:8009 > &amp#27;[0m&amp#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTPS listener https suspending > &amp#27;[0m&amp#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [::1]:8443 > &amp#27;[0m&amp#27;[31m04:31:43,585 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-11) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace > at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:795) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642) > at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602) > at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577) > at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) > at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962) > at org.infinispan.remoting.transport.jgroups.RspListFuture.futureDone(RspListFuture.java:31) > at org.jgroups.blocks.Request.checkCompletion(Request.java:152) > at org.jgroups.blocks.GroupRequest.receiveResponse(GroupRequest.java:116) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:427) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > at org.jgroups.JChannel.up(JChannel.java:738) > at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120) > at org.jgroups.stack.Protocol.up(Protocol.java:380) > at org.jgroups.protocols.FORK.up(FORK.java:114) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070) > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD.up(FD.java:260) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) > at org.jgroups.protocols.Discovery.up(Discovery.java:296) > at org.jgroups.protocols.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.infinispan.commons.CacheException: Problems invoking command. > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.exceptionHandlingCommand(BasePerCacheInboundInvocationHandler.java:106) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:101) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > ... 27 more > Caused by: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > ... 33 more > &amp#27;[0m&amp#27;[31m04:31:43,588 ERROR [org.jboss.as.ejb3.invocation] (default task-11) WFLYEJB0034: EJB Invocation failed on component SlowToDestroyStatefulIncrementorBean for method public abstract org.jboss.as.test.clustering.cluster.ejb.remote.bean.Result org.jboss.as.test.clustering.cluster.ejb.remote.bean.Incrementor.increment(): javax.ejb.EJBException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace > at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:328) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:201) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:263) > at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213) > at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76) > at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace > at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:795) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642) > at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602) > at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577) > at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) > at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962) > at org.infinispan.remoting.transport.jgroups.RspListFuture.futureDone(RspListFuture.java:31) > at org.jgroups.blocks.Request.checkCompletion(Request.java:152) > at org.jgroups.blocks.GroupRequest.receiveResponse(GroupRequest.java:116) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:427) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > at org.jgroups.JChannel.up(JChannel.java:738) > at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120) > at org.jgroups.stack.Protocol.up(Protocol.java:380) > at org.jgroups.protocols.FORK.up(FORK.java:114) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070) > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD.up(FD.java:260) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) > at org.jgroups.protocols.Discovery.up(Discovery.java:296) > at org.jgroups.protocols.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52) > ... 1 more > Caused by: org.infinispan.commons.CacheException: Problems invoking command. > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.exceptionHandlingCommand(BasePerCacheInboundInvocationHandler.java:106) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:101) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > ... 27 more > Caused by: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > ... 33 more > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7029) RemoteFailoverTestCast#testGracefulShutdownConcurrentFailover fails with "ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations."

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/WFLY-7029?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz commented on WFLY-7029: ------------------------------------------- I've had another look at this from the EJB side. There are actually 5 cache accesses to the cache remote-failover-test.jar(dist_sync) for each invocation. All five of these accesses are wrapped into one Infinispan transaction by Paul's Batch mechanism. The calls look like this: In StatefulComponentInstanceInterceptor: - we call DistributableCache.get() to get the StatefulSessionComponent instance to be used in the invocation - this results in two get()s: one for the bean value and one for the group value In StatefulSessionSynchronizationInterceptor: - we call DistributableCache.release() to free the StatefulSessionComponent instance used in the invocation - this results in two get()s: one for the bean value and one for the group value - this also results in one put, to save the changes made in the invocation to the cache These are all in one transaction. It's not possible as far as I can tell, which of these invocations caused the failure. So, for each invocation, these five cache operations should be in the same transaction. > RemoteFailoverTestCast#testGracefulShutdownConcurrentFailover fails with "ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations." > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7029 > URL: https://issues.jboss.org/browse/WFLY-7029 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Richard Achmatowicz > > https://ci.wildfly.org/viewLog.html?buildId=24851&tab=buildResultsDiv&bui... > {noformat} > 04:31:43,323 INFO [org.jboss.as.test.clustering.NodeUtil] (main) Stopping container=container-0, timeout=15 > 04:31:43,324 INFO [org.jboss.as.arquillian.container.controller.ClientWildFlyContainerController] (main) Manual stopping of a server instance with timeout=15 > &amp#27;[0m04:31:43,338 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0211: Suspending server with 15000 ms timeout. > &amp#27;[0m04:31:43,343 INFO [org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler] (Remoting "config-based-ejb-client-endpoint" task-10) Retrying invocation which failed on node node-0 with exception:: javax.ejb.NoSuchEJBException: No such EJB[appname=,modulename=remote-failover-test,distinctname=,beanname=SlowToDestroyStatefulIncrementorBean,viewclassname=org.jboss.as.test.clustering.cluster.ejb.remote.bean.Incrementor] > at org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler.processMessage(NoSuchEJBExceptionResponseHandler.java:64) > at org.jboss.ejb.client.remoting.ChannelAssociation.processResponse(ChannelAssociation.java:386) > at org.jboss.ejb.client.remoting.ChannelAssociation$ResponseReceiver.handleMessage(ChannelAssociation.java:498) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > &amp#27;[0m04:31:43,345 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown' > &amp#27;[0m&amp#27;[0m04:31:43,430 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping > &amp#27;[0m&amp#27;[0m04:31:43,436 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 29) MODCLUSTER000002: Initiating mod_cluster shutdown > &amp#27;[0m&amp#27;[0m04:31:43,445 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 74) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:/ConnectionFactory > &amp#27;[0m&amp#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000080: Disconnecting JGroups channel hibernate > &amp#27;[0m&amp#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher for channel hibernate > &amp#27;[0m&amp#27;[0m04:31:43,463 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000080: Disconnecting JGroups channel server > &amp#27;[0m&amp#27;[0m04:31:43,464 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000082: Stopping the RpcDispatcher for channel server > &amp#27;[0m&amp#27;[0m04:31:43,471 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000029: Passivating all entries to disk > &amp#27;[0m&amp#27;[0m04:31:43,472 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000030: Passivated 2 entries in 0 milliseconds > &amp#27;[0m&amp#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel web > &amp#27;[0m&amp#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel web > &amp#27;[0m&amp#27;[0m04:31:43,502 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 29) WFLYCLINF0003: Stopped remote-failover-test.jar cache from ejb container > &amp#27;[0m&amp#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel testDbPersistence > &amp#27;[0m&amp#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel testDbPersistence > &amp#27;[0m&amp#27;[33m04:31:43,502 WARN [org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler] (thread-11,ee,node-0) ISPN000071: Caught exception when handling command LockControlCommand{cache=remote-failover-test.jar, keys=[UnknownSessionID [6951504948515351686656515249505365655750686851525048706670486766]], flags=[FORCE_WRITE_LOCK], unlock=false, gtx=GlobalTransaction:<node-1>:48:remote}: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > at org.jgroups.JChannel.up(JChannel.java:738) > at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120) > at org.jgroups.stack.Protocol.up(Protocol.java:380) > at org.jgroups.protocols.FORK.up(FORK.java:114) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070) > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD.up(FD.java:260) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) > at org.jgroups.protocols.Discovery.up(Discovery.java:296) > at org.jgroups.protocols.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52) > at java.lang.Thread.run(Thread.java:745) > &amp#27;[0m&amp#27;[0m04:31:43,517 INFO [org.wildfly.extension.messaging-activemq] (MSC service thread 1-2) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory > &amp#27;[0m&amp#27;[0m04:31:43,517 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > &amp#27;[0m&amp#27;[0m04:31:43,518 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA] > &amp#27;[0m&amp#27;[0m04:31:43,535 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-8) WFLYJCA0019: Stopped Driver service with driver-name = h2 > &amp#27;[0m&amp#27;[0m04:31:43,547 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 2) WFLYCLINF0003: Stopped client-mappings cache from ejb container > &amp#27;[0m04:31:43,565 INFO [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-14) EJBCLIENT000016: Channel Channel ID b007a55b (outbound) of Remoting connection 017c35ab to /0:0:0:0:0:0:0:1:8080 of endpoint "config-based-ejb-client-endpoint" <1c33eee> can no longer process messages > &amp#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000080: Disconnecting JGroups channel ejb > &amp#27;[0m&amp#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000082: Stopping the RpcDispatcher for channel ejb > &amp#27;[0m&amp#27;[0m04:31:43,575 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 35) AMQ151003: resource adaptor stopped > &amp#27;[0m&amp#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow AJP listener ajp suspending > &amp#27;[0m&amp#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow AJP listener ajp stopped, was bound to [::1]:8009 > &amp#27;[0m&amp#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTPS listener https suspending > &amp#27;[0m&amp#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to [::1]:8443 > &amp#27;[0m&amp#27;[31m04:31:43,585 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-11) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace > at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:795) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642) > at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602) > at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577) > at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) > at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962) > at org.infinispan.remoting.transport.jgroups.RspListFuture.futureDone(RspListFuture.java:31) > at org.jgroups.blocks.Request.checkCompletion(Request.java:152) > at org.jgroups.blocks.GroupRequest.receiveResponse(GroupRequest.java:116) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:427) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > at org.jgroups.JChannel.up(JChannel.java:738) > at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120) > at org.jgroups.stack.Protocol.up(Protocol.java:380) > at org.jgroups.protocols.FORK.up(FORK.java:114) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070) > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD.up(FD.java:260) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) > at org.jgroups.protocols.Discovery.up(Discovery.java:296) > at org.jgroups.protocols.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.infinispan.commons.CacheException: Problems invoking command. > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.exceptionHandlingCommand(BasePerCacheInboundInvocationHandler.java:106) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:101) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > ... 27 more > Caused by: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > ... 33 more > &amp#27;[0m&amp#27;[31m04:31:43,588 ERROR [org.jboss.as.ejb3.invocation] (default task-11) WFLYEJB0034: EJB Invocation failed on component SlowToDestroyStatefulIncrementorBean for method public abstract org.jboss.as.test.clustering.cluster.ejb.remote.bean.Result org.jboss.as.test.clustering.cluster.ejb.remote.bean.Incrementor.increment(): javax.ejb.EJBException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace > at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:328) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:201) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:263) > at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213) > at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76) > at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node-0, see cause for remote stack trace > at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:795) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642) > at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602) > at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577) > at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) > at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962) > at org.infinispan.remoting.transport.jgroups.RspListFuture.futureDone(RspListFuture.java:31) > at org.jgroups.blocks.Request.checkCompletion(Request.java:152) > at org.jgroups.blocks.GroupRequest.receiveResponse(GroupRequest.java:116) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:427) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:357) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:245) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664) > at org.jgroups.JChannel.up(JChannel.java:738) > at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120) > at org.jgroups.stack.Protocol.up(Protocol.java:380) > at org.jgroups.protocols.FORK.up(FORK.java:114) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1040) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) > at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070) > at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:649) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD.up(FD.java:260) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) > at org.jgroups.protocols.Discovery.up(Discovery.java:296) > at org.jgroups.protocols.MPING.up(MPING.java:178) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52) > ... 1 more > Caused by: org.infinispan.commons.CacheException: Problems invoking command. > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.exceptionHandlingCommand(BasePerCacheInboundInvocationHandler.java:106) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:101) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleCacheRpcCommand(GlobalInboundInvocationHandler.java:126) > at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.handleFromCluster(GlobalInboundInvocationHandler.java:75) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:205) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:175) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:455) > at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:406) > ... 27 more > Caused by: org.infinispan.IllegalLifecycleStateException: ISPN000324: remote-failover-test.jar is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:364) > at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:354) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:138) > at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:38) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.createContext(PendingTxAction.java:107) > at org.infinispan.remoting.inboundhandler.action.PendingTxAction.init(PendingTxAction.java:57) > at org.infinispan.remoting.inboundhandler.action.BaseLockingAction.check(BaseLockingAction.java:38) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:42) > at org.infinispan.remoting.inboundhandler.action.DefaultReadyAction.isReady(DefaultReadyAction.java:45) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler$1.isReady(NonTotalOrderTxPerCacheInboundInvocationHandler.java:124) > at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl.execute(BlockingTaskAwareExecutorServiceImpl.java:51) > at org.infinispan.executors.LazyInitializingBlockingTaskAwareExecutorService.execute(LazyInitializingBlockingTaskAwareExecutorService.java:46) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.handleRunnable(BasePerCacheInboundInvocationHandler.java:130) > at org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler.handle(NonTotalOrderTxPerCacheInboundInvocationHandler.java:99) > ... 33 more > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5265) Use WildFly Common for null param checks

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-5265?page=com.atlassian.jira.plugin.... ] David Lloyd reassigned WFLY-5265: --------------------------------- Assignee: David Lloyd In for a penny, in for a pound. > Use WildFly Common for null param checks > ---------------------------------------- > > Key: WFLY-5265 > URL: https://issues.jboss.org/browse/WFLY-5265 > Project: WildFly > Issue Type: Task > Reporter: David Lloyd > Assignee: David Lloyd > Priority: Minor > Fix For: 11.0.0.Alpha1 > > > For each module, do the following: > * Locate any/all null param check methods in the log msg > * Replace them with calls to org.wildfly.common.Assert#checkNotNullParam or related method as needed > * Replace the old null param check method with a comment that reserves the ID and shows that it was previously used for that purpose -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7069) EJBs accessible too early (spec violation) - deployment marked started before ready

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-7069?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-7069: ---------------------------------------- [~bmaxwell] Can you further describe what the problem is here? I'm not sure what "marked started in the deployment repository" means or how that relates to "resulting in requests being accepted." > EJBs accessible too early (spec violation) - deployment marked started before ready > ----------------------------------------------------------------------------------- > > Key: WFLY-7069 > URL: https://issues.jboss.org/browse/WFLY-7069 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.1.0.Final > Reporter: Brad Maxwell > Assignee: Fedor Gavrilov > > Follow up of WFLY-6402, the deployment is being marked started in the deployment repository before it is ready, resulting in requests being accepted. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7018) Valid Wildfly 10.0.0.Final DataSource fails in Wildfly 10.1.0.Final

by Mark S (JIRA)

[ https://issues.jboss.org/browse/WFLY-7018?page=com.atlassian.jira.plugin.... ] Mark S edited comment on WFLY-7018 at 9/7/16 12:57 PM: ------------------------------------------------------- Just a quick note. I set the {{datasource-class}} value (Which seems like it is the preferred way) and in Wildfly 10.1.0.Final I tried to set the connection value via {{<connection-property name="url">}} instead of {{<connection-url>}}, though I got exceptions unless both values where present (Like in the example above). [~gaol]: I have a couple of questions in relation to your recent comments. *Question 1:* It sounds like Wildfly DataSources will be configured differently in future, with different cli commands. Is this correct? *Question 2:* Is there a better work-around than the above example, so that I can get a Wildfly 10.0.0.Final DataSource working again in Wildfly 10.1.0.Final? *Question 3:* Could you provide a sample Wildfly 10.1.0.Final DataSource XML configuration ({{<subsystem xmlns="urn:jboss:domain:datasources:4.0"></subsystem>}}) that would work? *Question 4:* Could you provide a sample Wildfly 10.1.0.Final DataSource CLI configuration that would work? h3. Official Documentation on Wildfly 10 Datasources [Official Wildfly 10 DataSource Configuration|https://docs.jboss.org/author/display/WFLY10/DataSource+con...] Which links to [Official IronJacammar PostgresSql DataSource Configuration |http://www.ironjacamar.org/doc/userguide/1.1/en-US/html_single/index.html#ex_datasources_postgresql] was (Author: marks1900): Just a quick note. I set the {{datasource-class}} value (Which seems like it is the preferred way) and in Wildfly 10.1.0.Final I tried to set the connection value via {{<connection-property name="url">}} instead of {{<connection-url>}}, though I got exceptions unless both values where present (Like in the example above). [~gaol]: I have a couple of questions in relation to your recent comments. *Question 1:* In your recent comments, it sounds like Wildfly DataSources will be configured differently in future, with different cli commands. Is this correct? *Question 2:* Is there a better work-around than the above example, so that I can get a Wildfly 10.0.0.Final DataSource working again in Wildfly 10.1.0.Final? *Question 3:* Could you provide a sample Wildfly 10.1.0.Final DataSource XML configuration ({{<subsystem xmlns="urn:jboss:domain:datasources:4.0"></subsystem>}}) that would work? *Question 4:* Could you provide a sample Wildfly 10.1.0.Final DataSource CLI configuration that would work? h3. Official Documentation on Wildfly 10 Datasources [Official Wildfly 10 DataSource Configuration|https://docs.jboss.org/author/display/WFLY10/DataSource+con...] Which links to [Official IronJacammar PostgresSql DataSource Configuration |http://www.ironjacamar.org/doc/userguide/1.1/en-US/html_single/index.html#ex_datasources_postgresql] > Valid Wildfly 10.0.0.Final DataSource fails in Wildfly 10.1.0.Final > ------------------------------------------------------------------- > > Key: WFLY-7018 > URL: https://issues.jboss.org/browse/WFLY-7018 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 10.1.0.Final > Reporter: Mark S > Assignee: Lin Gao > > My current Wildfly 10.0.0.Final (Non-XA) Datasource configuration will not work for Wildfly 10.1.0.Final. See the "Steps to Reproduce" section. > The stacktrace points to here: > * https://source.jboss.org/browse/IronJacamar/adapters/src/main/java/org/jb... > * https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.3.4.Final/a... > h3. The work-around > h3. Wildfly 10.1.0.Final Datasource configuration via CLI > {code} > # No parameter to set a connection property value. > {code} > h3. Wildfly 10.1.0.Final Datasource configuration via XML (standalone-full.xml) > Note the addition of {{<connection-property name="databaseName">myapp</connection-property>}} > {code:xml} > <subsystem xmlns="urn:jboss:domain:datasources:4.0"> > <datasources> > <datasource jndi-name="java:/MY_APP_DS" pool-name="Postgres_MY_APP_DS"> > <connection-url>jdbc:postgresql://localhost:5432/myapp</connection-url> > <connection-property name="databaseName">myapp</connection-property> > <driver>postgres</driver> > <security> > <user-name>myapp</user-name> > <password>myapp</password> > </security> > <validation> > <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/> > <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/> > </validation> > </datasource> > <drivers> > <driver name="postgres" module="org.postgres"> > <driver-class>org.postgresql.Driver</driver-class> > <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class> > <datasource-class>org.postgresql.ds.PGSimpleDataSource</datasource-class> > </driver> > </drivers> > </datasources> > </subsystem> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7018) Valid Wildfly 10.0.0.Final DataSource fails in Wildfly 10.1.0.Final

by Mark S (JIRA)

[ https://issues.jboss.org/browse/WFLY-7018?page=com.atlassian.jira.plugin.... ] Mark S edited comment on WFLY-7018 at 9/7/16 12:45 PM: ------------------------------------------------------- Just a quick note. I set the {{datasource-class}} value (Which seems like it is the preferred way) and in Wildfly 10.1.0.Final I tried to set the connection value via {{<connection-property name="url">}} instead of {{<connection-url>}}, though I got exceptions unless both values where present (Like in the example above). [~gaol]: I have a couple of questions in relation to your recent comments. *Question 1:* In your recent comments, it sounds like Wildfly DataSources will be configured differently in future, with different cli commands. Is this correct? *Question 2:* Is there a better work-around than the above example, so that I can get a Wildfly 10.0.0.Final DataSource working again in Wildfly 10.1.0.Final? *Question 3:* Could you provide a sample Wildfly 10.1.0.Final DataSource XML configuration ({{<subsystem xmlns="urn:jboss:domain:datasources:4.0"></subsystem>}}) that would work? *Question 4:* Could you provide a sample Wildfly 10.1.0.Final DataSource CLI configuration that would work? h3. Official Documentation on Wildfly 10 Datasources [Official Wildfly 10 DataSource Configuration|https://docs.jboss.org/author/display/WFLY10/DataSource+con...] Which links to [Official IronJacammar PostgresSql DataSource Configuration |http://www.ironjacamar.org/doc/userguide/1.1/en-US/html_single/index.html#ex_datasources_postgresql] was (Author: marks1900): Just a quick note. I set the {{datasource-class}} value (Which seems like it is the preferred way) and in Wildfly 10.1.0.Final I tried to set the connection value via {{<connection-property name="url">}} instead of {{<connection-url>}}, though I got exceptions unless both values where present (Like in the example above). [~gaol]: I have a couple of questions in relation to your recent comments. *Question:* In your recent comments, it sounds like Wildfly DataSources will be configured differently in future, with different cli commands. Is this correct? *Question:* Is there a better work-around than the above example, so that I can get a Wildfly 10.0.0.Final DataSource working again in Wildfly 10.1.0.Final? *Question:* Could you provide a sample Wildfly 10.1.0.Final DataSource XML configuration ({{<subsystem xmlns="urn:jboss:domain:datasources:4.0"></subsystem>}}) that would work? *Question:* Could you provide a sample Wildfly 10.1.0.Final DataSource CLI configuration that would work? h3. Official Documentation on Wildfly 10 Datasources [Official Wildfly 10 DataSource Configuration|https://docs.jboss.org/author/display/WFLY10/DataSource+con...] Which links to [Official IronJacammar PostgresSql DataSource Configuration |http://www.ironjacamar.org/doc/userguide/1.1/en-US/html_single/index.html#ex_datasources_postgresql] > Valid Wildfly 10.0.0.Final DataSource fails in Wildfly 10.1.0.Final > ------------------------------------------------------------------- > > Key: WFLY-7018 > URL: https://issues.jboss.org/browse/WFLY-7018 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 10.1.0.Final > Reporter: Mark S > Assignee: Lin Gao > > My current Wildfly 10.0.0.Final (Non-XA) Datasource configuration will not work for Wildfly 10.1.0.Final. See the "Steps to Reproduce" section. > The stacktrace points to here: > * https://source.jboss.org/browse/IronJacamar/adapters/src/main/java/org/jb... > * https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.3.4.Final/a... > h3. The work-around > h3. Wildfly 10.1.0.Final Datasource configuration via CLI > {code} > # No parameter to set a connection property value. > {code} > h3. Wildfly 10.1.0.Final Datasource configuration via XML (standalone-full.xml) > Note the addition of {{<connection-property name="databaseName">myapp</connection-property>}} > {code:xml} > <subsystem xmlns="urn:jboss:domain:datasources:4.0"> > <datasources> > <datasource jndi-name="java:/MY_APP_DS" pool-name="Postgres_MY_APP_DS"> > <connection-url>jdbc:postgresql://localhost:5432/myapp</connection-url> > <connection-property name="databaseName">myapp</connection-property> > <driver>postgres</driver> > <security> > <user-name>myapp</user-name> > <password>myapp</password> > </security> > <validation> > <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/> > <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/> > </validation> > </datasource> > <drivers> > <driver name="postgres" module="org.postgres"> > <driver-class>org.postgresql.Driver</driver-class> > <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class> > <datasource-class>org.postgresql.ds.PGSimpleDataSource</datasource-class> > </driver> > </drivers> > </datasources> > </subsystem> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7018) Valid Wildfly 10.0.0.Final DataSource fails in Wildfly 10.1.0.Final

by Mark S (JIRA)

[ https://issues.jboss.org/browse/WFLY-7018?page=com.atlassian.jira.plugin.... ] Mark S commented on WFLY-7018: ------------------------------ Just a quick note. I set the {{datasource-class}} value (Which seems like it is the preferred way) and in Wildfly 10.1.0.Final I tried to set the connection value via {{<connection-property name="url">}} instead of {{<connection-url>}}, though I got exceptions unless both values where present (Like in the example above). [~gaol]: I have a couple of questions in relation to your recent comments. *Question:* In your recent comments, it sounds like Wildfly DataSources will be configured differently in future, with different cli commands. Is this correct? *Question:* Is there a better work-around than the above example, so that I can get a Wildfly 10.0.0.Final DataSource working again in Wildfly 10.1.0.Final? *Question:* Could you provide a sample Wildfly 10.1.0.Final DataSource XML configuration ({{<subsystem xmlns="urn:jboss:domain:datasources:4.0"></subsystem>}}) that would work? *Question:* Could you provide a sample Wildfly 10.1.0.Final DataSource CLI configuration that would work? h3. Official Documentation on Wildfly 10 Datasources [Official Wildfly 10 DataSource Configuration|https://docs.jboss.org/author/display/WFLY10/DataSource+con...] Which links to [Official IronJacammar PostgresSql DataSource Configuration |http://www.ironjacamar.org/doc/userguide/1.1/en-US/html_single/index.html#ex_datasources_postgresql] > Valid Wildfly 10.0.0.Final DataSource fails in Wildfly 10.1.0.Final > ------------------------------------------------------------------- > > Key: WFLY-7018 > URL: https://issues.jboss.org/browse/WFLY-7018 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 10.1.0.Final > Reporter: Mark S > Assignee: Lin Gao > > My current Wildfly 10.0.0.Final (Non-XA) Datasource configuration will not work for Wildfly 10.1.0.Final. See the "Steps to Reproduce" section. > The stacktrace points to here: > * https://source.jboss.org/browse/IronJacamar/adapters/src/main/java/org/jb... > * https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.3.4.Final/a... > h3. The work-around > h3. Wildfly 10.1.0.Final Datasource configuration via CLI > {code} > # No parameter to set a connection property value. > {code} > h3. Wildfly 10.1.0.Final Datasource configuration via XML (standalone-full.xml) > Note the addition of {{<connection-property name="databaseName">myapp</connection-property>}} > {code:xml} > <subsystem xmlns="urn:jboss:domain:datasources:4.0"> > <datasources> > <datasource jndi-name="java:/MY_APP_DS" pool-name="Postgres_MY_APP_DS"> > <connection-url>jdbc:postgresql://localhost:5432/myapp</connection-url> > <connection-property name="databaseName">myapp</connection-property> > <driver>postgres</driver> > <security> > <user-name>myapp</user-name> > <password>myapp</password> > </security> > <validation> > <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/> > <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/> > </validation> > </datasource> > <drivers> > <driver name="postgres" module="org.postgres"> > <driver-class>org.postgresql.Driver</driver-class> > <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class> > <datasource-class>org.postgresql.ds.PGSimpleDataSource</datasource-class> > </driver> > </drivers> > </datasources> > </subsystem> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1683) Home and End keys doesn't work on Windows

by Alexey Loubyansky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1683?page=com.atlassian.jira.plugi... ] Alexey Loubyansky resolved WFCORE-1683. --------------------------------------- Fix Version/s: 3.0.0.Alpha8 Resolution: Done [~pkremens], thanks for confirming. The bug has been fixed in Aesh 0.66.9. Current version used by the core is 0.66.10. > Home and End keys doesn't work on Windows > ----------------------------------------- > > Key: WFCORE-1683 > URL: https://issues.jboss.org/browse/WFCORE-1683 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Petr Kremensky > Assignee: Alexey Loubyansky > Fix For: 3.0.0.Alpha8 > > > Home and End keys doesn't work properly on Windows. > *actual* > {noformat} > [disconnected /] echo<HOME> test > [disconnected /] echoαG[] test > [disconnected /] echo<END> test > [disconnected /] echoαO[] test > {noformat} > *expected* > {noformat} > [disconnected /] echo<HOME> test > [disconnected /] []echo test > [disconnected /] echo<END> test > [disconnected /] echo test[] > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7018) Valid Wildfly 10.0.0.Final DataSource fails in Wildfly 10.1.0.Final

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-7018?page=com.atlassian.jira.plugin.... ] Lin Gao commented on WFLY-7018: ------------------------------- When {{connection-url}} is defined, and the {{datasource-class}} is *NOT* defined either in {{driver}} or in {{data-source}} element, IronJacamar uses [java.sql.DriverManager.getConnection(String url, String username, String password)|https://docs.oracle.com/javase/8/docs/api/java/sql/DriverManage...] to get the database connection by using the specified {{connection-url}}. When {{datasource-class}} is defined either in {{driver}} or in {{data-source}} element, IronJacamar uses DataSource to get the database connection, which is the [preferred way|https://docs.oracle.com/javase/tutorial/jdbc/basics/connecting.html]. A set of connection property needs to be defined to connect database via [DataSource|https://docs.oracle.com/javase/8/docs/api/javax/sql/DataSource...]. In case of PostgreSQL server, I think you can specify: {code:xml} <connection-property name="url">jdbc:postgresql://localhost:5432/myapp</connection-property> {code} instead of defining the {{<connection-url>}} in your configuration. If you still want to use the {{connection-url}} configuration, remove the {{datasource-class}} definition in {{driver}} element can also be fine, but it is not recommended. With WFCORE-1362 resolved, the command: {code:java} data-source add --connection-properties={"url"=>"myurl","user"=>"user","pass"=>"pass"} {code} supports specifying the {{connection-properties}} in one go when adding a new data-source. > Valid Wildfly 10.0.0.Final DataSource fails in Wildfly 10.1.0.Final > ------------------------------------------------------------------- > > Key: WFLY-7018 > URL: https://issues.jboss.org/browse/WFLY-7018 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 10.1.0.Final > Reporter: Mark S > Assignee: Lin Gao > > My current Wildfly 10.0.0.Final (Non-XA) Datasource configuration will not work for Wildfly 10.1.0.Final. See the "Steps to Reproduce" section. > The stacktrace points to here: > * https://source.jboss.org/browse/IronJacamar/adapters/src/main/java/org/jb... > * https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.3.4.Final/a... > h3. The work-around > h3. Wildfly 10.1.0.Final Datasource configuration via CLI > {code} > # No parameter to set a connection property value. > {code} > h3. Wildfly 10.1.0.Final Datasource configuration via XML (standalone-full.xml) > Note the addition of {{<connection-property name="databaseName">myapp</connection-property>}} > {code:xml} > <subsystem xmlns="urn:jboss:domain:datasources:4.0"> > <datasources> > <datasource jndi-name="java:/MY_APP_DS" pool-name="Postgres_MY_APP_DS"> > <connection-url>jdbc:postgresql://localhost:5432/myapp</connection-url> > <connection-property name="databaseName">myapp</connection-property> > <driver>postgres</driver> > <security> > <user-name>myapp</user-name> > <password>myapp</password> > </security> > <validation> > <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/> > <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/> > </validation> > </datasource> > <drivers> > <driver name="postgres" module="org.postgres"> > <driver-class>org.postgresql.Driver</driver-class> > <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class> > <datasource-class>org.postgresql.ds.PGSimpleDataSource</datasource-class> > </driver> > </drivers> > </datasources> > </subsystem> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1683) Home and End keys doesn't work on Windows

by Petr Kremensky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1683?page=com.atlassian.jira.plugi... ] Petr Kremensky commented on WFCORE-1683: ---------------------------------------- [~aloubyansky] This one can be closed (not sure whether I can/should change the state of upstream issues thus letting you know) > Home and End keys doesn't work on Windows > ----------------------------------------- > > Key: WFCORE-1683 > URL: https://issues.jboss.org/browse/WFCORE-1683 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Petr Kremensky > Assignee: Alexey Loubyansky > > Home and End keys doesn't work properly on Windows. > *actual* > {noformat} > [disconnected /] echo<HOME> test > [disconnected /] echoαG[] test > [disconnected /] echo<END> test > [disconnected /] echoαO[] test > {noformat} > *expected* > {noformat} > [disconnected /] echo<HOME> test > [disconnected /] []echo test > [disconnected /] echo<END> test > [disconnected /] echo test[] > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7070) EJBs accessible too early (spec violation) - deployment marked started before ready

by Brad Maxwell (JIRA)

Brad Maxwell created WFLY-7070: ---------------------------------- Summary: EJBs accessible too early (spec violation) - deployment marked started before ready Key: WFLY-7070 URL: https://issues.jboss.org/browse/WFLY-7070 Project: WildFly Issue Type: Bug Affects Versions: 10.1.0.Final Reporter: Brad Maxwell Assignee: Fedor Gavrilov Follow up of WFLY-6402, the deployment is being marked started in the deployment repository before it is ready, resulting in requests being accepted. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7069) EJBs accessible too early (spec violation) - deployment marked started before ready

by Brad Maxwell (JIRA)

Brad Maxwell created WFLY-7069: ---------------------------------- Summary: EJBs accessible too early (spec violation) - deployment marked started before ready Key: WFLY-7069 URL: https://issues.jboss.org/browse/WFLY-7069 Project: WildFly Issue Type: Bug Affects Versions: 10.1.0.Final Reporter: Brad Maxwell Assignee: Fedor Gavrilov Follow up of WFLY-6402, the deployment is being marked started in the deployment repository before it is ready, resulting in requests being accepted. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-955) Regression in parsing username in LdapExtLoginModule

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/SECURITY-955?page=com.atlassian.jira.plug... ] Ilia Vassilev reassigned SECURITY-955: -------------------------------------- Assignee: Ilia Vassilev (was: Stefan Guilhen) > Regression in parsing username in LdapExtLoginModule > ---------------------------------------------------- > > Key: SECURITY-955 > URL: https://issues.jboss.org/browse/SECURITY-955 > Project: PicketBox > Issue Type: Bug > Affects Versions: PicketBox_5_0_0.Alpha3 > Reporter: Ondrej Lukas > Assignee: Ilia Vassilev > Priority: Blocker > > In case when customers using LdapExtLoginModule with option parseUsername=true but without option usernameBeginString (i.e. usernameBeginString=null) then all users cannot be successfully authenticated into application. Authentication failure is caused by hidden internal NPE. > It is the same issue as was reported in [1], but fix is missing in current EAP 7.1 version of PicketBox (5.0.0.Alpha3). > We request blocker flag because: > * Valid configuration which works for 7.0.x becomes invalid after migration to 7.1.0 > * All users cannot authenticate to application despite of valid EAP configuration > * Authetication failure caused by NPE is logged to server log > Thrown NPE: > {code} > java.lang.NullPointerException > at org.jboss.security.auth.spi.LdapExtLoginModule.getUsername(LdapExtLoginModule.java:963) > at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:342) > at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:283) > {code} > [1] https://issues.jboss.org/browse/JBEAP-364?focusedCommentId=13160168&page=... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-956) New behavior for empty string in rolesCtxDN in LdapExtLoginModule in EAP 7.1

by Ondrej Lukas (JIRA)

Ondrej Lukas created SECURITY-956: ------------------------------------- Summary: New behavior for empty string in rolesCtxDN in LdapExtLoginModule in EAP 7.1 Key: SECURITY-956 URL: https://issues.jboss.org/browse/SECURITY-956 Project: PicketBox Issue Type: Bug Reporter: Ondrej Lukas Assignee: Stefan Guilhen In case when LdapExtLoginModule has option rolesCtxDN set to empty string then it has different behavior in EAP 7.0 (PicketBox 4.9.x) and 7.1 (PicketBox 5.0.x). EAP 7.0 uses empty string as base search for LDAP. * In case when LDAP server supports empty string search base (e.g. Apache DS allows it) it works as expected, all LDAP tree is searched for roles. * In case when LDAP server does not support empty string search base (e.g. Active Directory or Red Hat Directory Server) it thrown exception authentication fails. However exception is expected since it is misconfiguration for those LDAP servers. EAP 7.1 does not search any roles for empty string. That means: * In case when LDAP server supports empty string search base it does not find any roles. However some roles could be found on that type of LDAP servers. * In case when LDAP server does not support empty string search base it correctly returns no roles and authentication passes. >From my PoV, behavior from EAP 7.0 is more correct, because it works correctly for LDAP servers where empty string is legal search base. However it can be decided that current EAP 7.1 behavior is intended. In that case please create Release Notes Jira (because it is change in behavior) and close this Jira. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-956) New behavior for empty string in rolesCtxDN in LdapExtLoginModule in EAP 7.1

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/SECURITY-956?page=com.atlassian.jira.plug... ] Ondrej Lukas updated SECURITY-956: ---------------------------------- Affects Version/s: PicketBox_5_0_0.Alpha3 > New behavior for empty string in rolesCtxDN in LdapExtLoginModule in EAP 7.1 > ---------------------------------------------------------------------------- > > Key: SECURITY-956 > URL: https://issues.jboss.org/browse/SECURITY-956 > Project: PicketBox > Issue Type: Bug > Affects Versions: PicketBox_5_0_0.Alpha3 > Reporter: Ondrej Lukas > Assignee: Stefan Guilhen > > In case when LdapExtLoginModule has option rolesCtxDN set to empty string then it has different behavior in EAP 7.0 (PicketBox 4.9.x) and 7.1 (PicketBox 5.0.x). > EAP 7.0 uses empty string as base search for LDAP. > * In case when LDAP server supports empty string search base (e.g. Apache DS allows it) it works as expected, all LDAP tree is searched for roles. > * In case when LDAP server does not support empty string search base (e.g. Active Directory or Red Hat Directory Server) it thrown exception authentication fails. However exception is expected since it is misconfiguration for those LDAP servers. > EAP 7.1 does not search any roles for empty string. That means: > * In case when LDAP server supports empty string search base it does not find any roles. However some roles could be found on that type of LDAP servers. > * In case when LDAP server does not support empty string search base it correctly returns no roles and authentication passes. > From my PoV, behavior from EAP 7.0 is more correct, because it works correctly for LDAP servers where empty string is legal search base. However it can be decided that current EAP 7.1 behavior is intended. In that case please create Release Notes Jira (because it is change in behavior) and close this Jira. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1270) support fact handle operations for REST APIs on kie server

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1270?page=com.atlassian.jira.plugi... ] Mario Fusco commented on DROOLS-1270: ------------------------------------- Reassigned to [~swiderski.maciej] to allow him to perform some further checks on the kie-server side. > support fact handle operations for REST APIs on kie server > ---------------------------------------------------------- > > Key: DROOLS-1270 > URL: https://issues.jboss.org/browse/DROOLS-1270 > Project: Drools > Issue Type: Enhancement > Components: core engine, kie server > Affects Versions: 6.5.0.CR1 > Environment: kie server > Reporter: Dan Cimpoesu > Assignee: Maciej Swiderski > Fix For: 6.5.0.Final > > > Please support fact handle operations for REST APIs on kie server. > Fact handle operations are currently not supported in kie server as they usually bring less value in rule based systems where most of the operations are stateless. Though they do provide rather big value for processes integrated with rules. > Operations that require fact handles are: > - delete facts > - update facts -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1270) support fact handle operations for REST APIs on kie server

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1270?page=com.atlassian.jira.plugi... ] Mario Fusco commented on DROOLS-1270: ------------------------------------- Fixed by https://github.com/droolsjbpm/drools/commit/67375fecabd5199dc121e4e64f6b9... and https://github.com/droolsjbpm/droolsjbpm-integration/commit/2d30ee6436cff... > support fact handle operations for REST APIs on kie server > ---------------------------------------------------------- > > Key: DROOLS-1270 > URL: https://issues.jboss.org/browse/DROOLS-1270 > Project: Drools > Issue Type: Enhancement > Components: core engine, kie server > Affects Versions: 6.5.0.CR1 > Environment: kie server > Reporter: Dan Cimpoesu > Assignee: Mario Fusco > Fix For: 6.5.0.Final > > > Please support fact handle operations for REST APIs on kie server. > Fact handle operations are currently not supported in kie server as they usually bring less value in rule based systems where most of the operations are stateless. Though they do provide rather big value for processes integrated with rules. > Operations that require fact handles are: > - delete facts > - update facts -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1270) support fact handle operations for REST APIs on kie server

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1270?page=com.atlassian.jira.plugi... ] Mario Fusco reassigned DROOLS-1270: ----------------------------------- Assignee: Maciej Swiderski (was: Mario Fusco) > support fact handle operations for REST APIs on kie server > ---------------------------------------------------------- > > Key: DROOLS-1270 > URL: https://issues.jboss.org/browse/DROOLS-1270 > Project: Drools > Issue Type: Enhancement > Components: core engine, kie server > Affects Versions: 6.5.0.CR1 > Environment: kie server > Reporter: Dan Cimpoesu > Assignee: Maciej Swiderski > Fix For: 6.5.0.Final > > > Please support fact handle operations for REST APIs on kie server. > Fact handle operations are currently not supported in kie server as they usually bring less value in rule based systems where most of the operations are stateless. Though they do provide rather big value for processes integrated with rules. > Operations that require fact handles are: > - delete facts > - update facts -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2099) TP: one single thread pool

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2099?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2099. ---------------------------- Resolution: Done Adjusted all sample configs > TP: one single thread pool > -------------------------- > > Key: JGRP-2099 > URL: https://issues.jboss.org/browse/JGRP-2099 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently, TP has 4 thread pools: > * OOB > * Regular > * Internal > * Timer (used by TimeScheduler3) > The reason for this was mainly to prevent certain types of tasks from getting dropped due to a full pool. However, this can be changed by (1) making the pool have no queue and (2) handling the RejectedExecutionException (e.g. by spawning a new thread, or upping the max-threads value) for (e.g.) INTERNAL messages and timer tasks. > This not only simplify configuration (1 config section rather than 4), but also reduces the size of TP (removal of accessors, attributes). Things might also become a bit faster as a result. > The new common pool would have the following characteristics: > * Default rejection policy of "abort" (so we can handle pool exhaustion) > * No queue ({{SynchronousQueue}}), so new threads up to max-threads are created if none of the existing ones are available. The queue config attribute will be removed > * Catch RejectedExecutionException for INTERNAL messages and timer tasks. A new thread will be spawned on a RejectedExecutionException. This will be used mainly by INTERNAL messages and timer tasks > * Alternatively, we could increase max-threads (if {{ergonomics==true}}) if we get a constant rate of these exceptions -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6621) wildfly-spec-api:10.0.0.Final mismanages el-api, jsf-api

by kostd kostd (JIRA)

[ https://issues.jboss.org/browse/WFLY-6621?page=com.atlassian.jira.plugin.... ] kostd kostd commented on WFLY-6621: ----------------------------------- in new 10.1.0Final problem still exists (!) *Environment*: org.wildfly.bom:wildfly-javaee7-with-tools:10.1.0.Final; org.wildfly:wildfly-spec-api:10.1.0.Final {code:title=project dependencies} <dependencyManagement> <dependencies> <dependency> <groupId>org.wildfly.bom</groupId> <artifactId>wildfly-javaee7-with-tools</artifactId> <version>10.1.0.Final</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <dependencies> <dependency> <groupId>org.wildfly</groupId> <artifactId>wildfly-spec-api</artifactId> <version>10.1.0.Final</version> <type>pom</type> <scope>provided</scope> </dependency> </dependencies> {code} {code:title= mvn dependency:tree log} [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building *** 3.18.0 [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ volga-gate --- [INFO] ru.argustelecom.argus:***:ejb:3.18.0 [INFO] \- org.wildfly:wildfly-spec-api:pom:10.1.0.Final:provided [INFO] +- org.glassfish:javax.json:jar:1.0.3:provided [INFO] +- org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_2.0_spec:jar:1.0.0.Final:provided [INFO] +- org.jboss.spec.javax.batch:jboss-batch-api_1.0_spec:jar:1.0.0.Final:provided [INFO] | \- javax.inject:javax.inject:jar:1:provided [INFO] +- org.jboss.spec.javax.ejb:jboss-ejb-api_3.2_spec:jar:1.0.0.Final:provided [INFO] +- org.jboss.spec.javax.el:jboss-el-api_3.0_spec:jar:1.0.4.Final:provided [INFO] +- org.jboss.spec.javax.enterprise.concurrent:jboss-concurrency-api_1.0_spec:jar:1.0.0.Final:provided [INFO] +- org.jboss.spec.javax.faces:jboss-jsf-api_2.2_spec:jar:2.2.11:provided [INFO] +- org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.2_spec:jar:1.0.0.Final:provided [INFO] +- org.jboss.spec.javax.jms:jboss-jms-api_2.0_spec:jar:1.0.0.Final:provided [INFO] +- org.jboss.spec.javax.resource:jboss-connector-api_1.7_spec:jar:1.0.0.Final:provided [INFO] +- org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_spec:jar:1.0.0.Final:provided [INFO] +- org.jboss.spec.javax.security.jacc:jboss-jacc-api_1.5_spec:jar:1.0.0.Final:provided [INFO] +- org.jboss.spec.javax.servlet:jboss-servlet-api_3.1_spec:jar:1.0.0.Final:provided [INFO] +- org.jboss.spec.javax.servlet.jsp:jboss-jsp-api_2.3_spec:jar:1.0.1.Final:provided [INFO] +- org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar:1.1.2.Final:provided [INFO] +- org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec:jar:1.0.0.Final:provided [INFO] +- org.jboss.spec.javax.websocket:jboss-websocket-api_1.1_spec:jar:1.1.0.Final:provided [INFO] +- org.jboss.spec.javax.xml.bind:jboss-jaxb-api_2.2_spec:jar:1.0.4.Final:provided [INFO] +- org.jboss.spec.javax.xml.rpc:jboss-jaxrpc-api_1.1_spec:jar:1.0.1.Final:provided [INFO] +- org.jboss.spec.javax.xml.soap:jboss-saaj-api_1.3_spec:jar:1.0.3.Final:provided [INFO] +- org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final:provided [INFO] +- org.hibernate.javax.persistence:hibernate-jpa-2.1-api:jar:1.0.0.Final:provided [INFO] +- javax.enterprise:cdi-api:jar:1.2:provided [INFO] +- com.sun.mail:javax.mail:jar:1.5.3:provided [INFO] | \- javax.activation:activation:jar:1.1.1:provided [INFO] +- org.jboss.spec.javax.annotation:jboss-annotations-api_1.2_spec:jar:1.0.0.Final:provided [INFO] +- javax.validation:validation-api:jar:1.1.0.Final:provided [INFO] +- org.jboss.spec.javax.management.j2ee:jboss-j2eemgmt-api_1.1_spec:jar:1.0.1.Final:provided [INFO] \- org.wildfly.checkstyle:wildfly-checkstyle-config:jar:1.0.4.Final:provided [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 3.948 s [INFO] Finished at: 2016-09-07T12:22:19+03:00 [INFO] Final Memory: 17M/283M [INFO] ------------------------------------------------------------------------ {code} {code:title=jar versions in wildfly-10.1.0.Final dist} C:\Java\servers\wildfly-10.1.0.Final\modules\system\layers\base\javax\faces\api\main>ls -l total 712 -rwxr-xr-x+ 1 Администраторы mkpasswd 722960 Aug 18 18:12 jboss-jsf-api_2.2_spec-2.2.13.jar -rwxr-xr-x+ 1 Администраторы mkpasswd 1736 Aug 18 18:12 module.xml C:\Java\servers\wildfly-10.1.0.Final\modules\system\layers\base\javax\el\api\main>ls -l total 88 -rwxr-xr-x+ 1 Администраторы mkpasswd 85726 Aug 18 18:12 jboss-el-api_3.0_spec-1.0.7.Final.jar -rwxr-xr-x+ 1 Администраторы mkpasswd 1258 Aug 18 18:12 module.xml {code} [~ctomc], at this time no gui tools, only mvn dependency:tree. In fresh bom/spec-api problem still exists. Please reopen this issue. > wildfly-spec-api:10.0.0.Final mismanages el-api, jsf-api > -------------------------------------------------------- > > Key: WFLY-6621 > URL: https://issues.jboss.org/browse/WFLY-6621 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.0.0.Final > Reporter: Vsevolod Golovanov > Assignee: Tomaz Cerar > Attachments: pom_el.png, pom_jsf.png > > > Manages el-api to 1.0.4.Final, should be 1.0.5.Final: !pom_el.png|thumbnail! > Manages jsf-api to 2.2.11, should be 2.2.12: !pom_jsf.png|thumbnail! -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2099) TP: one single thread pool

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2099?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2099: --------------------------- Description: Currently, TP has 4 thread pools: * OOB * Regular * Internal * Timer (used by TimeScheduler3) The reason for this was mainly to prevent certain types of tasks from getting dropped due to a full pool. However, this can be changed by (1) making the pool have no queue and (2) handling the RejectedExecutionException (e.g. by spawning a new thread, or upping the max-threads value) for (e.g.) INTERNAL messages and timer tasks. This not only simplify configuration (1 config section rather than 4), but also reduces the size of TP (removal of accessors, attributes). Things might also become a bit faster as a result. The new common pool would have the following characteristics: * Default rejection policy of "abort" (so we can handle pool exhaustion) * No queue ({{SynchronousQueue}}), so new threads up to max-threads are created if none of the existing ones are available. The queue config attribute will be removed * Catch RejectedExecutionException for INTERNAL messages and timer tasks. A new thread will be spawned on a RejectedExecutionException. This will be used mainly by INTERNAL messages and timer tasks * Alternatively, we could increase max-threads (if {{ergonomics==true}}) if we get a constant rate of these exceptions was: Currently, TP has 4 thread pools: * OOB * Regular * Internal * Timer (used by TimeScheduler3) The reason for this was mainly to prevent certain types of tasks from getting dropped due to a full pool. However, this can be changed by (1) making the pool have no queue and (2) handling the RejectedExecutionException (e.g. by spawning a new thread, or upping the max-threads value) for (e.g.) INTERNAL messages and timer tasks. This not only simplify configuration (1 config section rather than 4), but also reduce the size of TP (removal of accessors, attributes). Things might also become a bit faster as a result. The new common pool would have the following characteristics: * Default rejection policy of "abort" (so we can handle pool exhaustion) * No queue ({{SynchronousQueue}}), so new threads up to max-threads are created if none of the existing ones are available. The queue config attribute will be removed * Catch RejectedExecutionException for INTERNAL messages and timer tasks. A new thread will be spawned on a RejectedExecutionException. This will be used mainly by INTERNAL messages and timer tasks * Alternatively, we could increase max-threads (if {{ergonomics==true}}) if we get a constant rate of these exceptions > TP: one single thread pool > -------------------------- > > Key: JGRP-2099 > URL: https://issues.jboss.org/browse/JGRP-2099 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently, TP has 4 thread pools: > * OOB > * Regular > * Internal > * Timer (used by TimeScheduler3) > The reason for this was mainly to prevent certain types of tasks from getting dropped due to a full pool. However, this can be changed by (1) making the pool have no queue and (2) handling the RejectedExecutionException (e.g. by spawning a new thread, or upping the max-threads value) for (e.g.) INTERNAL messages and timer tasks. > This not only simplify configuration (1 config section rather than 4), but also reduces the size of TP (removal of accessors, attributes). Things might also become a bit faster as a result. > The new common pool would have the following characteristics: > * Default rejection policy of "abort" (so we can handle pool exhaustion) > * No queue ({{SynchronousQueue}}), so new threads up to max-threads are created if none of the existing ones are available. The queue config attribute will be removed > * Catch RejectedExecutionException for INTERNAL messages and timer tasks. A new thread will be spawned on a RejectedExecutionException. This will be used mainly by INTERNAL messages and timer tasks > * Alternatively, we could increase max-threads (if {{ergonomics==true}}) if we get a constant rate of these exceptions -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6960) SFSB concurrent access timeout when the bean defines CDI producer for another SFSB

by Enrique González Martínez (JIRA)

[ https://issues.jboss.org/browse/WFLY-6960?page=com.atlassian.jira.plugin.... ] Enrique González Martínez commented on WFLY-6960: ------------------------------------------------- It ssems that the error only happens when @RequestScoped and @Statefull at class level is used in combination with @produces and those are injected in different stages. As Far as I can see the injection of the foo var fails in SFBean2 causing the creation exceptioin. https://github.com/tremes/core/blob/concurrentAcces/tests-arquillian/src/... > SFSB concurrent access timeout when the bean defines CDI producer for another SFSB > ---------------------------------------------------------------------------------- > > Key: WFLY-6960 > URL: https://issues.jboss.org/browse/WFLY-6960 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final, 10.1.0.CR1 > Reporter: Tomas Remes > Assignee: Enrique González Martínez > > In the given scenario there are two calls to {{org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor#processInvocation}} in the same thread. In the first call the {{OwnableReentrantLock}} is obtained but it couldn't be reentered in the second call. This results to: > {noformat} > 14:54:21,184 ERROR [org.jboss.as.ejb3.invocation] (pool-2-thread-2) WFLYEJB0034: EJB Invocation failed on component SFBean1 for method public org.jboss.weld.tests.ejb.stateful.producer.Foo org.jboss.weld.tests.ejb.stateful.producer.SFBean1.produceString(): javax.ejb.ConcurrentAccessTimeoutException: WFLYEJB0228: EJB 3.1 FR 4.3.14.1 concurrent access timeout on SFBean1 - could not obtain lock within 5000 MILLISECONDS > at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:86) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) > at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64) > at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195) > at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean1$$$view5.produceString(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:436) > at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127) > at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) > at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean1$Proxy$_$$_Weld$EnterpriseProxy$.produceString(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.producer.ProducerMethodProducer.produce(ProducerMethodProducer.java:99) > at org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:161) > at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:181) > at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:70) > at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) > at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) > at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742) > at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:842) > at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92) > at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:378) > at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:389) > at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:71) > at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) > at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:73) > at org.jboss.weld.injection.producer.ejb.SessionBeanInjectionTarget.inject(SessionBeanInjectionTarget.java:140) > at org.jboss.as.weld.injection.WeldInjectionContext.inject(WeldInjectionContext.java:39) > at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:51) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:263) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.notSupported(CMTTxInterceptor.java:308) > at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:62) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.jpa.interceptor.SFSBPreCreateInterceptor.processInvocation(SFSBPreCreateInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:150) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75) > at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:145) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75) > at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:135) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:75) > at org.jboss.as.ejb3.cache.simple.SimpleCache.create(SimpleCache.java:118) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238) > at org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.<init>(StatefulSessionObjectReferenceImpl.java:70) > at org.jboss.as.weld.services.bootstrap.WeldEjbServices.resolveEjb(WeldEjbServices.java:53) > at org.jboss.weld.bean.SessionBean.createReference(SessionBean.java:230) > at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:83) > at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:63) > at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.createEnterpriseTargetBeanInstance(SessionBeanProxyInstantiator.java:80) > at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.newInstance(SessionBeanProxyInstantiator.java:61) > at org.jboss.weld.bean.SessionBean.create(SessionBean.java:149) > at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96) > at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) > at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.get(ContextualInstanceStrategy.java:178) > at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) > at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99) > at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean2$Proxy$_$$_WeldClientProxy.foo(Unknown Source) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean3.ping(SFBean3.java:19) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) > at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) > at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) > at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:125) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) > at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64) > at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195) > at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$$$view6.ping(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:436) > at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127) > at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) > at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$Proxy$_$$_Weld$EnterpriseProxy$.ping(Unknown Source) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$Proxy$_$$_WeldClientProxy.ping(Unknown Source) > at org.jboss.weld.tests.ejb.stateful.producer.ConcurrentAccessTest.test(ConcurrentAccessTest.java:31) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7068) Typo in help for Infinispan subsystem

by Dmitrii Tikhomirov (JIRA)

Dmitrii Tikhomirov created WFLY-7068: ---------------------------------------- Summary: Typo in help for Infinispan subsystem Key: WFLY-7068 URL: https://issues.jboss.org/browse/WFLY-7068 Project: WildFly Issue Type: Bug Components: Web Console Affects Versions: 11.0.0.Alpha1 Reporter: Dmitrii Tikhomirov Assignee: Dmitrii Tikhomirov Priority: Trivial There is a typo in Passivation paragraph. "f false, the cache store contains a copy of the contents in memory, so writes to cache result in cache store writes." There should be "If" instead of "f" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7067) show-resources operation of jaxrs subsystem is unable to read jax-rs end-point from subresources

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-7067?page=com.atlassian.jira.plugin.... ] Lin Gao moved JBEAP-5910 to WFLY-7067: -------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7067 (was: JBEAP-5910) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: REST (was: REST) Affects Version/s: (was: 7.1.0.DR3) > show-resources operation of jaxrs subsystem is unable to read jax-rs end-point from subresources > ------------------------------------------------------------------------------------------------ > > Key: WFLY-7067 > URL: https://issues.jboss.org/browse/WFLY-7067 > Project: WildFly > Issue Type: Bug > Components: REST > Reporter: Lin Gao > Assignee: Lin Gao > > Show-resources operation of jaxrs subsystem is unable to read jax-rs end-point from subresources. > Example: > {code:java} > @Path("/root") > public class Root { > @Path("/method") > public Sub rootMethod() { > return new Sub(); > } > } > {code} > {code:java} > public class Sub { > @GET > @Path("submethod") > public String returnValue() { > return "555"; > } > } > {code} > {noformat} > [standalone@localhost:9990 /] /deployment=jaxrs-wf.war/subsystem=jaxrs:show-resources > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.ClassCastException: org.jboss.resteasy.core.ResourceLocatorInvoker cannot be cast to org.jboss.resteasy.core.ResourceMethodInvoker", > "rolled-back" => true > } > [standalone@localhost:9990 /] > {noformat} > {noformat} > 15:52:04,618 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 33) WFLYCTL0013: Operation ("show-resources") failed - address: ([ > ("deployment" => "jaxrs-wf.war"), > ("subsystem" => "jaxrs") > ]): java.lang.ClassCastException: org.jboss.resteasy.core.ResourceLocatorInvoker cannot be cast to org.jboss.resteasy.core.ResourceMethodInvoker > at org.jboss.as.jaxrs.JaxrsDeploymentDefinition$ShowJaxrsResourcesHandler.handle(JaxrsDeploymentDefinition.java:107) > at org.jboss.as.jaxrs.JaxrsDeploymentDefinition$ShowJaxrsResourcesHandler$1.execute(JaxrsDeploymentDefinition.java:163) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:951) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:694) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:389) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2016