[JBoss JIRA] (WFLY-7047) host-elytron.xml, different jvm settings, unnecesarry unsecure interface
by Martin Choma (JIRA)
Martin Choma created WFLY-7047:
----------------------------------
Summary: host-elytron.xml, different jvm settings, unnecesarry unsecure interface
Key: WFLY-7047
URL: https://issues.jboss.org/browse/WFLY-7047
Project: WildFly
Issue Type: Bug
Components: Security
Affects Versions: 11.0.0.Alpha1
Reporter: Martin Choma
Assignee: Darran Lofthouse
host-elytron.xml, different jvm settings, unnecesarry unsecure interface
When I compare host-elytron.xml to host.xml,
1) jvm settings use permgen element
2) probably unnecesarry configuration of unsecure profile stays there
Is it worth provide elytron-like host-master/host-slave configuration files for convenience?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-7046) domain-elytron.xml doesn't predefine ManagementDomain
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7046?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-7046:
----------------------------------------
This one does not sound like a bug, the ManagementDomain lives in the Elytron subsystem within the host.xml and not the domain.xml.
Having said that I probably should have removed all management realms and domains for now and add them back in for phase III so I think my fix for this will just be to remove them all until they are actually needed.
> domain-elytron.xml doesn't predefine ManagementDomain
> -----------------------------------------------------
>
> Key: WFLY-7046
> URL: https://issues.jboss.org/browse/WFLY-7046
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Fix For: 11.0.0.Alpha1
>
>
> When I compare domain-elytron.xml to standalone-elytron.xml there is missing ManagementDomain configured in all 4 profiles.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-7046) domain-elytron.xml doesn't predefine ManagementDomain
by Martin Choma (JIRA)
Martin Choma created WFLY-7046:
----------------------------------
Summary: domain-elytron.xml doesn't predefine ManagementDomain
Key: WFLY-7046
URL: https://issues.jboss.org/browse/WFLY-7046
Project: WildFly
Issue Type: Bug
Components: Security
Affects Versions: 11.0.0.Alpha1
Reporter: Martin Choma
Assignee: Darran Lofthouse
When I compare domain-elytron.xml to standalone-elytron.xml there is missing ManagementDomain configured in all 4 profiles.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-7045) domain-elytron.xml, missing singelton subsystem, different ejb cache type
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7045?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7045:
-----------------------------------
Fix Version/s: 11.0.0.Alpha1
> domain-elytron.xml, missing singelton subsystem, different ejb cache type
> -------------------------------------------------------------------------
>
> Key: WFLY-7045
> URL: https://issues.jboss.org/browse/WFLY-7045
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Fix For: 11.0.0.Alpha1
>
>
> When I compare domain-elytron.xml to domain.xml,
> 1) There is missing org.wildfly.extension.clustering.singleton extension installed.
> 2) There is changed ejb cache configuration
> 1254c1129
> < <stateful default-access-timeout="5000" cache-ref="simple" passivation-disabled-cache-ref="simple"/>
> ---
> > <stateful default-access-timeout="5000" cache-ref="distributable" passivation-disabled-cache-ref="simple"/>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-7045) domain-elytron.xml, missing singelton subsystem, different ejb cache type
by Martin Choma (JIRA)
Martin Choma created WFLY-7045:
----------------------------------
Summary: domain-elytron.xml, missing singelton subsystem, different ejb cache type
Key: WFLY-7045
URL: https://issues.jboss.org/browse/WFLY-7045
Project: WildFly
Issue Type: Bug
Components: Security
Affects Versions: 11.0.0.Alpha1
Reporter: Martin Choma
Assignee: Darran Lofthouse
When I compare domain-elytron.xml to domain.xml,
1) There is missing org.wildfly.extension.clustering.singleton extension installed.
2) There is changed ejb cache configuration
1254c1129
< <stateful default-access-timeout="5000" cache-ref="simple" passivation-disabled-cache-ref="simple"/>
---
> <stateful default-access-timeout="5000" cache-ref="distributable" passivation-disabled-cache-ref="simple"/>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-7044) standalone-elytron.xml , unnecessary unsecure interface
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7044?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7044:
-----------------------------------
Fix Version/s: 11.0.0.Alpha1
> standalone-elytron.xml , unnecessary unsecure interface
> -------------------------------------------------------
>
> Key: WFLY-7044
> URL: https://issues.jboss.org/browse/WFLY-7044
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Fix For: 11.0.0.Alpha1
>
>
> When I compare standalone-elytron.xml to standalone.xml, there is additional section
> {noformat}
> </interface>
> <!-- TODO - only show this if the jacorb subsystem is added -->
> <interface name="unsecure">
> <!--
> ~ Used for IIOP sockets in the standard configuration.
> ~ To secure IIOP connections you need to setup SSL
> -->
> <inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/>
> {noformat}
> Is it necessary?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-7044) standalone-elytron.xml , unnecessary unsecure interface
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7044?page=com.atlassian.jira.plugin.... ]
Martin Choma updated WFLY-7044:
-------------------------------
Summary: standalone-elytron.xml , unnecessary unsecure interface (was: standalone-elytron.xml , unnecesary unsecure interface)
> standalone-elytron.xml , unnecessary unsecure interface
> -------------------------------------------------------
>
> Key: WFLY-7044
> URL: https://issues.jboss.org/browse/WFLY-7044
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
>
> When I compare standalone-elytron.xml to standalone.xml, there is additional section
> {noformat}
> </interface>
> <!-- TODO - only show this if the jacorb subsystem is added -->
> <interface name="unsecure">
> <!--
> ~ Used for IIOP sockets in the standard configuration.
> ~ To secure IIOP connections you need to setup SSL
> -->
> <inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/>
> {noformat}
> Is it necessary?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-7044) standalone-elytron.xml , unnecesary unsecure interface
by Martin Choma (JIRA)
Martin Choma created WFLY-7044:
----------------------------------
Summary: standalone-elytron.xml , unnecesary unsecure interface
Key: WFLY-7044
URL: https://issues.jboss.org/browse/WFLY-7044
Project: WildFly
Issue Type: Bug
Components: Security
Affects Versions: 11.0.0.Alpha1
Reporter: Martin Choma
Assignee: Darran Lofthouse
When I compare standalone-elytron.xml to standalone.xml, there is additional section
{noformat}
</interface>
<!-- TODO - only show this if the jacorb subsystem is added -->
<interface name="unsecure">
<!--
~ Used for IIOP sockets in the standard configuration.
~ To secure IIOP connections you need to setup SSL
-->
<inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/>
{noformat}
Is it necessary?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-7042) Elytron Test Coverage
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFLY-7042:
--------------------------------------
Summary: Elytron Test Coverage
Key: WFLY-7042
URL: https://issues.jboss.org/browse/WFLY-7042
Project: WildFly
Issue Type: Task
Components: Test Suite
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Priority: Blocker
Fix For: 11.0.0.CR1
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1762) Missing dependency should be triggering rollback of the deployment operation
by Martin Stefanko (JIRA)
Martin Stefanko created WFCORE-1762:
---------------------------------------
Summary: Missing dependency should be triggering rollback of the deployment operation
Key: WFCORE-1762
URL: https://issues.jboss.org/browse/WFCORE-1762
Project: WildFly Core
Issue Type: Bug
Affects Versions: 3.0.0.Alpha7
Reporter: Martin Stefanko
When removing a deployment that other deployments or resources depend on, it should not be possible to remove such deployment or at least to present this information to the user prior to the removal.
For example:
{code}INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0028: Stopped deployment postgresql-9.4.1208.jar (runtime-name: postgresql-9.4.1208.jar) in 61ms
INFO [org.jboss.as.server] (ServerService Thread Pool -- 65) WFLYSRV0009: Undeployed "postgresql-9.4.1208.jar" (runtime-name: "postgresql-9.4.1208.jar")
INFO [org.jboss.as.repository] (ServerService Thread Pool -- 65) WFLYDR0002: Content removed from location /home/mjurc/testing/eap/7.0.0/jboss-eap-7.0/standalone/data/content/5c/7e80698b80a5045fe64daa67426051bbd16a56/content
INFO [org.jboss.as.controller] (ServerService Thread Pool -- 65) WFLYCTL0183: Service status report
WFLYCTL0184: New missing/unsatisfied dependencies:
service jboss.jdbc-driver.postgresql-9_4_1208_jar (missing) dependents: [service jboss.driver-demander.java:/PostgresDS, service org.wildfly.data-source.PostgresDS]
{code}
The monitoring is done by the ContainerStateMonitor class.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1742) Allow registering a custom handler for management interface
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1742?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-1742:
------------------------------------------
A couple of other related thoughts: -
- Currently Wise is being discussed on the dev list, ideally they would have also been exposed over the management interface.
- We have other projects such as KeyCloak that may also prefer to expose their management console over the management interface.
> Allow registering a custom handler for management interface
> -----------------------------------------------------------
>
> Key: WFCORE-1742
> URL: https://issues.jboss.org/browse/WFCORE-1742
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Sebastian Łaskawiec
>
> When building [HealthCheck API for Infisnispan|https://github.com/infinispan/infinispan/pull/4499] we noticed there is no way to register a custom endpoint on Management REST interface. Without it, calling the API requires using HTTP POST method (since it includes runtime parameters) and the URL is very long (and not intuitive for our users):
> {noformat}
> curl --digest -L -D - "http://localhost:9990/management/subsystem/datagrid-infinispan/cache-cont..." --header "Content-Type: application/json" -u ispnadmin:ispnadmin
> HTTP/1.1 401 Unauthorized
> Connection: keep-alive
> WWW-Authenticate: Digest realm="ManagementRealm",domain="/management",nonce="AuZzFxz7uC4NMTQ3MDgyNTU1NTQ3OCfIJBHXVpPHPBdzGUy7Qts=",opaque="00000000000000000000000000000000",algorithm=MD5,qop="auth"
> Content-Length: 77
> Content-Type: text/html
> Date: Wed, 10 Aug 2016 10:39:15 GMT
> HTTP/1.1 200 OK
> Connection: keep-alive
> Authentication-Info: nextnonce="AuZzFxz7uC4NMTQ3MDgyNTU1NTQ3OCfIJBHXVpPHPBdzGUy7Qts=",qop="auth",rspauth="b518c3170e627bd732055c382ce5d970",cnonce="NGViOWM0NDY5OGJmNjY0MjcyOWE4NDkyZDU3YzNhYjY=",nc=00000001
> Content-Type: application/json; charset=utf-8
> Content-Length: 1927
> Date: Wed, 10 Aug 2016 10:39:15 GMT
> {
> "cache-health" : "GREEN",
> "cluster-health" : ["test"],
> "cluster-name" : "clustered",
> "free-memory" : 96778,
> "log-tail" : [
> "2016-08-10 11:54:14,706 INFO [org.infinispan.server.endpoint] (MSC service thread 1-5) DGENDPT10001: HotRodServer listening on 127.0.0.1:11222",
> "2016-08-10 11:54:14,706 INFO [org.infinispan.server.endpoint] (MSC service thread 1-1) DGENDPT10001: MemcachedServer listening on 127.0.0.1:11211",
> "2016-08-10 11:54:14,785 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) DGISPN0001: Started ___protobuf_metadata cache from clustered container",
> "2016-08-10 11:54:14,800 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) DGISPN0001: Started ___script_cache cache from clustered container",
> "2016-08-10 11:54:15,159 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-5) DGISPN0001: Started ___hotRodTopologyCache cache from clustered container",
> "2016-08-10 11:54:15,210 INFO [org.infinispan.rest.NettyRestServer] (MSC service thread 1-6) ISPN012003: REST server starting, listening on 127.0.0.1:8080",
> "2016-08-10 11:54:15,210 INFO [org.infinispan.server.endpoint] (MSC service thread 1-6) DGENDPT10002: REST mapped to /rest",
> "2016-08-10 11:54:15,306 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management",
> "2016-08-10 11:54:15,307 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990",
> "2016-08-10 11:54:15,307 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: Infinispan Server 9.0.0-SNAPSHOT (WildFly Core 2.2.0.CR9) started in 8681ms - Started 196 of 237 services (121 services are lazy, passive or on-demand)"
> ],
> "number-of-cpus" : 8,
> "number-of-nodes" : 1,
> "total-memory" : 235520
> }%
> {noformat}
> It would be very convenient to allow exposing such endpoints with optional authorization and using custom URLs (e.g. something like http://localhost:9990/health).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1742) Allow registering a custom handler for management interface
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1742?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-1742:
------------------------------------------
Related to this did start some ideas about moving this into a subsystem: -
https://developer.jboss.org/wiki/ManagementSubsystemDesign-WFCORE-920
Also some older notes about possible restructuring of the interfaces: -
https://developer.jboss.org/wiki/WildFly11-HTTPManagementInterfaceConfigu...
These are all just random brain dumps for issues I was thinking about at the time but hopefully they do flag up some of the possible problems that may need to be solved around the management interfaces.
The management interfaces were originally designed to be very simple resources, as more and more requirements have been identified they have evolved to have more and more added to them. Personally I think it would be a good time for a redesign now to meet the needs going forward, a move to a subsystem could be a good way to support old and new as mutually exclusive options to allow a complete redesign with less worry about compatibility.
> Allow registering a custom handler for management interface
> -----------------------------------------------------------
>
> Key: WFCORE-1742
> URL: https://issues.jboss.org/browse/WFCORE-1742
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Sebastian Łaskawiec
>
> When building [HealthCheck API for Infisnispan|https://github.com/infinispan/infinispan/pull/4499] we noticed there is no way to register a custom endpoint on Management REST interface. Without it, calling the API requires using HTTP POST method (since it includes runtime parameters) and the URL is very long (and not intuitive for our users):
> {noformat}
> curl --digest -L -D - "http://localhost:9990/management/subsystem/datagrid-infinispan/cache-cont..." --header "Content-Type: application/json" -u ispnadmin:ispnadmin
> HTTP/1.1 401 Unauthorized
> Connection: keep-alive
> WWW-Authenticate: Digest realm="ManagementRealm",domain="/management",nonce="AuZzFxz7uC4NMTQ3MDgyNTU1NTQ3OCfIJBHXVpPHPBdzGUy7Qts=",opaque="00000000000000000000000000000000",algorithm=MD5,qop="auth"
> Content-Length: 77
> Content-Type: text/html
> Date: Wed, 10 Aug 2016 10:39:15 GMT
> HTTP/1.1 200 OK
> Connection: keep-alive
> Authentication-Info: nextnonce="AuZzFxz7uC4NMTQ3MDgyNTU1NTQ3OCfIJBHXVpPHPBdzGUy7Qts=",qop="auth",rspauth="b518c3170e627bd732055c382ce5d970",cnonce="NGViOWM0NDY5OGJmNjY0MjcyOWE4NDkyZDU3YzNhYjY=",nc=00000001
> Content-Type: application/json; charset=utf-8
> Content-Length: 1927
> Date: Wed, 10 Aug 2016 10:39:15 GMT
> {
> "cache-health" : "GREEN",
> "cluster-health" : ["test"],
> "cluster-name" : "clustered",
> "free-memory" : 96778,
> "log-tail" : [
> "2016-08-10 11:54:14,706 INFO [org.infinispan.server.endpoint] (MSC service thread 1-5) DGENDPT10001: HotRodServer listening on 127.0.0.1:11222",
> "2016-08-10 11:54:14,706 INFO [org.infinispan.server.endpoint] (MSC service thread 1-1) DGENDPT10001: MemcachedServer listening on 127.0.0.1:11211",
> "2016-08-10 11:54:14,785 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) DGISPN0001: Started ___protobuf_metadata cache from clustered container",
> "2016-08-10 11:54:14,800 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) DGISPN0001: Started ___script_cache cache from clustered container",
> "2016-08-10 11:54:15,159 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-5) DGISPN0001: Started ___hotRodTopologyCache cache from clustered container",
> "2016-08-10 11:54:15,210 INFO [org.infinispan.rest.NettyRestServer] (MSC service thread 1-6) ISPN012003: REST server starting, listening on 127.0.0.1:8080",
> "2016-08-10 11:54:15,210 INFO [org.infinispan.server.endpoint] (MSC service thread 1-6) DGENDPT10002: REST mapped to /rest",
> "2016-08-10 11:54:15,306 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management",
> "2016-08-10 11:54:15,307 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990",
> "2016-08-10 11:54:15,307 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: Infinispan Server 9.0.0-SNAPSHOT (WildFly Core 2.2.0.CR9) started in 8681ms - Started 196 of 237 services (121 services are lazy, passive or on-demand)"
> ],
> "number-of-cpus" : 8,
> "number-of-nodes" : 1,
> "total-memory" : 235520
> }%
> {noformat}
> It would be very convenient to allow exposing such endpoints with optional authorization and using custom URLs (e.g. something like http://localhost:9990/health).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6596) WrongClassException when using infinispan as remote-store for hibernate entity cache
by Gunther v. Wolffersdorff (JIRA)
[ https://issues.jboss.org/browse/WFLY-6596?page=com.atlassian.jira.plugin.... ]
Gunther v. Wolffersdorff edited comment on WFLY-6596 at 9/5/16 5:55 AM:
------------------------------------------------------------------------
@Steve:
_Are you doing that explicitly (in annotations or XML, etc)?_
No we don't.
Thank you for your advise concerning {{hibernate.cache.keys_factory}}. Unfortunately {{org.hibernate.cache.internal.DefaultCacheKeysFactory}} does not implement {{org.hibernate.cache.spi.CacheKeysFactory}}. So I implemented a cache key factory one based on {{org.hibernate.cache.internal.DefaultCacheKeysFactory}}. Using this the error is gone.
I will rebuild and upload the sample app for documentation uses.
was (Author: gvwolf3d):
@Steve:
_ Are you doing that explicitly (in annotations or XML, etc)?_
No we don't.
Thank you for your advise concerning {{hibernate.cache.keys_factory}}. Unfortunately {{org.hibernate.cache.internal.DefaultCacheKeysFactory}} does not implement {{org.hibernate.cache.spi.CacheKeysFactory}}. So I implemented a cache key factory one based on {{org.hibernate.cache.internal.DefaultCacheKeysFactory}}. Using this the error is gone.
I will rebuild and upload the sample app for documentation uses.
> WrongClassException when using infinispan as remote-store for hibernate entity cache
> ------------------------------------------------------------------------------------
>
> Key: WFLY-6596
> URL: https://issues.jboss.org/browse/WFLY-6596
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Java version: 1.8.0_45, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_45\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos"
> Infifnspan 8.1.2 or 8.2.0
> Reporter: Gunther v. Wolffersdorff
> Assignee: Scott Marlow
> Labels: inifinispan-commons, org.hibernate.WrongClassException, remote-store
> Attachments: clustered.sample.xml, infinispan.zip, sample-10.1.0.Final-2.zip, sample-10.1.0.Final.zip, sample.zip, standalone.sample.ha-10.1.0.Final.xml, standalone.sample.ha.xml
>
>
> Starting an application and then requesting a list of cachable JPA entitties ( configured cachable using a hibernate entity invalidation-cache with a remote-server as remote-store ) causes:
> {code}
> 13:00:52,541 MESZ ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /sample-web/rest/members/listAll: org.jboss.resteasy.spi.UnhandledException: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=100] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
> Caused by: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:492) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.criteria.compile.CriteriaQueryTypeQueryAdapter.getResultList(CriteriaQueryTypeQueryAdapter.java:50) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.jboss.as.jpa.container.TypedQueryNonTxInvocationDetacher.getResultList(TypedQueryNonTxInvocationDetacher.java:58) [wildfly-jpa-10.1.0.Final.jar:10.1.0.Final]
> at de.alvara.ticket.sample.data.MemberRepository.findAllOrderedByName(MemberRepository.java:58) [sample-ejb.jar:]
> at de.alvara.ticket.sample.data.MemberRepository$Proxy$_$$_WeldClientProxy.findAllOrderedByName(Unknown Source) [sample-ejb.jar:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService.listAllMembers(MemberResourceRESTService.java:75) [classes:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService$Proxy$_$$_WeldClientProxy.listAllMembers(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_66]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_66]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_66]
> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_66]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> ... 43 more
> Caused by: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.event.internal.DefaultLoadEventListener.processCachedEntry(DefaultLoadEventListener.java:631) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:602) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:462) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.internalLoad(SessionImpl.java:1022) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:632) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolve(EntityType.java:424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:154) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:128) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1133) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.processResultSet(Loader.java:992) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQuery(Loader.java:930) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:336) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2617) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2600) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2429) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.list(Loader.java:2424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:501) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:371) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1326) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> ... 58 more
> {code}
> Entity cache is configured like this:
> {code:xml}
> ...
> <invalidation-cache name="entity" mode="SYNC">
> <eviction strategy="LRU" max-entries="1000"/>
> <expiration lifespan="45000" max-idle="30000"/>
> <remote-store cache="hibernateDistributed" socket-timeout="60000" tcp-no-delay="true" remote-servers="local-cache-server" fetch-state="false" passivation="false" preload="false" purge="true" shared="true"/>
> </invalidation-cache>
> ...
> <outbound-socket-binding name="local-cache-server">
> <remote-destination host="${jboss.bind.address:127.0.0.1}" port="11322"/>
> </outbound-socket-binding>
> ...
> {code}
> see standalone.sample.ha-10.1.0.Final.xml .
> *This constellation works fine using Wildfly 8.2.0 and Infinispan 7.2.5 .*
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6596) WrongClassException when using infinispan as remote-store for hibernate entity cache
by Gunther v. Wolffersdorff (JIRA)
[ https://issues.jboss.org/browse/WFLY-6596?page=com.atlassian.jira.plugin.... ]
Gunther v. Wolffersdorff commented on WFLY-6596:
------------------------------------------------
@Steve:
_ Are you doing that explicitly (in annotations or XML, etc)?_
No we don't.
Thank you for your advise concerning {{hibernate.cache.keys_factory}}. Unfortunately {{org.hibernate.cache.internal.DefaultCacheKeysFactory}} does not implement {{org.hibernate.cache.spi.CacheKeysFactory}}. So I implemented a cache key factory one based on {{org.hibernate.cache.internal.DefaultCacheKeysFactory}}. Using this the error is gone.
I will rebuild and upload the sample app for documentation uses.
> WrongClassException when using infinispan as remote-store for hibernate entity cache
> ------------------------------------------------------------------------------------
>
> Key: WFLY-6596
> URL: https://issues.jboss.org/browse/WFLY-6596
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Java version: 1.8.0_45, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_45\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos"
> Infifnspan 8.1.2 or 8.2.0
> Reporter: Gunther v. Wolffersdorff
> Assignee: Scott Marlow
> Labels: inifinispan-commons, org.hibernate.WrongClassException, remote-store
> Attachments: clustered.sample.xml, infinispan.zip, sample-10.1.0.Final-2.zip, sample-10.1.0.Final.zip, sample.zip, standalone.sample.ha-10.1.0.Final.xml, standalone.sample.ha.xml
>
>
> Starting an application and then requesting a list of cachable JPA entitties ( configured cachable using a hibernate entity invalidation-cache with a remote-server as remote-store ) causes:
> {code}
> 13:00:52,541 MESZ ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /sample-web/rest/members/listAll: org.jboss.resteasy.spi.UnhandledException: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=100] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
> Caused by: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:492) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.criteria.compile.CriteriaQueryTypeQueryAdapter.getResultList(CriteriaQueryTypeQueryAdapter.java:50) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.jboss.as.jpa.container.TypedQueryNonTxInvocationDetacher.getResultList(TypedQueryNonTxInvocationDetacher.java:58) [wildfly-jpa-10.1.0.Final.jar:10.1.0.Final]
> at de.alvara.ticket.sample.data.MemberRepository.findAllOrderedByName(MemberRepository.java:58) [sample-ejb.jar:]
> at de.alvara.ticket.sample.data.MemberRepository$Proxy$_$$_WeldClientProxy.findAllOrderedByName(Unknown Source) [sample-ejb.jar:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService.listAllMembers(MemberResourceRESTService.java:75) [classes:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService$Proxy$_$$_WeldClientProxy.listAllMembers(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_66]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_66]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_66]
> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_66]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> ... 43 more
> Caused by: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.event.internal.DefaultLoadEventListener.processCachedEntry(DefaultLoadEventListener.java:631) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:602) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:462) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.internalLoad(SessionImpl.java:1022) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:632) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolve(EntityType.java:424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:154) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:128) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1133) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.processResultSet(Loader.java:992) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQuery(Loader.java:930) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:336) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2617) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2600) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2429) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.list(Loader.java:2424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:501) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:371) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1326) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> ... 58 more
> {code}
> Entity cache is configured like this:
> {code:xml}
> ...
> <invalidation-cache name="entity" mode="SYNC">
> <eviction strategy="LRU" max-entries="1000"/>
> <expiration lifespan="45000" max-idle="30000"/>
> <remote-store cache="hibernateDistributed" socket-timeout="60000" tcp-no-delay="true" remote-servers="local-cache-server" fetch-state="false" passivation="false" preload="false" purge="true" shared="true"/>
> </invalidation-cache>
> ...
> <outbound-socket-binding name="local-cache-server">
> <remote-destination host="${jboss.bind.address:127.0.0.1}" port="11322"/>
> </outbound-socket-binding>
> ...
> {code}
> see standalone.sample.ha-10.1.0.Final.xml .
> *This constellation works fine using Wildfly 8.2.0 and Infinispan 7.2.5 .*
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6596) WrongClassException when using infinispan as remote-store for hibernate entity cache
by Gunther v. Wolffersdorff (JIRA)
[ https://issues.jboss.org/browse/WFLY-6596?page=com.atlassian.jira.plugin.... ]
Gunther v. Wolffersdorff edited comment on WFLY-6596 at 9/5/16 5:53 AM:
------------------------------------------------------------------------
@Steve:
_ Are you doing that explicitly (in annotations or XML, etc)?_
No we don't.
Thank you for your advise concerning {{hibernate.cache.keys_factory}}. Unfortunately {{org.hibernate.cache.internal.DefaultCacheKeysFactory}} does not implement {{org.hibernate.cache.spi.CacheKeysFactory}}. So I implemented a cache key factory one based on {{org.hibernate.cache.internal.DefaultCacheKeysFactory}}. Using this the error is gone.
I will rebuild and upload the sample app for documentation uses.
was (Author: gvwolf3d):
@Steve:
_ Are you doing that explicitly (in annotations or XML, etc)?_
No we don't.
Thank you for your advise concerning {{hibernate.cache.keys_factory}}. Unfortunately {{org.hibernate.cache.internal.DefaultCacheKeysFactory}} does not implement {{org.hibernate.cache.spi.CacheKeysFactory}}. So I implemented a cache key factory one based on {{org.hibernate.cache.internal.DefaultCacheKeysFactory}}. Using this the error is gone.
I will rebuild and upload the sample app for documentation uses.
> WrongClassException when using infinispan as remote-store for hibernate entity cache
> ------------------------------------------------------------------------------------
>
> Key: WFLY-6596
> URL: https://issues.jboss.org/browse/WFLY-6596
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Java version: 1.8.0_45, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_45\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos"
> Infifnspan 8.1.2 or 8.2.0
> Reporter: Gunther v. Wolffersdorff
> Assignee: Scott Marlow
> Labels: inifinispan-commons, org.hibernate.WrongClassException, remote-store
> Attachments: clustered.sample.xml, infinispan.zip, sample-10.1.0.Final-2.zip, sample-10.1.0.Final.zip, sample.zip, standalone.sample.ha-10.1.0.Final.xml, standalone.sample.ha.xml
>
>
> Starting an application and then requesting a list of cachable JPA entitties ( configured cachable using a hibernate entity invalidation-cache with a remote-server as remote-store ) causes:
> {code}
> 13:00:52,541 MESZ ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /sample-web/rest/members/listAll: org.jboss.resteasy.spi.UnhandledException: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=100] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
> Caused by: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:492) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.criteria.compile.CriteriaQueryTypeQueryAdapter.getResultList(CriteriaQueryTypeQueryAdapter.java:50) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.jboss.as.jpa.container.TypedQueryNonTxInvocationDetacher.getResultList(TypedQueryNonTxInvocationDetacher.java:58) [wildfly-jpa-10.1.0.Final.jar:10.1.0.Final]
> at de.alvara.ticket.sample.data.MemberRepository.findAllOrderedByName(MemberRepository.java:58) [sample-ejb.jar:]
> at de.alvara.ticket.sample.data.MemberRepository$Proxy$_$$_WeldClientProxy.findAllOrderedByName(Unknown Source) [sample-ejb.jar:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService.listAllMembers(MemberResourceRESTService.java:75) [classes:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService$Proxy$_$$_WeldClientProxy.listAllMembers(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_66]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_66]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_66]
> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_66]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> ... 43 more
> Caused by: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.event.internal.DefaultLoadEventListener.processCachedEntry(DefaultLoadEventListener.java:631) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:602) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:462) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.internalLoad(SessionImpl.java:1022) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:632) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolve(EntityType.java:424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:154) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:128) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1133) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.processResultSet(Loader.java:992) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQuery(Loader.java:930) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:336) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2617) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2600) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2429) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.list(Loader.java:2424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:501) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:371) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1326) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> ... 58 more
> {code}
> Entity cache is configured like this:
> {code:xml}
> ...
> <invalidation-cache name="entity" mode="SYNC">
> <eviction strategy="LRU" max-entries="1000"/>
> <expiration lifespan="45000" max-idle="30000"/>
> <remote-store cache="hibernateDistributed" socket-timeout="60000" tcp-no-delay="true" remote-servers="local-cache-server" fetch-state="false" passivation="false" preload="false" purge="true" shared="true"/>
> </invalidation-cache>
> ...
> <outbound-socket-binding name="local-cache-server">
> <remote-destination host="${jboss.bind.address:127.0.0.1}" port="11322"/>
> </outbound-socket-binding>
> ...
> {code}
> see standalone.sample.ha-10.1.0.Final.xml .
> *This constellation works fine using Wildfly 8.2.0 and Infinispan 7.2.5 .*
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6596) WrongClassException when using infinispan as remote-store for hibernate entity cache
by Gunther v. Wolffersdorff (JIRA)
[ https://issues.jboss.org/browse/WFLY-6596?page=com.atlassian.jira.plugin.... ]
Gunther v. Wolffersdorff commented on WFLY-6596:
------------------------------------------------
@Radim:
_Your Question: I wonder what is your use case ..._
Ok, we are running a Wildfly Cluster with a buisness critical application. For better control and monitor we would like to separate the application server functionality from cache functionality. Therefore we are running an Infinispan Server at each host (building itself an Infinispan cluster). The hibernate cache gets this cache server as remote store to hold the JPA entities in memory (no persistence here). Unfortunately we cannot configure the hibernate cache in the application server in a way to hold no entities (local-cache with eviction max-entries="0" does not work). So we configured a minimal invalidation-cache in the application server and an huge cache in the infinispan cache server (also just in memory).
Do you know a better way to separate application server and cache server JVM?
> WrongClassException when using infinispan as remote-store for hibernate entity cache
> ------------------------------------------------------------------------------------
>
> Key: WFLY-6596
> URL: https://issues.jboss.org/browse/WFLY-6596
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Java version: 1.8.0_45, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_45\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos"
> Infifnspan 8.1.2 or 8.2.0
> Reporter: Gunther v. Wolffersdorff
> Assignee: Scott Marlow
> Labels: inifinispan-commons, org.hibernate.WrongClassException, remote-store
> Attachments: clustered.sample.xml, infinispan.zip, sample-10.1.0.Final-2.zip, sample-10.1.0.Final.zip, sample.zip, standalone.sample.ha-10.1.0.Final.xml, standalone.sample.ha.xml
>
>
> Starting an application and then requesting a list of cachable JPA entitties ( configured cachable using a hibernate entity invalidation-cache with a remote-server as remote-store ) causes:
> {code}
> 13:00:52,541 MESZ ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /sample-web/rest/members/listAll: org.jboss.resteasy.spi.UnhandledException: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=100] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
> Caused by: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:492) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.criteria.compile.CriteriaQueryTypeQueryAdapter.getResultList(CriteriaQueryTypeQueryAdapter.java:50) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.jboss.as.jpa.container.TypedQueryNonTxInvocationDetacher.getResultList(TypedQueryNonTxInvocationDetacher.java:58) [wildfly-jpa-10.1.0.Final.jar:10.1.0.Final]
> at de.alvara.ticket.sample.data.MemberRepository.findAllOrderedByName(MemberRepository.java:58) [sample-ejb.jar:]
> at de.alvara.ticket.sample.data.MemberRepository$Proxy$_$$_WeldClientProxy.findAllOrderedByName(Unknown Source) [sample-ejb.jar:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService.listAllMembers(MemberResourceRESTService.java:75) [classes:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService$Proxy$_$$_WeldClientProxy.listAllMembers(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_66]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_66]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_66]
> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_66]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> ... 43 more
> Caused by: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.event.internal.DefaultLoadEventListener.processCachedEntry(DefaultLoadEventListener.java:631) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:602) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:462) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.internalLoad(SessionImpl.java:1022) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:632) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolve(EntityType.java:424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:154) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:128) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1133) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.processResultSet(Loader.java:992) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQuery(Loader.java:930) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:336) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2617) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2600) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2429) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.list(Loader.java:2424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:501) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:371) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1326) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> ... 58 more
> {code}
> Entity cache is configured like this:
> {code:xml}
> ...
> <invalidation-cache name="entity" mode="SYNC">
> <eviction strategy="LRU" max-entries="1000"/>
> <expiration lifespan="45000" max-idle="30000"/>
> <remote-store cache="hibernateDistributed" socket-timeout="60000" tcp-no-delay="true" remote-servers="local-cache-server" fetch-state="false" passivation="false" preload="false" purge="true" shared="true"/>
> </invalidation-cache>
> ...
> <outbound-socket-binding name="local-cache-server">
> <remote-destination host="${jboss.bind.address:127.0.0.1}" port="11322"/>
> </outbound-socket-binding>
> ...
> {code}
> see standalone.sample.ha-10.1.0.Final.xml .
> *This constellation works fine using Wildfly 8.2.0 and Infinispan 7.2.5 .*
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1274) Deleting of drools project cause error on Windows 10
by Lukáš Petrovický (JIRA)
Lukáš Petrovický created DROOLS-1274:
----------------------------------------
Summary: Deleting of drools project cause error on Windows 10
Key: DROOLS-1274
URL: https://issues.jboss.org/browse/DROOLS-1274
Project: Drools
Issue Type: Bug
Components: eclipse plugin
Affects Versions: 6.4.0.Final
Environment: Windows 10
jdk 1.8.0
Reporter: Lukáš Petrovický
Assignee: Robert (Bob) Brodt
If you create a new drools project with all samples and delete it, an error appears. This happens only sometimes on windows 10 machines. See the screenshot and log file.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-7038) License files issues
by Petr Sakař (JIRA)
Petr Sakař created WFLY-7038:
--------------------------------
Summary: License files issues
Key: WFLY-7038
URL: https://issues.jboss.org/browse/WFLY-7038
Project: WildFly
Issue Type: Bug
Components: Build System
Affects Versions: 10.1.0.Final
Reporter: Petr Sakař
Assignee: Paul Gier
Various problems with licenses were found.
- bsd.txt file contains BSD license template
- some licenses are incorrect
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-7037) Memory leak when doing deploy/undeploy app using REST and JPA
by Tomas Remes (JIRA)
Tomas Remes created WFLY-7037:
---------------------------------
Summary: Memory leak when doing deploy/undeploy app using REST and JPA
Key: WFLY-7037
URL: https://issues.jboss.org/browse/WFLY-7037
Project: WildFly
Issue Type: Bug
Components: REST, XML Frameworks
Affects Versions: 10.1.0.Final
Reporter: Tomas Remes
Assignee: Stuart Douglas
Priority: Critical
Attachments: gc_path.png, mem-leak.zip
It seems that exposing some type (ApplicationUser in attached app) which has enum type as attribute via REST api could cause memory leak (See steps to reproduce). You can observe that person.joey.test.UserType instances are kept in memory when GC happens (metaspace exceeds) and the path to GC root looks:
!gc_path.png|thumbnail!
Note that this map https://github.com/FasterXML/jackson-databind/blob/jackson-databind-2.7.4... was not available in 2.5.4 version used in WF 10.0.0.Final
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1270) support fact handle operations for REST APIs on kie server
by Dan Cimpoesu (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1270?page=com.atlassian.jira.plugi... ]
Dan Cimpoesu updated DROOLS-1270:
---------------------------------
Description:
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
was:
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.
> 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: kie server
> Affects Versions: 6.5.0.CR1
> Environment: kie server
> Reporter: Dan Cimpoesu
> Assignee: Edson Tirelli
> 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
[JBoss JIRA] (WFLY-6663) NPE o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-6663?page=com.atlassian.jira.plugin.... ]
jaikiran pai commented on WFLY-6663:
------------------------------------
Any chance you can attach an application which reproduces this?
> NPE o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6663
> URL: https://issues.jboss.org/browse/WFLY-6663
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Win7 64bit + JDK8 64bit
> Reporter: Darryl Miles
>
> 1 in 8 deployments fail to deploy, usually a redeploy fixes it.
> If there is anyway to get a module state logging out of it, I can send over two logs to compare, one that deploy ok and one that fails. I guess there is a race bug there somewhere.
> 09:42:01,687 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 529) MSC000001: Failed to start service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163)
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:138)
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> ... 6 more
> Caused by: javax.ejb.EJBException: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:83)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:91)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:106)
> at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> 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)
> ... 11 more
> Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:319)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:97)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 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.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> ... 26 more
> Caused by: javax.naming.NamingException: WFLYNAM0062: Failed to lookup env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb [Root exception is java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl]
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:157)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
> ... 43 more
> Caused by: java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl
> at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:99)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143)
> ... 48 more
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.openSession(LocalEjbReceiver.java:296)
> at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:225)
> at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:202)
> at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:176)
> at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:97)
> ... 49 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6663) NPE o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/WFLY-6663?page=com.atlassian.jira.plugin.... ]
Darryl Miles updated WFLY-6663:
-------------------------------
Affects Version/s: 10.1.0.Final
> NPE o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6663
> URL: https://issues.jboss.org/browse/WFLY-6663
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Win7 64bit + JDK8 64bit
> Reporter: Darryl Miles
>
> 1 in 8 deployments fail to deploy, usually a redeploy fixes it.
> If there is anyway to get a module state logging out of it, I can send over two logs to compare, one that deploy ok and one that fails. I guess there is a race bug there somewhere.
> 09:42:01,687 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 529) MSC000001: Failed to start service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163)
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:138)
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> ... 6 more
> Caused by: javax.ejb.EJBException: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:83)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:91)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:106)
> at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> 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)
> ... 11 more
> Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:319)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:97)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 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.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> ... 26 more
> Caused by: javax.naming.NamingException: WFLYNAM0062: Failed to lookup env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb [Root exception is java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl]
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:157)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
> ... 43 more
> Caused by: java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl
> at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:99)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143)
> ... 48 more
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.openSession(LocalEjbReceiver.java:296)
> at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:225)
> at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:202)
> at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:176)
> at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:97)
> ... 49 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6663) NPE o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/WFLY-6663?page=com.atlassian.jira.plugin.... ]
Darryl Miles commented on WFLY-6663:
------------------------------------
Ok quite quickly after removing the @EJB (and disabling method use) the problem moved to another @Startup @Singleton @TransactionManagement(TransactionManagementType.BEAN) EJB trying to inject @EJB MainEjb.
> NPE o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6663
> URL: https://issues.jboss.org/browse/WFLY-6663
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final
> Environment: Win7 64bit + JDK8 64bit
> Reporter: Darryl Miles
>
> 1 in 8 deployments fail to deploy, usually a redeploy fixes it.
> If there is anyway to get a module state logging out of it, I can send over two logs to compare, one that deploy ok and one that fails. I guess there is a race bug there somewhere.
> 09:42:01,687 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 529) MSC000001: Failed to start service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163)
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:138)
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> ... 6 more
> Caused by: javax.ejb.EJBException: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:83)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:91)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:106)
> at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> 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)
> ... 11 more
> Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:319)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:97)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 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.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> ... 26 more
> Caused by: javax.naming.NamingException: WFLYNAM0062: Failed to lookup env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb [Root exception is java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl]
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:157)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
> ... 43 more
> Caused by: java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl
> at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:99)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143)
> ... 48 more
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.openSession(LocalEjbReceiver.java:296)
> at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:225)
> at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:202)
> at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:176)
> at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:97)
> ... 49 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6663) NPE o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/WFLY-6663?page=com.atlassian.jira.plugin.... ]
Darryl Miles edited comment on WFLY-6663 at 9/3/16 9:48 PM:
------------------------------------------------------------
https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...
The line I presume with the NPE.
Was method StatefulSessionComponent#start() called, is the NPE from this.cache==null ?
It is the @EJB injection of the @Stateful MainEjb that is causing the error. The MainEjb EJB implementation is really simple and has no injections of its own. Just simple private fields holding only primitive types (it is a statistics collector).
was (Author: dlmiles):
https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...
The line I presume with the NPE. Was #start() called, is the NPE from this.cache==null ?
> NPE o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6663
> URL: https://issues.jboss.org/browse/WFLY-6663
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final
> Environment: Win7 64bit + JDK8 64bit
> Reporter: Darryl Miles
>
> 1 in 8 deployments fail to deploy, usually a redeploy fixes it.
> If there is anyway to get a module state logging out of it, I can send over two logs to compare, one that deploy ok and one that fails. I guess there is a race bug there somewhere.
> 09:42:01,687 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 529) MSC000001: Failed to start service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163)
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:138)
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> ... 6 more
> Caused by: javax.ejb.EJBException: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:83)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:91)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:106)
> at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> 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)
> ... 11 more
> Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:319)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:97)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 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.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> ... 26 more
> Caused by: javax.naming.NamingException: WFLYNAM0062: Failed to lookup env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb [Root exception is java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl]
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:157)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
> ... 43 more
> Caused by: java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl
> at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:99)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143)
> ... 48 more
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.openSession(LocalEjbReceiver.java:296)
> at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:225)
> at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:202)
> at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:176)
> at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:97)
> ... 49 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6663) NPE o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/WFLY-6663?page=com.atlassian.jira.plugin.... ]
Darryl Miles edited comment on WFLY-6663 at 9/3/16 9:48 PM:
------------------------------------------------------------
Just to report back Wildfly 10.1.0.Final has the same issue.
So to add to the information here (and since it only seems to be this specific EJB with the problem I guess it is the specific situation it creates):
{code:title=MainStartupEjbImpl.java|borderStyle=solid}
// Typed in so excuse typos
@Singleton
@Startup
@TransactionManagement(TransactionManagementType.BEAN)
public class MainStartupEjbImpl {
@EJB
private MainEjb mainEjb;
@Resource
private TimerService timerService;
@Resource
private EJBContext context;
@Resource
private UserTransaction ut;
@PostContruct
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void postConstruct() {
// code removed
}
@PreDestroy
public void preDestory() {
// code removed
}
@Timeout
public void timeout() {
// code removed
}
}
{code}
was (Author: dlmiles):
Just to report back Wildfly 10.1.0.Final has the same issue.
So to add to the information here (and since it only seems to be this specific EJB with the problem I guess it is the specific situation it creates):
{code:title=MainEjbImpl.java|borderStyle=solid}
// Typed in so excuse typos
@Singleton
@Startup
@TransactionManagement(TransactionManagementType.BEAN)
public class MainStartupEjbImpl {
@EJB
private MainEjb mainEjb;
@Resource
private TimerService timerService;
@Resource
private EJBContext context;
@Resource
private UserTransaction ut;
@PostContruct
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void postConstruct() {
// code removed
}
@PreDestroy
public void preDestory() {
// code removed
}
@Timeout
public void timeout() {
// code removed
}
}
{code}
> NPE o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6663
> URL: https://issues.jboss.org/browse/WFLY-6663
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final
> Environment: Win7 64bit + JDK8 64bit
> Reporter: Darryl Miles
>
> 1 in 8 deployments fail to deploy, usually a redeploy fixes it.
> If there is anyway to get a module state logging out of it, I can send over two logs to compare, one that deploy ok and one that fails. I guess there is a race bug there somewhere.
> 09:42:01,687 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 529) MSC000001: Failed to start service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163)
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:138)
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> ... 6 more
> Caused by: javax.ejb.EJBException: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:83)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:91)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:106)
> at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> 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)
> ... 11 more
> Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:319)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:97)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 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.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> ... 26 more
> Caused by: javax.naming.NamingException: WFLYNAM0062: Failed to lookup env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb [Root exception is java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl]
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:157)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
> ... 43 more
> Caused by: java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl
> at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:99)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143)
> ... 48 more
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.openSession(LocalEjbReceiver.java:296)
> at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:225)
> at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:202)
> at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:176)
> at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:97)
> ... 49 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6663) NPE o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/WFLY-6663?page=com.atlassian.jira.plugin.... ]
Darryl Miles commented on WFLY-6663:
------------------------------------
https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...
The line I presume with the NPE. Was #start() called, is the NPE from this.cache==null ?
> NPE o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6663
> URL: https://issues.jboss.org/browse/WFLY-6663
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final
> Environment: Win7 64bit + JDK8 64bit
> Reporter: Darryl Miles
>
> 1 in 8 deployments fail to deploy, usually a redeploy fixes it.
> If there is anyway to get a module state logging out of it, I can send over two logs to compare, one that deploy ok and one that fails. I guess there is a race bug there somewhere.
> 09:42:01,687 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 529) MSC000001: Failed to start service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163)
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:138)
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> ... 6 more
> Caused by: javax.ejb.EJBException: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:83)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:91)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:106)
> at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> 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)
> ... 11 more
> Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:319)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:97)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 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.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> ... 26 more
> Caused by: javax.naming.NamingException: WFLYNAM0062: Failed to lookup env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb [Root exception is java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl]
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:157)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
> ... 43 more
> Caused by: java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl
> at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:99)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143)
> ... 48 more
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.openSession(LocalEjbReceiver.java:296)
> at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:225)
> at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:202)
> at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:176)
> at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:97)
> ... 49 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6663) NPE o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/WFLY-6663?page=com.atlassian.jira.plugin.... ]
Darryl Miles commented on WFLY-6663:
------------------------------------
Just to report back Wildfly 10.1.0.Final has the same issue.
So to add to the information here (and since it only seems to be this specific EJB with the problem I guess it is the specific situation it creates):
{code:title=MainEjbImpl.java|borderStyle=solid}
// Typed in so excuse typos
@Singleton
@Startup
@TransactionManagement(TransactionManagementType.BEAN)
public class MainStartupEjbImpl {
@EJB
private MainEjb mainEjb;
@Resource
private TimerService timerService;
@Resource
private EJBContext context;
@Resource
private UserTransaction ut;
@PostContruct
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void postConstruct() {
// code removed
}
@PreDestroy
public void preDestory() {
// code removed
}
@Timeout
public void timeout() {
// code removed
}
}
{code}
> NPE o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6663
> URL: https://issues.jboss.org/browse/WFLY-6663
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final
> Environment: Win7 64bit + JDK8 64bit
> Reporter: Darryl Miles
>
> 1 in 8 deployments fail to deploy, usually a redeploy fixes it.
> If there is anyway to get a module state logging out of it, I can send over two logs to compare, one that deploy ok and one that fails. I guess there is a race bug there somewhere.
> 09:42:01,687 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 529) MSC000001: Failed to start service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163)
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:138)
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> ... 6 more
> Caused by: javax.ejb.EJBException: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:83)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:91)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:106)
> at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> 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)
> ... 11 more
> Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:319)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:97)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 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.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> ... 26 more
> Caused by: javax.naming.NamingException: WFLYNAM0062: Failed to lookup env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb [Root exception is java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl]
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:157)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
> ... 43 more
> Caused by: java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl
> at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:99)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143)
> ... 48 more
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.openSession(LocalEjbReceiver.java:296)
> at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:225)
> at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:202)
> at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:176)
> at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:97)
> ... 49 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-7036) Add MQTT protocol support for JMS
by Juraj Veverka (JIRA)
[ https://issues.jboss.org/browse/WFLY-7036?page=com.atlassian.jira.plugin.... ]
Juraj Veverka updated WFLY-7036:
--------------------------------
Fix Version/s: 10.2.0.Final
> Add MQTT protocol support for JMS
> ---------------------------------
>
> Key: WFLY-7036
> URL: https://issues.jboss.org/browse/WFLY-7036
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS
> Affects Versions: 10.1.0.Final
> Reporter: Juraj Veverka
> Assignee: Jeff Mesnil
> Fix For: 10.2.0.Final
>
>
> It would be great if MQTT protocol is supported by JMS subsystem in WildFly AS. As of WildFly 10, ActiveMQ is used as JMS implementation in WildFly AS. ActiveMQ supports MQTT protocol, but if I try to add remote-acceptor in <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
> <remote-acceptor name="netty-acceptor-mqtt" socket-binding="messaging-mqtt">
> <param name="protocols" value="MQTT,CORE"/>
> </remote-acceptor>
> When WildFly is started, I can see following log statement:
> 22:55:48,487 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 64) AMQ221020: Started Acceptor at 127.0.0.1:7998 for protocols [CORE,AMQP,HORNETQ,STOMP]
> which means that MQTT protocol is not supportred, instead CORE,AMQP,HORNETQ,STOMP are activated.
> MQTT is used by IoT devices, it would be nice if WildFly 10.2.0 AS has out-of-the-box support.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-7036) Add MQTT protocol support for JMS
by Juraj Veverka (JIRA)
Juraj Veverka created WFLY-7036:
-----------------------------------
Summary: Add MQTT protocol support for JMS
Key: WFLY-7036
URL: https://issues.jboss.org/browse/WFLY-7036
Project: WildFly
Issue Type: Feature Request
Components: JMS
Affects Versions: 10.1.0.Final
Reporter: Juraj Veverka
Assignee: Jeff Mesnil
It would be great if MQTT protocol is supported by JMS subsystem in WildFly AS. As of WildFly 10, ActiveMQ is used as JMS implementation in WildFly AS. ActiveMQ supports MQTT protocol, but if I try to add remote-acceptor in <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
<remote-acceptor name="netty-acceptor-mqtt" socket-binding="messaging-mqtt">
<param name="protocols" value="MQTT,CORE"/>
</remote-acceptor>
When WildFly is started, I can see following log statement:
22:55:48,487 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 64) AMQ221020: Started Acceptor at 127.0.0.1:7998 for protocols [CORE,AMQP,HORNETQ,STOMP]
which means that MQTT protocol is not supportred, instead CORE,AMQP,HORNETQ,STOMP are activated.
MQTT is used by IoT devices, it would be nice if WildFly 10.2.0 AS has out-of-the-box support.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6944) Encode session affinity using multiple routes, if supported by the load balancer
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6944?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-6944:
-------------------------------
Description:
Currently, session affinity is specified as a single route, usually the primary owner of a session. However, if this node is not active (from the load balancer's perspective), then the load balancer will select another node of its choosing. This is less than ideal, since some nodes are more optimal than others. Better is to expression session affinity as an ordered list of nodes. The load balancer can then choose the 1st node in the list that is active, and cascade on failures accordingly. From the server's perspective, the affinity list should have the following order:
1. The primary owner
2. Any backup owners
3. The local node (if the local node is not an owner)
There are a couple of ways a load balancer can indicate that it supports multiple routes.
1. Static configuration, e.g. routing="OWNER|LOCAL|RANKED"
2. Adding an HTTP header to a proxied request, which can be detected by the server handling the request
#1 has the advantage of simplicity - but requires that users manually apply this configuration to gain optimal performance. This would also let us allow users (for even the single node affinity case) to toggle between local affinity or primary owner affinity, or even no routing.
#2 has the advantage of applying this optimization automatically, but incurs the cost of an additional header to every request
was:
Currently, session affinity is specified as a single route, usually the primary owner of a session. However, if this node is not active (from the load balancer's perspective), then the load balancer will select another node of its choosing. This is less than ideal, since some nodes are more optimal than others. Better is to expression session affinity as an ordered list of nodes. The load balancer can then choose the 1st node in the list that is active, and cascade on failures accordingly. From the server's perspective, the affinity list should have the following order:
1. The primary owner
2. Any backup owners
3. The local node (if the local node is not an owner)
There are a couple of ways a load balancer can indicate that it supports multiple routes.
1. Static configuration
2. Adding an HTTP header to a proxied request, which can be detected by the server handling the request
#1 has the advantage of simplicity - but requires that users manually apply this configuration to gain optimal performance. This would also let us allow users (for even the single node affinity case) to toggle between local affinity or primary owner affinity, or even no routing.
#2 has the advantage of applying this optimization automatically, but incurs the cost of an additional header to every request
> Encode session affinity using multiple routes, if supported by the load balancer
> --------------------------------------------------------------------------------
>
> Key: WFLY-6944
> URL: https://issues.jboss.org/browse/WFLY-6944
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> Currently, session affinity is specified as a single route, usually the primary owner of a session. However, if this node is not active (from the load balancer's perspective), then the load balancer will select another node of its choosing. This is less than ideal, since some nodes are more optimal than others. Better is to expression session affinity as an ordered list of nodes. The load balancer can then choose the 1st node in the list that is active, and cascade on failures accordingly. From the server's perspective, the affinity list should have the following order:
> 1. The primary owner
> 2. Any backup owners
> 3. The local node (if the local node is not an owner)
> There are a couple of ways a load balancer can indicate that it supports multiple routes.
> 1. Static configuration, e.g. routing="OWNER|LOCAL|RANKED"
> 2. Adding an HTTP header to a proxied request, which can be detected by the server handling the request
> #1 has the advantage of simplicity - but requires that users manually apply this configuration to gain optimal performance. This would also let us allow users (for even the single node affinity case) to toggle between local affinity or primary owner affinity, or even no routing.
> #2 has the advantage of applying this optimization automatically, but incurs the cost of an additional header to every request
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6596) WrongClassException when using infinispan as remote-store for hibernate entity cache
by Gunther v. Wolffersdorff (JIRA)
[ https://issues.jboss.org/browse/WFLY-6596?page=com.atlassian.jira.plugin.... ]
Gunther v. Wolffersdorff updated WFLY-6596:
-------------------------------------------
Steps to Reproduce:
* Application
> unzip sample-10.1.0.Final-2.zip
> cd sample
> mvn clean install
> ls -la sample-ear/target/sample-ear.ear
* Infinispan
- Version 8.2.4.Final
- start:
> infinispan-server-8.2.4.Final/bin/standalone.sh --server-config=clustered.sample.xml -Djboss.socket.binding.port-offset=100
* Wildfly
- Version 10.1.0.Final
- start:
> wildfly-10.1.0.Final/bin/standalone.sh --server-config=standalone.sample.ha.xml
deploy: sample-ear.ear
Call in web browser: http://localhost:2680/sample-web/rest/members/listAll throws:
{code}
13:00:52,541 MESZ ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /sample-web/rest/members/listAll: org.jboss.resteasy.spi.UnhandledException: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=100] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
...
{code}
was:
* Application
> unzip sample-10.1.0.Final.zip
> cd sample
> mvn clean install
> ls -la sample-ear/target/sample-ear.ear
* Infinispan
- Version 8.2.4.Final
- start:
> infinispan-server-8.2.4.Final/bin/standalone.sh --server-config=clustered.sample.xml -Djboss.socket.binding.port-offset=100
* Wildfly
- Version 10.1.0.Final
- start:
> wildfly-10.1.0.Final/bin/standalone.sh --server-config=standalone.sample.ha.xml
deploy: sample-ear.ear
Call in web browser: http://localhost:2680/sample-web/rest/members/listAll throws:
{code}
13:00:52,541 MESZ ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /sample-web/rest/members/listAll: org.jboss.resteasy.spi.UnhandledException: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
...
{code}
> WrongClassException when using infinispan as remote-store for hibernate entity cache
> ------------------------------------------------------------------------------------
>
> Key: WFLY-6596
> URL: https://issues.jboss.org/browse/WFLY-6596
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Java version: 1.8.0_45, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_45\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos"
> Infifnspan 8.1.2 or 8.2.0
> Reporter: Gunther v. Wolffersdorff
> Assignee: Scott Marlow
> Labels: inifinispan-commons, org.hibernate.WrongClassException, remote-store
> Attachments: clustered.sample.xml, infinispan.zip, sample-10.1.0.Final-2.zip, sample-10.1.0.Final.zip, sample.zip, standalone.sample.ha-10.1.0.Final.xml, standalone.sample.ha.xml
>
>
> Starting an application and then requesting a list of cachable JPA entitties ( configured cachable using a hibernate entity invalidation-cache with a remote-server as remote-store ) causes:
> {code}
> 13:00:52,541 MESZ ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /sample-web/rest/members/listAll: org.jboss.resteasy.spi.UnhandledException: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
> Caused by: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:492) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.criteria.compile.CriteriaQueryTypeQueryAdapter.getResultList(CriteriaQueryTypeQueryAdapter.java:50) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.jboss.as.jpa.container.TypedQueryNonTxInvocationDetacher.getResultList(TypedQueryNonTxInvocationDetacher.java:58) [wildfly-jpa-10.1.0.Final.jar:10.1.0.Final]
> at de.alvara.ticket.sample.data.MemberRepository.findAllOrderedByName(MemberRepository.java:58) [sample-ejb.jar:]
> at de.alvara.ticket.sample.data.MemberRepository$Proxy$_$$_WeldClientProxy.findAllOrderedByName(Unknown Source) [sample-ejb.jar:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService.listAllMembers(MemberResourceRESTService.java:75) [classes:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService$Proxy$_$$_WeldClientProxy.listAllMembers(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_66]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_66]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_66]
> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_66]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> ... 43 more
> Caused by: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.event.internal.DefaultLoadEventListener.processCachedEntry(DefaultLoadEventListener.java:631) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:602) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:462) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.internalLoad(SessionImpl.java:1022) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:632) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolve(EntityType.java:424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:154) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:128) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1133) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.processResultSet(Loader.java:992) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQuery(Loader.java:930) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:336) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2617) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2600) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2429) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.list(Loader.java:2424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:501) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:371) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1326) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> ... 58 more
> {code}
> Entity cache is configured like this:
> {code:xml}
> ...
> <invalidation-cache name="entity" mode="SYNC">
> <eviction strategy="LRU" max-entries="1000"/>
> <expiration lifespan="45000" max-idle="30000"/>
> <remote-store cache="hibernateDistributed" socket-timeout="60000" tcp-no-delay="true" remote-servers="local-cache-server" fetch-state="false" passivation="false" preload="false" purge="true" shared="true"/>
> </invalidation-cache>
> ...
> <outbound-socket-binding name="local-cache-server">
> <remote-destination host="${jboss.bind.address:127.0.0.1}" port="11322"/>
> </outbound-socket-binding>
> ...
> {code}
> see standalone.sample.ha-10.1.0.Final.xml .
> *This constellation works fine using Wildfly 8.2.0 and Infinispan 7.2.5 .*
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6596) WrongClassException when using infinispan as remote-store for hibernate entity cache
by Gunther v. Wolffersdorff (JIRA)
[ https://issues.jboss.org/browse/WFLY-6596?page=com.atlassian.jira.plugin.... ]
Gunther v. Wolffersdorff updated WFLY-6596:
-------------------------------------------
Description:
Starting an application and then requesting a list of cachable JPA entitties ( configured cachable using a hibernate entity invalidation-cache with a remote-server as remote-store ) causes:
{code}
13:00:52,541 MESZ ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /sample-web/rest/members/listAll: org.jboss.resteasy.spi.UnhandledException: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=100] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
Caused by: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:492) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.jpa.criteria.compile.CriteriaQueryTypeQueryAdapter.getResultList(CriteriaQueryTypeQueryAdapter.java:50) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
at org.jboss.as.jpa.container.TypedQueryNonTxInvocationDetacher.getResultList(TypedQueryNonTxInvocationDetacher.java:58) [wildfly-jpa-10.1.0.Final.jar:10.1.0.Final]
at de.alvara.ticket.sample.data.MemberRepository.findAllOrderedByName(MemberRepository.java:58) [sample-ejb.jar:]
at de.alvara.ticket.sample.data.MemberRepository$Proxy$_$$_WeldClientProxy.findAllOrderedByName(Unknown Source) [sample-ejb.jar:]
at de.alvara.ticket.sample.rest.MemberResourceRESTService.listAllMembers(MemberResourceRESTService.java:75) [classes:]
at de.alvara.ticket.sample.rest.MemberResourceRESTService$Proxy$_$$_WeldClientProxy.listAllMembers(Unknown Source) [classes:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_66]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_66]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_66]
at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_66]
at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
... 43 more
Caused by: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
at org.hibernate.event.internal.DefaultLoadEventListener.processCachedEntry(DefaultLoadEventListener.java:631) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.event.internal.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:602) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:462) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.internal.SessionImpl.internalLoad(SessionImpl.java:1022) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:632) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.type.EntityType.resolve(EntityType.java:424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:154) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:128) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1133) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.loader.Loader.processResultSet(Loader.java:992) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.loader.Loader.doQuery(Loader.java:930) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:336) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.loader.Loader.doList(Loader.java:2617) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.loader.Loader.doList(Loader.java:2600) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2429) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.loader.Loader.list(Loader.java:2424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:501) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:371) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1326) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
... 58 more
{code}
Entity cache is configured like this:
{code:xml}
...
<invalidation-cache name="entity" mode="SYNC">
<eviction strategy="LRU" max-entries="1000"/>
<expiration lifespan="45000" max-idle="30000"/>
<remote-store cache="hibernateDistributed" socket-timeout="60000" tcp-no-delay="true" remote-servers="local-cache-server" fetch-state="false" passivation="false" preload="false" purge="true" shared="true"/>
</invalidation-cache>
...
<outbound-socket-binding name="local-cache-server">
<remote-destination host="${jboss.bind.address:127.0.0.1}" port="11322"/>
</outbound-socket-binding>
...
{code}
see standalone.sample.ha-10.1.0.Final.xml .
*This constellation works fine using Wildfly 8.2.0 and Infinispan 7.2.5 .*
was:
Starting an application and then requesting a list of cachable JPA entitties ( configured cachable using a hibernate entity invalidation-cache with a remote-server as remote-store ) causes:
{code}
13:00:52,541 MESZ ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /sample-web/rest/members/listAll: org.jboss.resteasy.spi.UnhandledException: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
Caused by: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:492) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.jpa.criteria.compile.CriteriaQueryTypeQueryAdapter.getResultList(CriteriaQueryTypeQueryAdapter.java:50) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
at org.jboss.as.jpa.container.TypedQueryNonTxInvocationDetacher.getResultList(TypedQueryNonTxInvocationDetacher.java:58) [wildfly-jpa-10.1.0.Final.jar:10.1.0.Final]
at de.alvara.ticket.sample.data.MemberRepository.findAllOrderedByName(MemberRepository.java:58) [sample-ejb.jar:]
at de.alvara.ticket.sample.data.MemberRepository$Proxy$_$$_WeldClientProxy.findAllOrderedByName(Unknown Source) [sample-ejb.jar:]
at de.alvara.ticket.sample.rest.MemberResourceRESTService.listAllMembers(MemberResourceRESTService.java:75) [classes:]
at de.alvara.ticket.sample.rest.MemberResourceRESTService$Proxy$_$$_WeldClientProxy.listAllMembers(Unknown Source) [classes:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_66]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_66]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_66]
at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_66]
at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
... 43 more
Caused by: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
at org.hibernate.event.internal.DefaultLoadEventListener.processCachedEntry(DefaultLoadEventListener.java:631) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.event.internal.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:602) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:462) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.internal.SessionImpl.internalLoad(SessionImpl.java:1022) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:632) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.type.EntityType.resolve(EntityType.java:424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:154) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:128) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1133) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.loader.Loader.processResultSet(Loader.java:992) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.loader.Loader.doQuery(Loader.java:930) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:336) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.loader.Loader.doList(Loader.java:2617) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.loader.Loader.doList(Loader.java:2600) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2429) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.loader.Loader.list(Loader.java:2424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:501) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:371) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1326) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
... 58 more
{code}
Entity cache is configured like this:
{code:xml}
...
<invalidation-cache name="entity" mode="SYNC">
<eviction strategy="LRU" max-entries="1000"/>
<expiration lifespan="45000" max-idle="30000"/>
<remote-store cache="hibernateDistributed" socket-timeout="60000" tcp-no-delay="true" remote-servers="local-cache-server" fetch-state="false" passivation="false" preload="false" purge="true" shared="true"/>
</invalidation-cache>
...
<outbound-socket-binding name="local-cache-server">
<remote-destination host="${jboss.bind.address:127.0.0.1}" port="11322"/>
</outbound-socket-binding>
...
{code}
see standalone.sample.ha-10.1.0.Final.xml .
*This constellation works fine using Wildfly 8.2.0 and Infinispan 7.2.5 .*
> WrongClassException when using infinispan as remote-store for hibernate entity cache
> ------------------------------------------------------------------------------------
>
> Key: WFLY-6596
> URL: https://issues.jboss.org/browse/WFLY-6596
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Java version: 1.8.0_45, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_45\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos"
> Infifnspan 8.1.2 or 8.2.0
> Reporter: Gunther v. Wolffersdorff
> Assignee: Scott Marlow
> Labels: inifinispan-commons, org.hibernate.WrongClassException, remote-store
> Attachments: clustered.sample.xml, infinispan.zip, sample-10.1.0.Final-2.zip, sample-10.1.0.Final.zip, sample.zip, standalone.sample.ha-10.1.0.Final.xml, standalone.sample.ha.xml
>
>
> Starting an application and then requesting a list of cachable JPA entitties ( configured cachable using a hibernate entity invalidation-cache with a remote-server as remote-store ) causes:
> {code}
> 13:00:52,541 MESZ ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /sample-web/rest/members/listAll: org.jboss.resteasy.spi.UnhandledException: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=100] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
> Caused by: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:492) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.criteria.compile.CriteriaQueryTypeQueryAdapter.getResultList(CriteriaQueryTypeQueryAdapter.java:50) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.jboss.as.jpa.container.TypedQueryNonTxInvocationDetacher.getResultList(TypedQueryNonTxInvocationDetacher.java:58) [wildfly-jpa-10.1.0.Final.jar:10.1.0.Final]
> at de.alvara.ticket.sample.data.MemberRepository.findAllOrderedByName(MemberRepository.java:58) [sample-ejb.jar:]
> at de.alvara.ticket.sample.data.MemberRepository$Proxy$_$$_WeldClientProxy.findAllOrderedByName(Unknown Source) [sample-ejb.jar:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService.listAllMembers(MemberResourceRESTService.java:75) [classes:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService$Proxy$_$$_WeldClientProxy.listAllMembers(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_66]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_66]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_66]
> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_66]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> ... 43 more
> Caused by: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.event.internal.DefaultLoadEventListener.processCachedEntry(DefaultLoadEventListener.java:631) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:602) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:462) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.internalLoad(SessionImpl.java:1022) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:632) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolve(EntityType.java:424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:154) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:128) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1133) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.processResultSet(Loader.java:992) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQuery(Loader.java:930) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:336) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2617) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2600) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2429) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.list(Loader.java:2424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:501) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:371) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1326) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> ... 58 more
> {code}
> Entity cache is configured like this:
> {code:xml}
> ...
> <invalidation-cache name="entity" mode="SYNC">
> <eviction strategy="LRU" max-entries="1000"/>
> <expiration lifespan="45000" max-idle="30000"/>
> <remote-store cache="hibernateDistributed" socket-timeout="60000" tcp-no-delay="true" remote-servers="local-cache-server" fetch-state="false" passivation="false" preload="false" purge="true" shared="true"/>
> </invalidation-cache>
> ...
> <outbound-socket-binding name="local-cache-server">
> <remote-destination host="${jboss.bind.address:127.0.0.1}" port="11322"/>
> </outbound-socket-binding>
> ...
> {code}
> see standalone.sample.ha-10.1.0.Final.xml .
> *This constellation works fine using Wildfly 8.2.0 and Infinispan 7.2.5 .*
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1305) LoggingSubsystemRollbackTestCase fails intermittently
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1305?page=com.atlassian.jira.plugi... ]
James Perkins closed WFCORE-1305.
---------------------------------
Resolution: Out of Date
> LoggingSubsystemRollbackTestCase fails intermittently
> -----------------------------------------------------
>
> Key: WFCORE-1305
> URL: https://issues.jboss.org/browse/WFCORE-1305
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 2.0.6.Final
> Reporter: Marek Kopecký
> Assignee: James Perkins
>
> *Description of problem:*
> LoggingSubsystemRollbackTestCase from wildfly-core fails intermittently.
> *How reproducible:*
> 40% with IBM JDK
> *Steps to Reproduce:*
> # mvn install -Dmaven.repo.local=$MAVEN_REPO_LOCAL -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dmcast=$MCAST_ADDR -DfailIfNoTests=false -Dts.domain -Dtest=LoggingSubsystemRollbackTestCase
> *Stacktrace:*
> {noformat}
> com.sun.tools.attach.AttachNotSupportedException: target not found
> at ibm.tools.attach.J9AttachProvider.attachVirtualMachine(J9AttachProvider.java:60)
> at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:231)
> at org.jboss.byteman.agent.install.Install.attach(Install.java:390)
> at org.jboss.byteman.agent.install.Install.install(Install.java:129)
> at org.jboss.byteman.contrib.bmunit.BMUnitConfigState.loadAgent(BMUnitConfigState.java:516)
> at org.jboss.byteman.contrib.bmunit.BMUnitConfigState.pushConfigurationState(BMUnitConfigState.java:669)
> at org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:73)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:113)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:85)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:134)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {noformat}
> *Standard Output:*
> {noformat}
> byteman jar is /mnt/hudson_workspace/eap-7x-as-testsuite-test-core-rhel/19de6045/eap-local-maven-repository/org/jboss/byteman/byteman/2.2.1/byteman-2.2.1.jar
> {noformat}
> *Expected results:*
> No errors
> *Additional info:*
> Jenkins reproducer job: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-AS-T...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[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 commented on WFCORE-1556:
------------------------------------------
WFCORE-1761 is for the org.jboss.as.server.mgmt.NativeManagementResourceDefinition SOCKET_BINDING thing I noted in my first comment.
It occurred to me that this work might break our JMX integration but it looks like the OpenMBeanAttributeInfo we generate from our descriptions does not deal with required/alternatives/nillable in any way so we are free to do what we want there.
> 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/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".
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1270) support fact handle operations for REST APIs on kie server
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1270?page=com.atlassian.jira.plugi... ]
Edson Tirelli commented on DROOLS-1270:
---------------------------------------
Can you please clarify your request and provide an example?
> 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: kie server
> Affects Versions: 6.5.0.CR1
> Environment: kie server
> Reporter: Dan Cimpoesu
> Assignee: Edson Tirelli
> 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.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-7035) [GSS](7.1.0) JDR is not collecting the file .overlays, layer.conf, version.txt config files
by Brad Maxwell (JIRA)
Brad Maxwell created WFLY-7035:
----------------------------------
Summary: [GSS](7.1.0) JDR is not collecting the file .overlays, layer.conf, version.txt config files
Key: WFLY-7035
URL: https://issues.jboss.org/browse/WFLY-7035
Project: WildFly
Issue Type: Bug
Components: JDR
Affects Versions: 10.1.0.Final
Reporter: Brad Maxwell
Assignee: Brad Maxwell
Priority: Minor
The JDR report when collecting files should be collecting
$JBOSS_HOME/modules/system/layers/base/.overlays/.overlays
$JBOSS_HOME/.installation/identity.conf
$JBOSS_HOME/.installation/layers/base/layer.conf
$JBOSS_HOME/.installation/patches/*/misc/version.txt
This file is needed to confirm overlay priority and other layer configurations to make sure the installation is not corrupted.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-7034) JDR is not collecting the file .overlays, layer.conf, version.txt config files
by Brad Maxwell (JIRA)
Brad Maxwell created WFLY-7034:
----------------------------------
Summary: JDR is not collecting the file .overlays, layer.conf, version.txt config files
Key: WFLY-7034
URL: https://issues.jboss.org/browse/WFLY-7034
Project: WildFly
Issue Type: Bug
Components: JDR
Affects Versions: 10.1.0.Final
Reporter: Brad Maxwell
Assignee: Brad Maxwell
Priority: Minor
The JDR report when collecting files should be collecting
$JBOSS_HOME/modules/system/layers/base/.overlays/.overlays
$JBOSS_HOME/.installation/identity.conf
$JBOSS_HOME/.installation/layers/base/layer.conf
$JBOSS_HOME/.installation/patches/*/misc/version.txt
This file is needed to confirm overlay priority and other layer configurations to make sure the installation is not corrupted.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[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 edited comment on WFLY-7029 at 9/2/16 3:31 PM:
--------------------------------------------------------------
Possible cause might be fix for ISPN-5918 with commit: https://github.com/infinispan/infinispan/pull/3805/commits/f8039053d6d76e...
was (Author: rhusar):
Possible cause https://github.com/infinispan/infinispan/pull/3805/commits/f8039053d6d76e...
> 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
> &#27;[0m04:31:43,338 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0211: Suspending server with 15000 ms timeout.
> &#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)
> &#27;[0m04:31:43,345 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown'
> &#27;[0m&#27;[0m04:31:43,430 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping
> &#27;[0m&#27;[0m04:31:43,436 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 29) MODCLUSTER000002: Initiating mod_cluster shutdown
> &#27;[0m&#27;[0m04:31:43,445 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 74) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:/ConnectionFactory
> &#27;[0m&#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000080: Disconnecting JGroups channel hibernate
> &#27;[0m&#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher for channel hibernate
> &#27;[0m&#27;[0m04:31:43,463 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000080: Disconnecting JGroups channel server
> &#27;[0m&#27;[0m04:31:43,464 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000082: Stopping the RpcDispatcher for channel server
> &#27;[0m&#27;[0m04:31:43,471 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000029: Passivating all entries to disk
> &#27;[0m&#27;[0m04:31:43,472 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000030: Passivated 2 entries in 0 milliseconds
> &#27;[0m&#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel web
> &#27;[0m&#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel web
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel testDbPersistence
> &#27;[0m&#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel testDbPersistence
> &#27;[0m&#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)
> &#27;[0m&#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
> &#27;[0m&#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]
> &#27;[0m&#27;[0m04:31:43,518 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA]
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,547 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 2) WFLYCLINF0003: Stopped client-mappings cache from ejb container
> &#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
> &#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000080: Disconnecting JGroups channel ejb
> &#27;[0m&#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000082: Stopping the RpcDispatcher for channel ejb
> &#27;[0m&#27;[0m04:31:43,575 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 35) AMQ151003: resource adaptor stopped
> &#27;[0m&#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow AJP listener ajp suspending
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTPS listener https suspending
> &#27;[0m&#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
> &#27;[0m&#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
> &#27;[0m&#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
[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 edited comment on WFLY-7029 at 9/2/16 3:31 PM:
--------------------------------------------------------------
Possible cause might be fix for ISPN-5918 by commit: https://github.com/infinispan/infinispan/pull/3805/commits/f8039053d6d76e...
was (Author: rhusar):
Possible cause might be fix for ISPN-5918 with commit: https://github.com/infinispan/infinispan/pull/3805/commits/f8039053d6d76e...
> 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
> &#27;[0m04:31:43,338 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0211: Suspending server with 15000 ms timeout.
> &#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)
> &#27;[0m04:31:43,345 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown'
> &#27;[0m&#27;[0m04:31:43,430 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping
> &#27;[0m&#27;[0m04:31:43,436 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 29) MODCLUSTER000002: Initiating mod_cluster shutdown
> &#27;[0m&#27;[0m04:31:43,445 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 74) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:/ConnectionFactory
> &#27;[0m&#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000080: Disconnecting JGroups channel hibernate
> &#27;[0m&#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher for channel hibernate
> &#27;[0m&#27;[0m04:31:43,463 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000080: Disconnecting JGroups channel server
> &#27;[0m&#27;[0m04:31:43,464 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000082: Stopping the RpcDispatcher for channel server
> &#27;[0m&#27;[0m04:31:43,471 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000029: Passivating all entries to disk
> &#27;[0m&#27;[0m04:31:43,472 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000030: Passivated 2 entries in 0 milliseconds
> &#27;[0m&#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel web
> &#27;[0m&#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel web
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel testDbPersistence
> &#27;[0m&#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel testDbPersistence
> &#27;[0m&#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)
> &#27;[0m&#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
> &#27;[0m&#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]
> &#27;[0m&#27;[0m04:31:43,518 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA]
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,547 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 2) WFLYCLINF0003: Stopped client-mappings cache from ejb container
> &#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
> &#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000080: Disconnecting JGroups channel ejb
> &#27;[0m&#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000082: Stopping the RpcDispatcher for channel ejb
> &#27;[0m&#27;[0m04:31:43,575 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 35) AMQ151003: resource adaptor stopped
> &#27;[0m&#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow AJP listener ajp suspending
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTPS listener https suspending
> &#27;[0m&#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
> &#27;[0m&#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
> &#27;[0m&#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
[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/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".
was:
The handling of the notions of 'require'd 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 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/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".
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1273) Rule Evaluation Modes
by Matteo Mortari (JIRA)
Matteo Mortari created DROOLS-1273:
--------------------------------------
Summary: Rule Evaluation Modes
Key: DROOLS-1273
URL: https://issues.jboss.org/browse/DROOLS-1273
Project: Drools
Issue Type: Enhancement
Components: docs
Reporter: Matteo Mortari
Assignee: Matteo Mortari
Priority: Minor
documents Immediate, Eager and Lazy annotations. As well as the ForceImmedateFilter api.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6596) WrongClassException when using infinispan as remote-store for hibernate entity cache
by Steve Ebersole (JIRA)
[ https://issues.jboss.org/browse/WFLY-6596?page=com.atlassian.jira.plugin.... ]
Steve Ebersole commented on WFLY-6596:
--------------------------------------
[~rvansa] Ah good... I had forgotten about {{hibernate.cache.keys_factory}}. Yes definitely use that as a work-around [~gvwolf3d]
> WrongClassException when using infinispan as remote-store for hibernate entity cache
> ------------------------------------------------------------------------------------
>
> Key: WFLY-6596
> URL: https://issues.jboss.org/browse/WFLY-6596
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Java version: 1.8.0_45, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_45\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos"
> Infifnspan 8.1.2 or 8.2.0
> Reporter: Gunther v. Wolffersdorff
> Assignee: Scott Marlow
> Labels: inifinispan-commons, org.hibernate.WrongClassException, remote-store
> Attachments: clustered.sample.xml, infinispan.zip, sample-10.1.0.Final-2.zip, sample-10.1.0.Final.zip, sample.zip, standalone.sample.ha-10.1.0.Final.xml, standalone.sample.ha.xml
>
>
> Starting an application and then requesting a list of cachable JPA entitties ( configured cachable using a hibernate entity invalidation-cache with a remote-server as remote-store ) causes:
> {code}
> 13:00:52,541 MESZ ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /sample-web/rest/members/listAll: org.jboss.resteasy.spi.UnhandledException: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
> Caused by: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:492) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.criteria.compile.CriteriaQueryTypeQueryAdapter.getResultList(CriteriaQueryTypeQueryAdapter.java:50) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.jboss.as.jpa.container.TypedQueryNonTxInvocationDetacher.getResultList(TypedQueryNonTxInvocationDetacher.java:58) [wildfly-jpa-10.1.0.Final.jar:10.1.0.Final]
> at de.alvara.ticket.sample.data.MemberRepository.findAllOrderedByName(MemberRepository.java:58) [sample-ejb.jar:]
> at de.alvara.ticket.sample.data.MemberRepository$Proxy$_$$_WeldClientProxy.findAllOrderedByName(Unknown Source) [sample-ejb.jar:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService.listAllMembers(MemberResourceRESTService.java:75) [classes:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService$Proxy$_$$_WeldClientProxy.listAllMembers(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_66]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_66]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_66]
> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_66]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> ... 43 more
> Caused by: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.event.internal.DefaultLoadEventListener.processCachedEntry(DefaultLoadEventListener.java:631) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:602) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:462) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.internalLoad(SessionImpl.java:1022) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:632) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolve(EntityType.java:424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:154) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:128) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1133) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.processResultSet(Loader.java:992) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQuery(Loader.java:930) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:336) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2617) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2600) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2429) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.list(Loader.java:2424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:501) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:371) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1326) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> ... 58 more
> {code}
> Entity cache is configured like this:
> {code:xml}
> ...
> <invalidation-cache name="entity" mode="SYNC">
> <eviction strategy="LRU" max-entries="1000"/>
> <expiration lifespan="45000" max-idle="30000"/>
> <remote-store cache="hibernateDistributed" socket-timeout="60000" tcp-no-delay="true" remote-servers="local-cache-server" fetch-state="false" passivation="false" preload="false" purge="true" shared="true"/>
> </invalidation-cache>
> ...
> <outbound-socket-binding name="local-cache-server">
> <remote-destination host="${jboss.bind.address:127.0.0.1}" port="11322"/>
> </outbound-socket-binding>
> ...
> {code}
> see standalone.sample.ha-10.1.0.Final.xml .
> *This constellation works fine using Wildfly 8.2.0 and Infinispan 7.2.5 .*
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6596) WrongClassException when using infinispan as remote-store for hibernate entity cache
by Steve Ebersole (JIRA)
[ https://issues.jboss.org/browse/WFLY-6596?page=com.atlassian.jira.plugin.... ]
Steve Ebersole commented on WFLY-6596:
--------------------------------------
That would indicate to me that you are using the same "cache region" for storing both Country and Member data. Are you doing that explicitly (in annotations or XML, etc)?
For illustration, when you have a {{Country#9}} and a {{Member#9}} both of those get stored into their respective cache region using a "cache key". What I think is happening is that in your case both {{Country#9}} and a {{Member#9}} get stored into the same "Map" using the key 9... they collide. So if you put {{Country#9}} into the cache and then try to find {{Member#9}} you'd get back the {{Country#9}} entry.
That would jive with a recent performance enhancement that changed the structure of this "cache key". We used to essentially use a tuple of {{rootEntityName,id}}. The recent change was performance related, and changed that to instead use just the {{id}}. But obviously we need to be correct, then performant.
If my hunch is correct you could work around this by using distinct regions for your entities.
You could also work around it by controlling the factory responsible for creating those "cache keys". Unfortunately that is a l lot of work (too much) atm.
I created [HHH-11083|https://hibernate.atlassian.net/browse/HHH-11083] to fix the bug in Hibernate.
> WrongClassException when using infinispan as remote-store for hibernate entity cache
> ------------------------------------------------------------------------------------
>
> Key: WFLY-6596
> URL: https://issues.jboss.org/browse/WFLY-6596
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Java version: 1.8.0_45, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_45\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos"
> Infifnspan 8.1.2 or 8.2.0
> Reporter: Gunther v. Wolffersdorff
> Assignee: Scott Marlow
> Labels: inifinispan-commons, org.hibernate.WrongClassException, remote-store
> Attachments: clustered.sample.xml, infinispan.zip, sample-10.1.0.Final-2.zip, sample-10.1.0.Final.zip, sample.zip, standalone.sample.ha-10.1.0.Final.xml, standalone.sample.ha.xml
>
>
> Starting an application and then requesting a list of cachable JPA entitties ( configured cachable using a hibernate entity invalidation-cache with a remote-server as remote-store ) causes:
> {code}
> 13:00:52,541 MESZ ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /sample-web/rest/members/listAll: org.jboss.resteasy.spi.UnhandledException: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
> Caused by: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:492) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.criteria.compile.CriteriaQueryTypeQueryAdapter.getResultList(CriteriaQueryTypeQueryAdapter.java:50) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.jboss.as.jpa.container.TypedQueryNonTxInvocationDetacher.getResultList(TypedQueryNonTxInvocationDetacher.java:58) [wildfly-jpa-10.1.0.Final.jar:10.1.0.Final]
> at de.alvara.ticket.sample.data.MemberRepository.findAllOrderedByName(MemberRepository.java:58) [sample-ejb.jar:]
> at de.alvara.ticket.sample.data.MemberRepository$Proxy$_$$_WeldClientProxy.findAllOrderedByName(Unknown Source) [sample-ejb.jar:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService.listAllMembers(MemberResourceRESTService.java:75) [classes:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService$Proxy$_$$_WeldClientProxy.listAllMembers(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_66]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_66]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_66]
> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_66]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> ... 43 more
> Caused by: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.event.internal.DefaultLoadEventListener.processCachedEntry(DefaultLoadEventListener.java:631) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:602) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:462) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.internalLoad(SessionImpl.java:1022) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:632) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolve(EntityType.java:424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:154) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:128) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1133) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.processResultSet(Loader.java:992) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQuery(Loader.java:930) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:336) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2617) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2600) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2429) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.list(Loader.java:2424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:501) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:371) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1326) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> ... 58 more
> {code}
> Entity cache is configured like this:
> {code:xml}
> ...
> <invalidation-cache name="entity" mode="SYNC">
> <eviction strategy="LRU" max-entries="1000"/>
> <expiration lifespan="45000" max-idle="30000"/>
> <remote-store cache="hibernateDistributed" socket-timeout="60000" tcp-no-delay="true" remote-servers="local-cache-server" fetch-state="false" passivation="false" preload="false" purge="true" shared="true"/>
> </invalidation-cache>
> ...
> <outbound-socket-binding name="local-cache-server">
> <remote-destination host="${jboss.bind.address:127.0.0.1}" port="11322"/>
> </outbound-socket-binding>
> ...
> {code}
> see standalone.sample.ha-10.1.0.Final.xml .
> *This constellation works fine using Wildfly 8.2.0 and Infinispan 7.2.5 .*
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6596) WrongClassException when using infinispan as remote-store for hibernate entity cache
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/WFLY-6596?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on WFLY-6596:
-----------------------------------
The critical info is that you use remote-store in the invalidation cache; the "entity" cache is rather a configuration template, and for each region (for each entity type) a new cache gets created. However, as you put the data from all caches to single remote store, the ids get overridden.
I wonder what is your use case for using the remote store (or basically any kind of persistence) at all, it defies the point of cache (being fast).
I think that your configuration could work when you set {{hibernate.cache.keys_factory=org.hibernate.cache.internal.DefaultCacheKeysFactory}} to revert to the old policy of using entity type as key to the cache.
> WrongClassException when using infinispan as remote-store for hibernate entity cache
> ------------------------------------------------------------------------------------
>
> Key: WFLY-6596
> URL: https://issues.jboss.org/browse/WFLY-6596
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Java version: 1.8.0_45, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_45\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos"
> Infifnspan 8.1.2 or 8.2.0
> Reporter: Gunther v. Wolffersdorff
> Assignee: Scott Marlow
> Labels: inifinispan-commons, org.hibernate.WrongClassException, remote-store
> Attachments: clustered.sample.xml, infinispan.zip, sample-10.1.0.Final-2.zip, sample-10.1.0.Final.zip, sample.zip, standalone.sample.ha-10.1.0.Final.xml, standalone.sample.ha.xml
>
>
> Starting an application and then requesting a list of cachable JPA entitties ( configured cachable using a hibernate entity invalidation-cache with a remote-server as remote-store ) causes:
> {code}
> 13:00:52,541 MESZ ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /sample-web/rest/members/listAll: org.jboss.resteasy.spi.UnhandledException: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
> Caused by: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:492) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.criteria.compile.CriteriaQueryTypeQueryAdapter.getResultList(CriteriaQueryTypeQueryAdapter.java:50) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.jboss.as.jpa.container.TypedQueryNonTxInvocationDetacher.getResultList(TypedQueryNonTxInvocationDetacher.java:58) [wildfly-jpa-10.1.0.Final.jar:10.1.0.Final]
> at de.alvara.ticket.sample.data.MemberRepository.findAllOrderedByName(MemberRepository.java:58) [sample-ejb.jar:]
> at de.alvara.ticket.sample.data.MemberRepository$Proxy$_$$_WeldClientProxy.findAllOrderedByName(Unknown Source) [sample-ejb.jar:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService.listAllMembers(MemberResourceRESTService.java:75) [classes:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService$Proxy$_$$_WeldClientProxy.listAllMembers(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_66]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_66]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_66]
> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_66]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> ... 43 more
> Caused by: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.event.internal.DefaultLoadEventListener.processCachedEntry(DefaultLoadEventListener.java:631) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:602) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:462) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.internalLoad(SessionImpl.java:1022) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:632) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolve(EntityType.java:424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:154) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:128) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1133) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.processResultSet(Loader.java:992) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQuery(Loader.java:930) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:336) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2617) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2600) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2429) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.list(Loader.java:2424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:501) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:371) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1326) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> ... 58 more
> {code}
> Entity cache is configured like this:
> {code:xml}
> ...
> <invalidation-cache name="entity" mode="SYNC">
> <eviction strategy="LRU" max-entries="1000"/>
> <expiration lifespan="45000" max-idle="30000"/>
> <remote-store cache="hibernateDistributed" socket-timeout="60000" tcp-no-delay="true" remote-servers="local-cache-server" fetch-state="false" passivation="false" preload="false" purge="true" shared="true"/>
> </invalidation-cache>
> ...
> <outbound-socket-binding name="local-cache-server">
> <remote-destination host="${jboss.bind.address:127.0.0.1}" port="11322"/>
> </outbound-socket-binding>
> ...
> {code}
> see standalone.sample.ha-10.1.0.Final.xml .
> *This constellation works fine using Wildfly 8.2.0 and Infinispan 7.2.5 .*
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1256) ForceEagerActivationOption and "not()" LHS pattern does not invoke matchCreated listener
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1256?page=com.atlassian.jira.plugi... ]
Mario Fusco closed DROOLS-1256.
-------------------------------
Resolution: Won't Fix
> ForceEagerActivationOption and "not()" LHS pattern does not invoke matchCreated listener
> ----------------------------------------------------------------------------------------
>
> Key: DROOLS-1256
> URL: https://issues.jboss.org/browse/DROOLS-1256
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.0.0.Beta1
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Priority: Minor
>
> Given the following rules
> {code:java}
> rule ND
> when
> not ( Double() )
> then
> // do nothing.
> end
> rule ND2
> salience 1
> when
> not ( Double() )
> then
> insert( new Double(0) );
> end
> {code}
> and KieSession created with {{ForceEagerActivationOption.YES}} and a generic AgendaEventListener on fire all rules returns:
> {code:java}
> created: 0 cancelled: 1 fired: 1
> {code}
> hence incoherent as matchcreated .
> Expected: created=2, cancelled=1, fired=1.
> Reporting this as also I understand this eager option is used by jBPM.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1742) Allow registering a custom handler for management interface
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1742?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1742:
------------------------------------------
Note to self: a concern with this kind of thing is a useful solution would probably result in a very broad SPI, taking a lot of stuff that is now an internal implementation detail and making it into a contract. with the result that the kernel becomes harder to evolve. For example, if we'd done something like this in EAP 6, the EAP 7 move to undertow would likely have been a breaking change. If we'd done it for WildFly 10 the WF 11 move to elytron would more likely result in some breaking change.
Perhaps a very limited SPI for this kind of thing could be developed, not exposing much more than the current Extension API plus some sort of generic HTTP-related interface not exposing undertow details. But I suspect that wouldn't be very practical or useful.
> Allow registering a custom handler for management interface
> -----------------------------------------------------------
>
> Key: WFCORE-1742
> URL: https://issues.jboss.org/browse/WFCORE-1742
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Sebastian Łaskawiec
>
> When building [HealthCheck API for Infisnispan|https://github.com/infinispan/infinispan/pull/4499] we noticed there is no way to register a custom endpoint on Management REST interface. Without it, calling the API requires using HTTP POST method (since it includes runtime parameters) and the URL is very long (and not intuitive for our users):
> {noformat}
> curl --digest -L -D - "http://localhost:9990/management/subsystem/datagrid-infinispan/cache-cont..." --header "Content-Type: application/json" -u ispnadmin:ispnadmin
> HTTP/1.1 401 Unauthorized
> Connection: keep-alive
> WWW-Authenticate: Digest realm="ManagementRealm",domain="/management",nonce="AuZzFxz7uC4NMTQ3MDgyNTU1NTQ3OCfIJBHXVpPHPBdzGUy7Qts=",opaque="00000000000000000000000000000000",algorithm=MD5,qop="auth"
> Content-Length: 77
> Content-Type: text/html
> Date: Wed, 10 Aug 2016 10:39:15 GMT
> HTTP/1.1 200 OK
> Connection: keep-alive
> Authentication-Info: nextnonce="AuZzFxz7uC4NMTQ3MDgyNTU1NTQ3OCfIJBHXVpPHPBdzGUy7Qts=",qop="auth",rspauth="b518c3170e627bd732055c382ce5d970",cnonce="NGViOWM0NDY5OGJmNjY0MjcyOWE4NDkyZDU3YzNhYjY=",nc=00000001
> Content-Type: application/json; charset=utf-8
> Content-Length: 1927
> Date: Wed, 10 Aug 2016 10:39:15 GMT
> {
> "cache-health" : "GREEN",
> "cluster-health" : ["test"],
> "cluster-name" : "clustered",
> "free-memory" : 96778,
> "log-tail" : [
> "2016-08-10 11:54:14,706 INFO [org.infinispan.server.endpoint] (MSC service thread 1-5) DGENDPT10001: HotRodServer listening on 127.0.0.1:11222",
> "2016-08-10 11:54:14,706 INFO [org.infinispan.server.endpoint] (MSC service thread 1-1) DGENDPT10001: MemcachedServer listening on 127.0.0.1:11211",
> "2016-08-10 11:54:14,785 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) DGISPN0001: Started ___protobuf_metadata cache from clustered container",
> "2016-08-10 11:54:14,800 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) DGISPN0001: Started ___script_cache cache from clustered container",
> "2016-08-10 11:54:15,159 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-5) DGISPN0001: Started ___hotRodTopologyCache cache from clustered container",
> "2016-08-10 11:54:15,210 INFO [org.infinispan.rest.NettyRestServer] (MSC service thread 1-6) ISPN012003: REST server starting, listening on 127.0.0.1:8080",
> "2016-08-10 11:54:15,210 INFO [org.infinispan.server.endpoint] (MSC service thread 1-6) DGENDPT10002: REST mapped to /rest",
> "2016-08-10 11:54:15,306 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management",
> "2016-08-10 11:54:15,307 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990",
> "2016-08-10 11:54:15,307 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: Infinispan Server 9.0.0-SNAPSHOT (WildFly Core 2.2.0.CR9) started in 8681ms - Started 196 of 237 services (121 services are lazy, passive or on-demand)"
> ],
> "number-of-cpus" : 8,
> "number-of-nodes" : 1,
> "total-memory" : 235520
> }%
> {noformat}
> It would be very convenient to allow exposing such endpoints with optional authorization and using custom URLs (e.g. something like http://localhost:9990/health).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1351) FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugi... ]
David Lloyd commented on WFCORE-1351:
-------------------------------------
OK I think the proper fix is to add a doPrivileged into the remote naming client.. possibly here:
{noformat}
at org.jboss.naming.remote.client.InitialContextFactory.createEndpoint(InitialContextFactory.java:226)
{noformat}
or here:
{noformat}
at org.jboss.naming.remote.client.EndpointCache.get(EndpointCache.java:47)
{noformat}
...to allow the endpoint to be joined with no special permissions.
> FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager
> ------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1351
> URL: https://issues.jboss.org/browse/WFCORE-1351
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting, Security
> Reporter: Ondrej Kotek
> Assignee: David Lloyd
> Priority: Critical
> Fix For: 3.0.0.Alpha8
>
> Attachments: 1-no-createEndpoint-permission.stacktrace, 2-no-createXnioWorker-permission.stacktrace, 3-no-addConnectionProvider-permission.stacktrace, 4-no-accessDeclaredMembers-permission.stractrace, 5-no-suppressAccessChecks-permission.stracktrace
>
>
> # Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like
> {noformat}
> ./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager
> {noformat}
> results in exception:
> {noformat}
> java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found
> {noformat}
> To make it work, permissions like following need to be added to _permissions.xml_ of _ejb.ear_:
> {noformat}
> new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"),
> new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"),
> new RemotingPermission("createEndpoint"),
> new RuntimePermission("createXnioWorker"),
> new RemotingPermission("addConnectionProvider"),
> new RuntimePermission("modifyThread"),
> new RuntimePermission("accessDeclaredMembers"),
> new ReflectPermission("suppressAccessChecks")
> {noformat}
> which is very confusing.
> Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1351) FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugi... ]
Lin Gao updated WFCORE-1351:
----------------------------
Attachment: 5-no-suppressAccessChecks-permission.stracktrace
4-no-accessDeclaredMembers-permission.stractrace
3-no-addConnectionProvider-permission.stacktrace
2-no-createXnioWorker-permission.stacktrace
1-no-createEndpoint-permission.stacktrace
Based on the permission sets in [NestedRemoteContextTestCase|https://github.com/wildfly/wildfly/blob/maste...], I added the permissions in the following order and get different stack trace:
# no more permissions added -> [^1-no-createEndpoint-permission.stacktrace]
# new RemotingPermission("createEndpoint") -> [^2-no-createXnioWorker-permission.stacktrace]
# new RuntimePermission("createXnioWorker") -> [^3-no-addConnectionProvider-permission.stacktrace]
# new RemotingPermission("addConnectionProvider") -> [^4-no-accessDeclaredMembers-permission.stractrace]
# new RuntimePermission("accessDeclaredMembers") -> [^5-no-suppressAccessChecks-permission.stracktrace]
# new java.lang.reflect.ReflectPermission("suppressAccessChecks") -> Test Pass
> FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager
> ------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1351
> URL: https://issues.jboss.org/browse/WFCORE-1351
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting, Security
> Reporter: Ondrej Kotek
> Assignee: David Lloyd
> Priority: Critical
> Fix For: 3.0.0.Alpha8
>
> Attachments: 1-no-createEndpoint-permission.stacktrace, 2-no-createXnioWorker-permission.stacktrace, 3-no-addConnectionProvider-permission.stacktrace, 4-no-accessDeclaredMembers-permission.stractrace, 5-no-suppressAccessChecks-permission.stracktrace
>
>
> # Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like
> {noformat}
> ./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager
> {noformat}
> results in exception:
> {noformat}
> java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found
> {noformat}
> To make it work, permissions like following need to be added to _permissions.xml_ of _ejb.ear_:
> {noformat}
> new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"),
> new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"),
> new RemotingPermission("createEndpoint"),
> new RuntimePermission("createXnioWorker"),
> new RemotingPermission("addConnectionProvider"),
> new RuntimePermission("modifyThread"),
> new RuntimePermission("accessDeclaredMembers"),
> new ReflectPermission("suppressAccessChecks")
> {noformat}
> which is very confusing.
> Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2098:
--------------------------------
Here's an example: say we use TCP and have cluster A,B,C,D,E, which is subsequently split into AB and CDE. There's no way for the AB side of the brain to know that there's a CDE side, and vice versa.
With UDP, it is simple: every side sends a multicast and so the two sides learn of each other. However, with TCP, we have to send messages individually to single members. Without discovery, neither side will know about the other.
> Discovery: reduce messages when IpAddressUUID is used
> -----------------------------------------------------
>
> Key: JGRP-2098
> URL: https://issues.jboss.org/browse/JGRP-2098
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
> Attachments: LESS_PING.java
>
>
> Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase.
> Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID.
> Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (ELY-624) Add support for SSO and Clustered SSO
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-624:
------------------------------------
Summary: Add support for SSO and Clustered SSO
Key: ELY-624
URL: https://issues.jboss.org/browse/ELY-624
Project: WildFly Elytron
Issue Type: Enhancement
Components: HTTP
Reporter: Darran Lofthouse
Assignee: Pedro Igor
Priority: Critical
Fix For: 1.1.0.Beta9
This issue is to cover the APIs / SPIs and some implementation where Elytron is to be used with container managed SSO / Clustered SSO.
By this we mean authentication mechanisms similar to HTTP Form where we want the resulting SecurityIdentity to be re-used across different HTTP context and possibly in the clustered case across different nodes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2098:
--------------------------------
I attached LESS_PING instead of polluting the message stream here with code... :-)
Yes, the primary goal of discovery is finding the coordinator.
However, a second goal is also to discover all members out there in case of a merge. For instance, consider cluster A,B,C,D,E which falls apart into A,B and C,D,E on a split. Somehow, both sides need to find out who's out there when the network partition heals. MERGE3 delegates this to the discovery protocols as they already have the means of doing this. I don't want to copy this functionality into the merge protocol itself, to prevent duplication of code.
Re MERGE2 and sendInfo(): I don't want discovery to rely on another protocol. Some configs may not even have a merge protocol in it (I've seen that, although I think that's not correct). Also, some new merge protocols may not send an INFO message at all...
> Discovery: reduce messages when IpAddressUUID is used
> -----------------------------------------------------
>
> Key: JGRP-2098
> URL: https://issues.jboss.org/browse/JGRP-2098
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
> Attachments: LESS_PING.java
>
>
> Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase.
> Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID.
> Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2098:
---------------------------
Attachment: LESS_PING.java
> Discovery: reduce messages when IpAddressUUID is used
> -----------------------------------------------------
>
> Key: JGRP-2098
> URL: https://issues.jboss.org/browse/JGRP-2098
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
> Attachments: LESS_PING.java
>
>
> Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase.
> Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID.
> Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2098:
---------------------------
Comment: was deleted
(was: In our implementation we created:
{{public class LESS_PING extends PING
{
@Override
public void findMembers( List<Address> members, boolean initial_discovery, Responses responses )
{
// no discovery except for the initial request
if ( initial_discovery )
{
try
{
sendDiscoveryRequest( cluster_name, members );
}
catch ( InterruptedIOException ie )
{
;
}
catch ( InterruptedException ex )
{
;
}
catch ( Throwable ex )
{
log.error( Util.getMessage( "FailedSendingDiscoveryRequest" ), ex );
}
}
}
protected void sendDiscoveryResponse(Address logical_addr, PhysicalAddress physical_addr,
String logical_name, final Address sender, boolean coord) {
final PingData data=new PingData(logical_addr, is_server, logical_name, physical_addr).coord(coord);
final Message rsp_msg=new Message(sender).setFlag(Message.Flag.INTERNAL, Message.Flag.OOB,
Message.Flag.DONT_BUNDLE)
.putHeader(this.id, new PingHeader(PingHeader.GET_MBRS_RSP)).setBuffer(marshal(data));
if(stagger_timeout > 0) {
int view_size=view != null? view.size() : 10;
int rank=Util.getRank(view, local_addr); // returns 0 if view or local_addr are null
if( rank > 5 )
{
// there will be plenty of responders
log.trace("%s: received GET_MBRS_REQ from %s, skipping response due to rank %d > max allowed of %d",
local_addr, sender, rank, max_rank_for_response );
}
else
{
long sleep_time = rank == 0 ? Util.random( stagger_timeout )
: stagger_timeout * rank / view_size - (stagger_timeout / view_size);
timer.schedule( new Runnable()
{
@Override
public void run()
{
log.trace( "%s: received GET_MBRS_REQ from %s, sending staggered response %s", local_addr, sender,
data );
down_prot.down( new Event( Event.MSG, rsp_msg ) );
}
}, sleep_time, TimeUnit.MILLISECONDS );
}
}
else
{
log.trace( "%s: received GET_MBRS_REQ from %s, sending response %s", local_addr, sender, data );
down_prot.down( new Event( Event.MSG, rsp_msg ) );
}
}
}
}}
This in effect limits discovery to initial discovery. In addition, discovery only responds if the rank < 5. Both of these changes work together to most eliminate discovery from the channel (because we have the IP address in the UUID))
> Discovery: reduce messages when IpAddressUUID is used
> -----------------------------------------------------
>
> Key: JGRP-2098
> URL: https://issues.jboss.org/browse/JGRP-2098
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
> Attachments: LESS_PING.java
>
>
> Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase.
> Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID.
> Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-952) Use WildFly Common for null param checks
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-952?page=com.atlassian.jira.plugin... ]
David Lloyd updated WFCORE-952:
-------------------------------
Fix Version/s: 3.0.0.Alpha8
> 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
> 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, 11 months
[JBoss JIRA] (ELY-623) Checking for anonymous principal by name is insufficient
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-623?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse reassigned ELY-623:
------------------------------------
Assignee: Darran Lofthouse
> Checking for anonymous principal by name is insufficient
> --------------------------------------------------------
>
> Key: ELY-623
> URL: https://issues.jboss.org/browse/ELY-623
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: David Lloyd
> Assignee: Darran Lofthouse
>
> In {{src/main/java/org/wildfly/security/auth/server/SecurityIdentity.java}}:
> {noformat}
> + if (AnonymousPrincipal.getInstance().getName().equals(name)) {
> + if (! context.authorizeAnonymous(false)) {
> + throw log.runAsAuthorizationFailed(getPrincipal(), new AnonymousPrincipal(), null);
> + }
> + } else {
> + if (! (context.importIdentity(this) && context.authorize(name, authorize))) {
> + throw log.runAsAuthorizationFailed(getPrincipal(), new NamePrincipal(name), null);
> + }
> }
> {noformat}
> Only a type check is sufficient to determine if a principal is anonymous. In this fix, the string name "anonymous" takes on a special meaning for the first time, which should not be the case.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1668) org.jboss.modules.ModuleNotFoundException when setting annotations=true in jboss-deployment-structure.xml
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1668?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1668:
-------------------------------------------------
Radovan Netuka <rnetuka(a)redhat.com> changed the Status of [bug 1358556|https://bugzilla.redhat.com/show_bug.cgi?id=1358556] from ASSIGNED to POST
> org.jboss.modules.ModuleNotFoundException when setting annotations=true in jboss-deployment-structure.xml
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1668
> URL: https://issues.jboss.org/browse/WFCORE-1668
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Brad Maxwell
> Assignee: Stuart Douglas
> Fix For: 3.0.0.Alpha4
>
> Attachments: reproducer.zip
>
>
> {code}
> helloWorld.ear
> - helloWorld-ejb.jar
> - HelloBean - @Stateless EJB extends AbstractBean
> - lib
> - helloWorld-api.jar
> - META-INF
> - jandex.idx
> - Hello - EJB interface
> - AbstractBean - abstract class which has @PostConstruct and implements Hello
> helloWorld2.ear
> - helloWorld2-ejb.jar
> - HelloBean2 - @Startup @Singleton extends AbstractBean
> - META-INF
> - jboss-deployment-structure.xml depends on deployment.helloWorld.ear export=true annotations=true
> {code}
> To have HelloBean2 pickup the annotations on AbstractBean, jandex.idx was generate for the helloWorld-api.jar and then the j-d-s.xml file dependency has export=true so helloWorld2-ejb.jar sees the classes and annotations=true set to pull in the annotations.
> When annotations is not set or annotations=false the helloWorld2.ear deploys (but the @PostConstruct is not run since annotations are not enabled). When annotations=true is set, helloWorld2.ear fails to deploy with the exception below.
> It looks like the annotations handling is possibly out of order as the j-d-s.xml dependency should ensure the deployment.helloWorld.ear module is there (which it does when annotations=false, but when true it seems the module is not ready)
> {code}
> 19:44:44,659 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."helloWorld2.ear".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."helloWorld2.ear".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "helloWorld2.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> 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: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.modules.ModuleNotFoundException: deployment.helloWorld.ear:main
> at org.jboss.as.server.deployment.annotation.CompositeIndexProcessor.deploy(CompositeIndexProcessor.java:91)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> Caused by: org.jboss.modules.ModuleNotFoundException: deployment.helloWorld.ear:main
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:223)
> at org.jboss.as.server.deployment.annotation.CompositeIndexProcessor.deploy(CompositeIndexProcessor.java:81)
> ... 6 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1760) Extension initialization handling makes use of PersistentResourceDefinition overly difficult
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1760:
----------------------------------------
Summary: Extension initialization handling makes use of PersistentResourceDefinition overly difficult
Key: WFCORE-1760
URL: https://issues.jboss.org/browse/WFCORE-1760
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Reporter: Brian Stansberry
PersistentResourceXMLBuilder.build() requires a PersistentResourceDefinition as an input. This is a problem because the PersistentResourcXmlDefinition is needed to initialize parsers for Extension.initializeParsers(), which is called *before* Extension.initialize(). And Extension.initialize() is when the PersistentResourceDefinition would normally be constructed.
An Extension implementation could overcome this by maintaining internal state. Construct the PersistentResourceDefinition in initializeParsers() and store it in an instance field for use in initialize(). Or vice versa. That gets messy though as now the Extension impl is needing to worry about the order in which the two methods are called and tracking whether both have been called so it can drop the cached object.
A possible thing to do is the have the ExtensionContext and ExtensionParsingContext offer an attachment API, with the lifecycle of attachments documented as being scoped to a single overall extension initialization. That could work but isn't very elegant.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6192) JAXBUsageTestCase fails with security manager with security manager enabled
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-6192?page=com.atlassian.jira.plugin.... ]
Alessio Soldano commented on WFLY-6192:
---------------------------------------
[~istudens], can't know for sure, but it looks reasonable. The problem is that even if they decide it's ok, it might take years before it's actually merged and release.
> JAXBUsageTestCase fails with security manager with security manager enabled
> ---------------------------------------------------------------------------
>
> Key: WFLY-6192
> URL: https://issues.jboss.org/browse/WFLY-6192
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Hynek Švábek
> Assignee: Ivo Studensky
>
> *org.jboss.as.test.integration.jaxb.unit.JAXBUsageTestCase#testJAXBServlet*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.jaxb.unit.JAXBUsageTestCase#testJAXBServlet}}
> Fails with:
> {code}
> ERROR [io.undertow.request] (default task-46) UT005023: Exception handling request to /jaxb-webapp//jaxbServlet: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/jaxb-webapp.war/WEB-INF/classes <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.Thread.getContextClassLoader(Thread.java:500)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:279)
> at org.jboss.as.test.integration.jaxb.JAXBUsageServlet.doGet(JAXBUsageServlet.java:50)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:180)
> at java.security.AccessController.doPrivileged(AccessController.java:650)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6192) JAXBUsageTestCase fails with security manager with security manager enabled
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-6192?page=com.atlassian.jira.plugin.... ]
Ivo Studensky commented on WFLY-6192:
-------------------------------------
[~asoldano] Do you think JAXB might accept a fix like \[1\]. I remember from some issues in the past that they refuse to merge additional privileged blocks.
\[1\] https://github.com/jboss/jaxb/compare/2.2.11-jboss...istudens:WFLY-6192?e...
> JAXBUsageTestCase fails with security manager with security manager enabled
> ---------------------------------------------------------------------------
>
> Key: WFLY-6192
> URL: https://issues.jboss.org/browse/WFLY-6192
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Hynek Švábek
> Assignee: Ivo Studensky
>
> *org.jboss.as.test.integration.jaxb.unit.JAXBUsageTestCase#testJAXBServlet*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.jaxb.unit.JAXBUsageTestCase#testJAXBServlet}}
> Fails with:
> {code}
> ERROR [io.undertow.request] (default task-46) UT005023: Exception handling request to /jaxb-webapp//jaxbServlet: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/jaxb-webapp.war/WEB-INF/classes <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.Thread.getContextClassLoader(Thread.java:500)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:279)
> at org.jboss.as.test.integration.jaxb.JAXBUsageServlet.doGet(JAXBUsageServlet.java:50)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:180)
> at java.security.AccessController.doPrivileged(AccessController.java:650)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-7033) EL break page compilation
by Marco Mondini (JIRA)
Marco Mondini created WFLY-7033:
-----------------------------------
Summary: EL break page compilation
Key: WFLY-7033
URL: https://issues.jboss.org/browse/WFLY-7033
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 10.1.0.Final
Reporter: Marco Mondini
Assignee: Stuart Douglas
In case of an expression with multiple ELs, fix for WFLY-4455 breaks braces precedence.
As a conseguence, if a single quote is present between expressions, EL Parser can't find function in second expression.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1759) add-user.sh does not return the secret value in non-interactive mode.
by Ivo Hrádek (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1759?page=com.atlassian.jira.plugi... ]
Ivo Hrádek edited comment on WFCORE-1759 at 9/2/16 8:54 AM:
------------------------------------------------------------
Hi [~ppetrou], are you working on this?
The secret value is just user's password encoded in base64, so probably you don't want to show this value on the output every time. So, I think displaying this value should be optional as in case of interactive mode.
Meanwhile, I have implemented a simple flag "--secret" or "-sv" and made a PR [1], with following behavior:
- If it was provided in non-interactive mode, the secret value would be printed, otherwise no,
- If it was provided in interactive mode, the secret value would be printed, without prompting for "yes/no",
- If it was provided in non-interactive mode together with "--silent" option, it wouldn't be printed.
btw: I think this JIRA should be more suitable for WFCORE.
EDIT1: flags has been changed to "--display-secret" and "-ds";
--
[1] https://github.com/wildfly/wildfly-core/pull/1771
was (Author: ihradek):
Hi [~ppetrou], are you working on this?
The secret value is just user's password encoded in base64, so probably you don't want to show this value on the output every time. So, I think displaying this value should be optional as in case of interactive mode.
Meanwhile, I have implemented a simple flag "--secret" or "-sv" and made a PR [1], with following behavior:
- If it was provided in non-interactive mode, the secret value would be printed, otherwise no,
- If it was provided in interactive mode, the secret value would be printed, without prompting for "yes/no",
- If it was provided in non-interactive mode together with "--silent" option, it wouldn't be printed.
btw: I think this JIRA should be more suitable for WFCORE.
--
[1] https://github.com/wildfly/wildfly-core/pull/1771
> add-user.sh does not return the secret value in non-interactive mode.
> ---------------------------------------------------------------------
>
> Key: WFCORE-1759
> URL: https://issues.jboss.org/browse/WFCORE-1759
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Reporter: Petros Petrou
> Assignee: Ivo Hrádek
> Priority: Minor
> Fix For: 3.0.0.Alpha8
>
>
> Running add-user.sh in non-interactive mode does not return the secret value of the password. It would be a useful feature when automating user creation using platform build software.
> Non-Interactive Mode
> =============
> add-user.sh --user domainuser --password welcome1!
> Added user 'domainuser' to file '\opt\wildfly-10.0.0\standalone\configuration\mgmt-users.properties'
> Added user 'domainuser' to file '\opt\wildfly-10.0.0.Final\domain\configuration\mgmt-users.properties'
> Press any key to continue . . .
> Interactive Mode
> =============
> What type of user do you wish to add?
> a) Management User (mgmt-users.properties)
> b) Application User (application-users.properties)
> (a): a
> Enter the details of the new user to add.
> Using realm 'ManagementRealm' as discovered from the existing property files.
> Username : ppetrou
> Password recommendations are listed below. To modify these restrictions edit the add-user.properties configuration file.
> - The password should be different from the username
> - The password should not be one of the following restricted values {root, admin, administrator}
> - The password should contain at least 8 characters, 1 alphabetic character(s), 1 digit(s), 1 non-alphanumeric symbol(s)
> Password :
> Re-enter Password :
> What groups do you want this user to belong to? (Please enter a comma separated list, or leave blank for none)[ ]:
> About to add user 'ppetrou' for realm 'ManagementRealm'
> Is this correct yes/no? yes
> Added user 'ppetrou' to file '\opt\wildfly-10.0.0.Final\standalone\configuration\mgmt-users.properties'
> Added user 'ppetrou' to file '\opt\wildfly-10.0.0.Final\domain\configuration\mgmt-users.properties'
> Added user 'ppetrou' with groups to file '\opt\wildfly-10.0.0.Final\standalone\configuration\mgmt-groups.properties'
> Added user 'ppetrou' with groups to file '\opt\wildfly-10.0.0.Final\domain\configuration\mgmt-groups.properties'
> Is this new user going to be used for one AS process to connect to another AS process?
> e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls.
> yes/no? yes
> To represent the user add the following to the server-identities definition <secret value="d2VsY29tZTEh" />
> Press any key to continue . . .
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1759) add-user.sh does not return the secret value in non-interactive mode.
by Ivo Hrádek (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1759?page=com.atlassian.jira.plugi... ]
Ivo Hrádek reassigned WFCORE-1759:
----------------------------------
Assignee: Ivo Hrádek
> add-user.sh does not return the secret value in non-interactive mode.
> ---------------------------------------------------------------------
>
> Key: WFCORE-1759
> URL: https://issues.jboss.org/browse/WFCORE-1759
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Reporter: Petros Petrou
> Assignee: Ivo Hrádek
> Priority: Minor
> Fix For: 3.0.0.Alpha8
>
>
> Running add-user.sh in non-interactive mode does not return the secret value of the password. It would be a useful feature when automating user creation using platform build software.
> Non-Interactive Mode
> =============
> add-user.sh --user domainuser --password welcome1!
> Added user 'domainuser' to file '\opt\wildfly-10.0.0\standalone\configuration\mgmt-users.properties'
> Added user 'domainuser' to file '\opt\wildfly-10.0.0.Final\domain\configuration\mgmt-users.properties'
> Press any key to continue . . .
> Interactive Mode
> =============
> What type of user do you wish to add?
> a) Management User (mgmt-users.properties)
> b) Application User (application-users.properties)
> (a): a
> Enter the details of the new user to add.
> Using realm 'ManagementRealm' as discovered from the existing property files.
> Username : ppetrou
> Password recommendations are listed below. To modify these restrictions edit the add-user.properties configuration file.
> - The password should be different from the username
> - The password should not be one of the following restricted values {root, admin, administrator}
> - The password should contain at least 8 characters, 1 alphabetic character(s), 1 digit(s), 1 non-alphanumeric symbol(s)
> Password :
> Re-enter Password :
> What groups do you want this user to belong to? (Please enter a comma separated list, or leave blank for none)[ ]:
> About to add user 'ppetrou' for realm 'ManagementRealm'
> Is this correct yes/no? yes
> Added user 'ppetrou' to file '\opt\wildfly-10.0.0.Final\standalone\configuration\mgmt-users.properties'
> Added user 'ppetrou' to file '\opt\wildfly-10.0.0.Final\domain\configuration\mgmt-users.properties'
> Added user 'ppetrou' with groups to file '\opt\wildfly-10.0.0.Final\standalone\configuration\mgmt-groups.properties'
> Added user 'ppetrou' with groups to file '\opt\wildfly-10.0.0.Final\domain\configuration\mgmt-groups.properties'
> Is this new user going to be used for one AS process to connect to another AS process?
> e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls.
> yes/no? yes
> To represent the user add the following to the server-identities definition <secret value="d2VsY29tZTEh" />
> Press any key to continue . . .
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1759) add-user.sh does not return the secret value in non-interactive mode.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1759?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-1759:
------------------------------------------
+1 On making it optional, users have written scripts based on non-interactive mode so we don't want to surprise them with additional output suddenly appearing - a new command line argument keeps it in their control.
> add-user.sh does not return the secret value in non-interactive mode.
> ---------------------------------------------------------------------
>
> Key: WFCORE-1759
> URL: https://issues.jboss.org/browse/WFCORE-1759
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Reporter: Petros Petrou
> Priority: Minor
> Fix For: 3.0.0.Alpha8
>
>
> Running add-user.sh in non-interactive mode does not return the secret value of the password. It would be a useful feature when automating user creation using platform build software.
> Non-Interactive Mode
> =============
> add-user.sh --user domainuser --password welcome1!
> Added user 'domainuser' to file '\opt\wildfly-10.0.0\standalone\configuration\mgmt-users.properties'
> Added user 'domainuser' to file '\opt\wildfly-10.0.0.Final\domain\configuration\mgmt-users.properties'
> Press any key to continue . . .
> Interactive Mode
> =============
> What type of user do you wish to add?
> a) Management User (mgmt-users.properties)
> b) Application User (application-users.properties)
> (a): a
> Enter the details of the new user to add.
> Using realm 'ManagementRealm' as discovered from the existing property files.
> Username : ppetrou
> Password recommendations are listed below. To modify these restrictions edit the add-user.properties configuration file.
> - The password should be different from the username
> - The password should not be one of the following restricted values {root, admin, administrator}
> - The password should contain at least 8 characters, 1 alphabetic character(s), 1 digit(s), 1 non-alphanumeric symbol(s)
> Password :
> Re-enter Password :
> What groups do you want this user to belong to? (Please enter a comma separated list, or leave blank for none)[ ]:
> About to add user 'ppetrou' for realm 'ManagementRealm'
> Is this correct yes/no? yes
> Added user 'ppetrou' to file '\opt\wildfly-10.0.0.Final\standalone\configuration\mgmt-users.properties'
> Added user 'ppetrou' to file '\opt\wildfly-10.0.0.Final\domain\configuration\mgmt-users.properties'
> Added user 'ppetrou' with groups to file '\opt\wildfly-10.0.0.Final\standalone\configuration\mgmt-groups.properties'
> Added user 'ppetrou' with groups to file '\opt\wildfly-10.0.0.Final\domain\configuration\mgmt-groups.properties'
> Is this new user going to be used for one AS process to connect to another AS process?
> e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls.
> yes/no? yes
> To represent the user add the following to the server-identities definition <secret value="d2VsY29tZTEh" />
> Press any key to continue . . .
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1759) add-user.sh does not return the secret value in non-interactive mode.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1759?page=com.atlassian.jira.plugi... ]
Darran Lofthouse moved WFLY-6656 to WFCORE-1759:
------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-1759 (was: WFLY-6656)
Component/s: Security
(was: Security)
Affects Version/s: (was: 10.0.0.Final)
Fix Version/s: 3.0.0.Alpha8
(was: Awaiting Volunteers)
> add-user.sh does not return the secret value in non-interactive mode.
> ---------------------------------------------------------------------
>
> Key: WFCORE-1759
> URL: https://issues.jboss.org/browse/WFCORE-1759
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Reporter: Petros Petrou
> Priority: Minor
> Fix For: 3.0.0.Alpha8
>
>
> Running add-user.sh in non-interactive mode does not return the secret value of the password. It would be a useful feature when automating user creation using platform build software.
> Non-Interactive Mode
> =============
> add-user.sh --user domainuser --password welcome1!
> Added user 'domainuser' to file '\opt\wildfly-10.0.0\standalone\configuration\mgmt-users.properties'
> Added user 'domainuser' to file '\opt\wildfly-10.0.0.Final\domain\configuration\mgmt-users.properties'
> Press any key to continue . . .
> Interactive Mode
> =============
> What type of user do you wish to add?
> a) Management User (mgmt-users.properties)
> b) Application User (application-users.properties)
> (a): a
> Enter the details of the new user to add.
> Using realm 'ManagementRealm' as discovered from the existing property files.
> Username : ppetrou
> Password recommendations are listed below. To modify these restrictions edit the add-user.properties configuration file.
> - The password should be different from the username
> - The password should not be one of the following restricted values {root, admin, administrator}
> - The password should contain at least 8 characters, 1 alphabetic character(s), 1 digit(s), 1 non-alphanumeric symbol(s)
> Password :
> Re-enter Password :
> What groups do you want this user to belong to? (Please enter a comma separated list, or leave blank for none)[ ]:
> About to add user 'ppetrou' for realm 'ManagementRealm'
> Is this correct yes/no? yes
> Added user 'ppetrou' to file '\opt\wildfly-10.0.0.Final\standalone\configuration\mgmt-users.properties'
> Added user 'ppetrou' to file '\opt\wildfly-10.0.0.Final\domain\configuration\mgmt-users.properties'
> Added user 'ppetrou' with groups to file '\opt\wildfly-10.0.0.Final\standalone\configuration\mgmt-groups.properties'
> Added user 'ppetrou' with groups to file '\opt\wildfly-10.0.0.Final\domain\configuration\mgmt-groups.properties'
> Is this new user going to be used for one AS process to connect to another AS process?
> e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls.
> yes/no? yes
> To represent the user add the following to the server-identities definition <secret value="d2VsY29tZTEh" />
> Press any key to continue . . .
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-952) Use WildFly Common for null param checks
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-952?page=com.atlassian.jira.plugin... ]
Darran Lofthouse commented on WFCORE-952:
-----------------------------------------
Shouldn't be a problem for Elytron if we can get this into core sooner, I will need to merge core/master into remoting5_integration a couple more times yet so if these changes are in should be able to cope with them.
> 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
> Priority: Minor
>
> 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
[JBoss JIRA] (DROOLS-1271) CepEspTest.testEventWithShortExpiration() needs another fireAllRules to flush the Propagation Queue
by Tibor Zimányi (JIRA)
Tibor Zimányi created DROOLS-1271:
-------------------------------------
Summary: CepEspTest.testEventWithShortExpiration() needs another fireAllRules to flush the Propagation Queue
Key: DROOLS-1271
URL: https://issues.jboss.org/browse/DROOLS-1271
Project: Drools
Issue Type: Enhancement
Components: core engine
Reporter: Tibor Zimányi
Assignee: Mario Fusco
Priority: Minor
Test CepEspTest.testEventWithShortExpiration sometimes fails, but it's a false positive. There's a race condition in the test between fireAllRules, which flushes PropagationQueue, and timer job that puts event expiration action into PropagationQueue. So other fireAllRules is needed in the test that will flush the queue again so we test that all expired objects are removed from the engine.
I will make a PR for this.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6656) add-user.sh does not return the secret value in non-interactive mode.
by Ivo Hrádek (JIRA)
[ https://issues.jboss.org/browse/WFLY-6656?page=com.atlassian.jira.plugin.... ]
Ivo Hrádek commented on WFLY-6656:
----------------------------------
Hi [~ppetrou], are you working on this?
The secret value is just user's password encoded in base64, so probably you don't want to show this value on the output every time. So, I think displaying this value should be optional as in case of interactive mode.
Meanwhile, I have implemented a simple flag "--secret" or "-sv" and made a PR [1], with following behavior:
- If it was provided in non-interactive mode, the secret value would be printed, otherwise no,
- If it was provided in interactive mode, the secret value would be printed, without prompting for "yes/no",
- If it was provided in non-interactive mode together with "--silent" option, it wouldn't be printed.
btw: I think this JIRA should be more suitable for WFCORE.
--
[1] https://github.com/wildfly/wildfly-core/pull/1771
> add-user.sh does not return the secret value in non-interactive mode.
> ---------------------------------------------------------------------
>
> Key: WFLY-6656
> URL: https://issues.jboss.org/browse/WFLY-6656
> Project: WildFly
> Issue Type: Feature Request
> Components: Security
> Affects Versions: 10.0.0.Final
> Reporter: Petros Petrou
> Priority: Minor
> Fix For: Awaiting Volunteers
>
>
> Running add-user.sh in non-interactive mode does not return the secret value of the password. It would be a useful feature when automating user creation using platform build software.
> Non-Interactive Mode
> =============
> add-user.sh --user domainuser --password welcome1!
> Added user 'domainuser' to file '\opt\wildfly-10.0.0\standalone\configuration\mgmt-users.properties'
> Added user 'domainuser' to file '\opt\wildfly-10.0.0.Final\domain\configuration\mgmt-users.properties'
> Press any key to continue . . .
> Interactive Mode
> =============
> What type of user do you wish to add?
> a) Management User (mgmt-users.properties)
> b) Application User (application-users.properties)
> (a): a
> Enter the details of the new user to add.
> Using realm 'ManagementRealm' as discovered from the existing property files.
> Username : ppetrou
> Password recommendations are listed below. To modify these restrictions edit the add-user.properties configuration file.
> - The password should be different from the username
> - The password should not be one of the following restricted values {root, admin, administrator}
> - The password should contain at least 8 characters, 1 alphabetic character(s), 1 digit(s), 1 non-alphanumeric symbol(s)
> Password :
> Re-enter Password :
> What groups do you want this user to belong to? (Please enter a comma separated list, or leave blank for none)[ ]:
> About to add user 'ppetrou' for realm 'ManagementRealm'
> Is this correct yes/no? yes
> Added user 'ppetrou' to file '\opt\wildfly-10.0.0.Final\standalone\configuration\mgmt-users.properties'
> Added user 'ppetrou' to file '\opt\wildfly-10.0.0.Final\domain\configuration\mgmt-users.properties'
> Added user 'ppetrou' with groups to file '\opt\wildfly-10.0.0.Final\standalone\configuration\mgmt-groups.properties'
> Added user 'ppetrou' with groups to file '\opt\wildfly-10.0.0.Final\domain\configuration\mgmt-groups.properties'
> Is this new user going to be used for one AS process to connect to another AS process?
> e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls.
> yes/no? yes
> To represent the user add the following to the server-identities definition <secret value="d2VsY29tZTEh" />
> Press any key to continue . . .
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.... ]
Martin Kouba commented on WFLY-6173:
------------------------------------
[~joeydaowang] Thanks for report. It looks like the next issue completely unrelated to CDI/Weld subsystem. My colleague Tomas Remes created JBEAP-5854.
> Classes not unloaded after undeployment
> ---------------------------------------
>
> Key: WFLY-6173
> URL: https://issues.jboss.org/browse/WFLY-6173
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Reporter: Joey Wang
> Assignee: Martin Kouba
> Priority: Blocker
> Attachments: memory-leak.zip, memory-leak_New.zip
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded.
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1758) WFLYCC0034: Closing leaked controller client
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1758?page=com.atlassian.jira.plugi... ]
Martin Choma edited comment on WFCORE-1758 at 9/2/16 4:04 AM:
--------------------------------------------------------------
I understand that it is very delicately piece of code. So most importantly potential change shouldn't break anything else. If you will decide, that finalize method can be enhanced, note, there are couple of others finalize() implementation with custom logic in wildfly core, which could be checked.
DeploymentPlanImpl
RemotingModelControllerClient
ConnectionImpl
MountHandle
Errors caused by implemented finalize() method occur probably very very rarely. So users probably can't reproduce it - hence doesn't report it.
was (Author: mchoma):
I understand that it is very delicately piece of code. So most importantly pottential change shouldn't break anything else. If you will decide, that finalize method can be enhanced, note, there are couple of others finalize() implementation with custom logic in wildfly core, which could be checked.
DeploymentPlanImpl
RemotingModelControllerClient
ConnectionImpl
MountHandle
Errors caused by implemented finalize() method occur probably very very rarely. So users probably can't reproduce it - hence doesn't report it.
> WFLYCC0034: Closing leaked controller client
> --------------------------------------------
>
> Key: WFCORE-1758
> URL: https://issues.jboss.org/browse/WFCORE-1758
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Martin Choma
> Assignee: James Perkins
> Attachments: server.log
>
>
> We are intermittently getting "WFLYCC0034: Closing leaked controller client" from RemotingModelControllerClient#finalize method.
> I wonder, isn't implementation of RemotingModelControllerClient#finalize() method [1] example of dangerous "safety net" implementation discussed in presentation "JVM finalize pitfalls" [2] ?
> *Reproducer:*
> 1. using ibm java 1.8
> 2. setting <startup-timeout>1</startup-timeout>
> [1] https://github.com/wildfly/wildfly-core/blob/master/controller-client/src...
> [2] https://www.youtube.com/watch?v=UrGP6pfb0H8
> [3]
> {noformat}
> 05:54:10 Aug 16, 2016 5:54:10 AM org.jboss.as.controller.client.impl.RemotingModelControllerClient finalize
> 05:54:10 WARN: WFLYCC0034: Closing leaked controller client
> 05:54:10 WFLYCC0030: Allocation stack trace:
> 05:54:10 at java.lang.Thread.getStackTrace(Thread.java:1552)
> 05:54:10 at org.jboss.as.controller.client.impl.RemotingModelControllerClient.<init>(RemotingModelControllerClient.java:74)
> 05:54:10 at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:567)
> 05:54:10 at org.wildfly.plugin.common.ManagementClient.<init>(ManagementClient.java:37)
> 05:54:10 at org.wildfly.plugin.common.AbstractServerConnection.createClient(AbstractServerConnection.java:126)
> 05:54:10 at org.wildfly.plugin.server.StartMojo.execute(StartMojo.java:269)
> 05:54:10 at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> 05:54:10 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 05:54:10 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 05:54:10 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 05:54:10 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> 05:54:10 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> 05:54:10 at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> 05:54:10 at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> 05:54:10 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
> 05:54:10 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> 05:54:10 at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> 05:54:10 at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
> 05:54:10 at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
> 05:54:10 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 05:54:10 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 05:54:10 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 05:54:10 at java.lang.reflect.Method.invoke(Method.java:498)
> 05:54:10 at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> 05:54:10 at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> 05:54:10 at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> 05:54:10 at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1270) support fact handle operations for REST APIs on kie server
by Dan Cimpoesu (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1270?page=com.atlassian.jira.plugi... ]
Dan Cimpoesu updated DROOLS-1270:
---------------------------------
Labels: (was: kie)
> 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: kie server
> Affects Versions: 6.5.0.CR1
> Environment: kie server
> Reporter: Dan Cimpoesu
> Assignee: Edson Tirelli
> 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.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1270) support fact handle operations for REST APIs on kie server
by Dan Cimpoesu (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1270?page=com.atlassian.jira.plugi... ]
Dan Cimpoesu updated DROOLS-1270:
---------------------------------
Labels: kie (was: )
> 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: kie server
> Affects Versions: 6.5.0.CR1
> Environment: kie server
> Reporter: Dan Cimpoesu
> Assignee: Edson Tirelli
> Labels: kie
> 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.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1270) support fact handle operations for REST APIs on kie server
by Dan Cimpoesu (JIRA)
Dan Cimpoesu created DROOLS-1270:
------------------------------------
Summary: 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: kie server
Affects Versions: 6.5.0.CR1
Environment: kie server
Reporter: Dan Cimpoesu
Assignee: Edson Tirelli
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.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1758) WFLYCC0034: Closing leaked controller client
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1758?page=com.atlassian.jira.plugi... ]
Martin Choma commented on WFCORE-1758:
--------------------------------------
I understand that it is very delicately piece of code. So most importantly pottential change shouldn't break anything else. If you will decide, that finalize method can be enhanced, note, there are couple of others finalize() implementation with custom logic in wildfly core, which could be checked.
DeploymentPlanImpl
RemotingModelControllerClient
ConnectionImpl
MountHandle
Errors caused by implemented finalize() method occur probably very very rarely. So users probably can't reproduce it - hence doesn't report it.
> WFLYCC0034: Closing leaked controller client
> --------------------------------------------
>
> Key: WFCORE-1758
> URL: https://issues.jboss.org/browse/WFCORE-1758
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Martin Choma
> Assignee: James Perkins
> Attachments: server.log
>
>
> We are intermittently getting "WFLYCC0034: Closing leaked controller client" from RemotingModelControllerClient#finalize method.
> I wonder, isn't implementation of RemotingModelControllerClient#finalize() method [1] example of dangerous "safety net" implementation discussed in presentation "JVM finalize pitfalls" [2] ?
> *Reproducer:*
> 1. using ibm java 1.8
> 2. setting <startup-timeout>1</startup-timeout>
> [1] https://github.com/wildfly/wildfly-core/blob/master/controller-client/src...
> [2] https://www.youtube.com/watch?v=UrGP6pfb0H8
> [3]
> {noformat}
> 05:54:10 Aug 16, 2016 5:54:10 AM org.jboss.as.controller.client.impl.RemotingModelControllerClient finalize
> 05:54:10 WARN: WFLYCC0034: Closing leaked controller client
> 05:54:10 WFLYCC0030: Allocation stack trace:
> 05:54:10 at java.lang.Thread.getStackTrace(Thread.java:1552)
> 05:54:10 at org.jboss.as.controller.client.impl.RemotingModelControllerClient.<init>(RemotingModelControllerClient.java:74)
> 05:54:10 at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:567)
> 05:54:10 at org.wildfly.plugin.common.ManagementClient.<init>(ManagementClient.java:37)
> 05:54:10 at org.wildfly.plugin.common.AbstractServerConnection.createClient(AbstractServerConnection.java:126)
> 05:54:10 at org.wildfly.plugin.server.StartMojo.execute(StartMojo.java:269)
> 05:54:10 at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> 05:54:10 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 05:54:10 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 05:54:10 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 05:54:10 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> 05:54:10 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> 05:54:10 at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> 05:54:10 at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> 05:54:10 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
> 05:54:10 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> 05:54:10 at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> 05:54:10 at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
> 05:54:10 at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
> 05:54:10 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 05:54:10 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 05:54:10 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 05:54:10 at java.lang.reflect.Method.invoke(Method.java:498)
> 05:54:10 at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> 05:54:10 at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> 05:54:10 at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> 05:54:10 at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[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:
-----------------------------------
Description:
... regardless of the real KieBase they actually belong to.
Ref example screenshot:
!rhqjon.png|thumbnail!
was:
... regardless of the real KieBase they actually belong to.
Ref example screenshot:
!rhqjon.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
>
>
> ... 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, 11 months
[JBoss JIRA] (WFLY-6596) WrongClassException when using infinispan as remote-store for hibernate entity cache
by Gunther v. Wolffersdorff (JIRA)
[ https://issues.jboss.org/browse/WFLY-6596?page=com.atlassian.jira.plugin.... ]
Gunther v. Wolffersdorff edited comment on WFLY-6596 at 9/2/16 3:19 AM:
------------------------------------------------------------------------
I don't think so. We are running a big application hitting this bug in Wildly 10.0.0.Final. So I created a little sample
application just for bug reporting. Our application (and the sample application) runs fine using Wildly 8.2.0 and Infinispan 7.2.5 for months.
I digged a little bit deeper and stripped the data loaded by the sample application a bit (new sample-10.1.0.Final-2.zip with smaller import.sql file).
So the simple class model is a follows:
{code}
+----------------+
| Country |
+----------------+
| id : long |
| name : string |
| iso : string |
+----------------+
| 1
|
|
| 0..*
+----------------------+
| Member |
+----------------------+
| id : long |
| name : string |
| email : string |
| phoneNumber : string |
| country ; Country |
+----------------------+
{code}
Both classes are @Cacheable .
The tables are populated by import.sql as shown below:
{code:sql}
insert into Country(id, name, iso) values (100, 'Deutschland', 'DE')
insert into Country(id, name, iso) values (102, 'Espana', 'ES')
insert into Member(id, name, email, phone_number, country_id) values (100, 'John Smith', 'john.smith(a)mailinator.com', '2125551212', 102 )
insert into Member(id, name, email, phone_number, country_id) values (110, 'Ed Moos', 'ed.moos(a)mailinator.com', '212500', 100 )
{code}
As you can see we have two countries (id=100 and id=102). Also we have a member id=100 referencing country id=102 . And we have a second member id=110 referencing country id=100;
The Hibernate entity cache has a remote-store.
We can now query all members order by id:
{code}
curl http://localhost:2680/sample-web/rest/members/listAllOrderedByIdAsc
{code}
So hibernate fetches at first member (id=100). When hibernate will fetch the second member (id=110). This member references country (id=100). But instead to fetch this country hibernate gets member (id=100) from cache.
This results in:
{code}
Object [id=100] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
{code}
(I changed the data a bit so we have new id's here)
If we remove the remote-store configuration from the cache-container configuration (<invalidation-cache name="entity">) everything runs fine. So it doesn't seems to be an application problem.
Also if we query the members in the reverse order no error occurs:
{code}
curl http://localhost:2680/sample-web/rest/members/listAllOrderedByIdDesc
{code}
This makes sense because no country is in cache having the same id as an already known (fetched) member.
was (Author: gvwolf3d):
I don't think so. We are running a big application hitting this bug in Wildly 10.0.0.Final. So I created a little sample
application just for bug reporting. Our application (and the sample application) runs fine using Wildly 8.2.0 and Infinispan 7.2.5 for months.
I digged a little bit deeper and stripped the data loaded by the sample application a bit (new sample-10.1.0.Final-2.zip with smaller import.sql file).
So the simple class model is a follows:
{code}
+----------------+
| Country |
+----------------+
| id : long |
| name : string |
| iso : string |
+----------------+
| 1
|
|
| 0..*
+----------------------+
| Member |
+----------------------+
| id : long |
| name : string |
| email : string |
| phoneNumber : string |
| country ; Country |
+----------------------+
{code}
Both classes are @Cacheable .
The tables are populated by import.sql as shown below:
{code:sql}
insert into Country(id, name, iso) values (100, 'Deutschland', 'DE')
insert into Country(id, name, iso) values (102, 'Espana', 'ES')
insert into Member(id, name, email, phone_number, country_id) values (100, 'John Smith', 'john.smith(a)mailinator.com', '2125551212', 102 )
insert into Member(id, name, email, phone_number, country_id) values (110, 'Ed Moos', 'ed.moos(a)mailinator.com', '212500', 100 )
{code}
As you can see we have two countries (id=100 and id=102). Also we have a member id=100 referencing country id=102 . And we have a second member id=110 referencing country id=100;
The Hibernate entity cache has a remote-store.
We can now query all members order by id:
{code}
curl http://localhost:2680/sample-web/rest/members/listAllOrderedByIdAsc
{code}
So hibernate fetches at first member (id=100). When hibernate will fetch the second member (id=110). This member references country (id=100). But instead to fetch this country hibernate gets member (id=100) from cache.
This results in:
{code}
Object [id=100] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member .(I changed the data a bit so we have new id's here)
{code}
If we remove the remote-store configuration from the cache-container configuration (<invalidation-cache name="entity">) everything runs fine. So it doesn't seems to be an application problem.
Also if we query the members in the reverse order no error occurs:
{code}
curl http://localhost:2680/sample-web/rest/members/listAllOrderedByIdDesc
{code}
This makes sense because no country is in cache having the same id as an already known (fetched) member.
> WrongClassException when using infinispan as remote-store for hibernate entity cache
> ------------------------------------------------------------------------------------
>
> Key: WFLY-6596
> URL: https://issues.jboss.org/browse/WFLY-6596
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Java version: 1.8.0_45, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_45\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos"
> Infifnspan 8.1.2 or 8.2.0
> Reporter: Gunther v. Wolffersdorff
> Assignee: Scott Marlow
> Labels: inifinispan-commons, org.hibernate.WrongClassException, remote-store
> Attachments: clustered.sample.xml, infinispan.zip, sample-10.1.0.Final-2.zip, sample-10.1.0.Final.zip, sample.zip, standalone.sample.ha-10.1.0.Final.xml, standalone.sample.ha.xml
>
>
> Starting an application and then requesting a list of cachable JPA entitties ( configured cachable using a hibernate entity invalidation-cache with a remote-server as remote-store ) causes:
> {code}
> 13:00:52,541 MESZ ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /sample-web/rest/members/listAll: org.jboss.resteasy.spi.UnhandledException: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
> Caused by: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:492) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.criteria.compile.CriteriaQueryTypeQueryAdapter.getResultList(CriteriaQueryTypeQueryAdapter.java:50) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.jboss.as.jpa.container.TypedQueryNonTxInvocationDetacher.getResultList(TypedQueryNonTxInvocationDetacher.java:58) [wildfly-jpa-10.1.0.Final.jar:10.1.0.Final]
> at de.alvara.ticket.sample.data.MemberRepository.findAllOrderedByName(MemberRepository.java:58) [sample-ejb.jar:]
> at de.alvara.ticket.sample.data.MemberRepository$Proxy$_$$_WeldClientProxy.findAllOrderedByName(Unknown Source) [sample-ejb.jar:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService.listAllMembers(MemberResourceRESTService.java:75) [classes:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService$Proxy$_$$_WeldClientProxy.listAllMembers(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_66]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_66]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_66]
> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_66]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> ... 43 more
> Caused by: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.event.internal.DefaultLoadEventListener.processCachedEntry(DefaultLoadEventListener.java:631) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:602) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:462) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.internalLoad(SessionImpl.java:1022) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:632) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolve(EntityType.java:424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:154) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:128) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1133) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.processResultSet(Loader.java:992) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQuery(Loader.java:930) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:336) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2617) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2600) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2429) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.list(Loader.java:2424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:501) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:371) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1326) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> ... 58 more
> {code}
> Entity cache is configured like this:
> {code:xml}
> ...
> <invalidation-cache name="entity" mode="SYNC">
> <eviction strategy="LRU" max-entries="1000"/>
> <expiration lifespan="45000" max-idle="30000"/>
> <remote-store cache="hibernateDistributed" socket-timeout="60000" tcp-no-delay="true" remote-servers="local-cache-server" fetch-state="false" passivation="false" preload="false" purge="true" shared="true"/>
> </invalidation-cache>
> ...
> <outbound-socket-binding name="local-cache-server">
> <remote-destination host="${jboss.bind.address:127.0.0.1}" port="11322"/>
> </outbound-socket-binding>
> ...
> {code}
> see standalone.sample.ha-10.1.0.Final.xml .
> *This constellation works fine using Wildfly 8.2.0 and Infinispan 7.2.5 .*
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6596) WrongClassException when using infinispan as remote-store for hibernate entity cache
by Gunther v. Wolffersdorff (JIRA)
[ https://issues.jboss.org/browse/WFLY-6596?page=com.atlassian.jira.plugin.... ]
Gunther v. Wolffersdorff edited comment on WFLY-6596 at 9/2/16 3:18 AM:
------------------------------------------------------------------------
I don't think so. We are running a big application hitting this bug in Wildly 10.0.0.Final. So I created a little sample
application just for bug reporting. Our application (and the sample application) runs fine using Wildly 8.2.0 and Infinispan 7.2.5 for months.
I digged a little bit deeper and stripped the data loaded by the sample application a bit (new sample-10.1.0.Final-2.zip with smaller import.sql file).
So the simple class model is a follows:
{code}
+----------------+
| Country |
+----------------+
| id : long |
| name : string |
| iso : string |
+----------------+
| 1
|
|
| 0..*
+----------------------+
| Member |
+----------------------+
| id : long |
| name : string |
| email : string |
| phoneNumber : string |
| country ; Country |
+----------------------+
{code}
Both classes are @Cacheable .
The tables are populated by import.sql as shown below:
{code:sql}
insert into Country(id, name, iso) values (100, 'Deutschland', 'DE')
insert into Country(id, name, iso) values (102, 'Espana', 'ES')
insert into Member(id, name, email, phone_number, country_id) values (100, 'John Smith', 'john.smith(a)mailinator.com', '2125551212', 102 )
insert into Member(id, name, email, phone_number, country_id) values (110, 'Ed Moos', 'ed.moos(a)mailinator.com', '212500', 100 )
{code}
As you can see we have two countries (id=100 and id=102). Also we have a member id=100 referencing country id=102 . And we have a second member id=110 referencing country id=100;
The Hibernate entity cache has a remote-store.
We can now query all members order by id:
{code}
curl http://localhost:2680/sample-web/rest/members/listAllOrderedByIdAsc
{code}
So hibernate fetches at first member (id=100). When hibernate will fetch the second member (id=110). This member references country (id=100). But instead to fetch this country hibernate gets member (id=100) from cache.
This results in:
{code}
Object [id=100] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member .(I changed the data a bit so we have new id's here)
{code}
If we remove the remote-store configuration from the cache-container configuration (<invalidation-cache name="entity">) everything runs fine. So it doesn't seems to be an application problem.
Also if we query the members in the reverse order no error occurs:
{code}
curl http://localhost:2680/sample-web/rest/members/listAllOrderedByIdDesc
{code}
This makes sense because no country is in cache having the same id as an already known (fetched) member.
was (Author: gvwolf3d):
I don't think so. We are running a big application hitting this bug in Wildly 10.0.0.Final. So I created a little sample
application just for bug reporting. Our application (and the sample application) runs fine using Wildly 8.2.0 and Infinispan 7.2.5 for months.
I digged a little bit deeper and stripped the data loaded by the sample application a bit (new sample-10.1.0.Final-2.zip with smaller import.sql file).
So the simple class model is a follows:
{code}
+----------------+
| Country |
+----------------+
| id : long |
| name : string |
| iso : string |
+----------------+
| 1
|
|
| 0..*
+----------------------+
| Member |
+----------------------+
| id : long |
| name : string |
| email : string |
| phoneNumber : string |
| country ; Country |
+----------------------+
{code}
Both classes are @Cacheable .
The tables are populated by import.sql as shown below:
{code:sql}
insert into Country(id, name, iso) values (100, 'Deutschland', 'DE')
insert into Country(id, name, iso) values (102, 'Espana', 'ES')
insert into Member(id, name, email, phone_number, country_id) values (100, 'John Smith', 'john.smith(a)mailinator.com', '2125551212', 102 )
insert into Member(id, name, email, phone_number, country_id) values (110, 'Ed Moos', 'ed.moos(a)mailinator.com', '212500', 100 )
{code}
As you can see we have two countries (id=100 and id=102). Also we have a member id=100 referencing country id=102 . And we have a second member id=110 referencing country 100;
The Hibernate entity cache has a remote-store.
We can now query all members order by id:
{code}
curl http://localhost:2680/sample-web/rest/members/listAllOrderedByIdAsc
{code}
So hibernate fetches at first member (id=100). When hibernate will fetch the second member (id=110). This member references country (id=100). But instead to fetch this country hibernate gets member (id=100) from cache.
This results in Object [id=100] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member .(I changed the data a bit so we have new id's here)
If we remove the remote-store configuration from the cache-container configuration (<invalidation-cache name="entity">) everything runs fine.
Also if we query the members in the reverse order no error occurs:
{code}
curl http://localhost:2680/sample-web/rest/members/listAllOrderedByIdDesc
{code}
This makes sense because no country is in cache having the same id as an already known (fetched) member.
> WrongClassException when using infinispan as remote-store for hibernate entity cache
> ------------------------------------------------------------------------------------
>
> Key: WFLY-6596
> URL: https://issues.jboss.org/browse/WFLY-6596
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Java version: 1.8.0_45, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_45\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos"
> Infifnspan 8.1.2 or 8.2.0
> Reporter: Gunther v. Wolffersdorff
> Assignee: Scott Marlow
> Labels: inifinispan-commons, org.hibernate.WrongClassException, remote-store
> Attachments: clustered.sample.xml, infinispan.zip, sample-10.1.0.Final-2.zip, sample-10.1.0.Final.zip, sample.zip, standalone.sample.ha-10.1.0.Final.xml, standalone.sample.ha.xml
>
>
> Starting an application and then requesting a list of cachable JPA entitties ( configured cachable using a hibernate entity invalidation-cache with a remote-server as remote-store ) causes:
> {code}
> 13:00:52,541 MESZ ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /sample-web/rest/members/listAll: org.jboss.resteasy.spi.UnhandledException: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
> Caused by: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:492) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.criteria.compile.CriteriaQueryTypeQueryAdapter.getResultList(CriteriaQueryTypeQueryAdapter.java:50) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.jboss.as.jpa.container.TypedQueryNonTxInvocationDetacher.getResultList(TypedQueryNonTxInvocationDetacher.java:58) [wildfly-jpa-10.1.0.Final.jar:10.1.0.Final]
> at de.alvara.ticket.sample.data.MemberRepository.findAllOrderedByName(MemberRepository.java:58) [sample-ejb.jar:]
> at de.alvara.ticket.sample.data.MemberRepository$Proxy$_$$_WeldClientProxy.findAllOrderedByName(Unknown Source) [sample-ejb.jar:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService.listAllMembers(MemberResourceRESTService.java:75) [classes:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService$Proxy$_$$_WeldClientProxy.listAllMembers(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_66]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_66]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_66]
> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_66]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> ... 43 more
> Caused by: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.event.internal.DefaultLoadEventListener.processCachedEntry(DefaultLoadEventListener.java:631) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:602) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:462) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.internalLoad(SessionImpl.java:1022) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:632) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolve(EntityType.java:424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:154) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:128) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1133) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.processResultSet(Loader.java:992) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQuery(Loader.java:930) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:336) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2617) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2600) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2429) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.list(Loader.java:2424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:501) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:371) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1326) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> ... 58 more
> {code}
> Entity cache is configured like this:
> {code:xml}
> ...
> <invalidation-cache name="entity" mode="SYNC">
> <eviction strategy="LRU" max-entries="1000"/>
> <expiration lifespan="45000" max-idle="30000"/>
> <remote-store cache="hibernateDistributed" socket-timeout="60000" tcp-no-delay="true" remote-servers="local-cache-server" fetch-state="false" passivation="false" preload="false" purge="true" shared="true"/>
> </invalidation-cache>
> ...
> <outbound-socket-binding name="local-cache-server">
> <remote-destination host="${jboss.bind.address:127.0.0.1}" port="11322"/>
> </outbound-socket-binding>
> ...
> {code}
> see standalone.sample.ha-10.1.0.Final.xml .
> *This constellation works fine using Wildfly 8.2.0 and Infinispan 7.2.5 .*
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-7027) MBeans with ObjectName attributes throw ClassNotFoundException
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-7027?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski reassigned WFLY-7027:
----------------------------------------
Assignee: Bartosz Baranowski (was: Kabir Khan)
> MBeans with ObjectName attributes throw ClassNotFoundException
> --------------------------------------------------------------
>
> Key: WFLY-7027
> URL: https://issues.jboss.org/browse/WFLY-7027
> Project: WildFly
> Issue Type: Bug
> Components: JMX
> Affects Versions: 10.0.0.Final
> Reporter: Dennis Reed
> Assignee: Bartosz Baranowski
>
> An MBean with:
> public void setObj(javax.management.ObjectName someObject)
> <mbean ...>
> <attribute name="Obj" />
> causes "java.lang.ClassNotFoundException: javax.management.MalformedObjectNameException from [Module \"org.jboss.common-beans:main\"
> org.jboss.common.beans.property.ObjectNameEditor in that module is used to convert to ObjectName objects, and requires MalformedObjectNameException but it is not on the classpath of that module.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment
by Joey Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.... ]
Joey Wang edited comment on WFLY-6173 at 9/2/16 12:49 AM:
----------------------------------------------------------
[~mkouba], thanks for the fix.
Unfortunately I found some other memory leak after undeployment. Please try to deploy [^memory-leak_New.zip] to Wildfly 10.1.0.Final, access url http://[WF host]/memoryLeak/webresources/user. Undeploy the application, found class instances of 'person.joey.test.UserType' still in memory.
I used SQL Server 2014 as DB server to reproduce this issue, but I guess it doesn't matter which DB server is used. Please let me know if you need more information.
was (Author: joeydaowang):
Unfortunately I found some other memory leak after undeployment. Please try to deploy [^memory-leak_New.zip] to Wildfly 10.1.0.Final, access url http://[WF host]/memoryLeak/webresources/user. Undeploy the application, found class instances of 'person.joey.test.UserType' still in memory.
I used SQL Server 2014 as DB server to reproduce this issue, but I guess it doesn't matter which DB server is used. Please let me know if you need more information.
> Classes not unloaded after undeployment
> ---------------------------------------
>
> Key: WFLY-6173
> URL: https://issues.jboss.org/browse/WFLY-6173
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Reporter: Joey Wang
> Assignee: Martin Kouba
> Priority: Blocker
> Attachments: memory-leak.zip, memory-leak_New.zip
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded.
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment
by Joey Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.... ]
Joey Wang edited comment on WFLY-6173 at 9/2/16 12:48 AM:
----------------------------------------------------------
Unfortunately I found some other memory leak after undeployment. Please try to deploy [^memory-leak_New.zip] to Wildfly 10.1.0.Final, access url http://[WF host]/memoryLeak/webresources/user. Undeploy the application, found class instances of 'person.joey.test.UserType' still in memory.
I used SQL Server 2014 as DB server to reproduce this issue, but I guess it doesn't matter which DB server is used. Please let me know if you need more information.
was (Author: joeydaowang):
Unfortunately I found some other memory leak after undeployment. Please try to deploy [^memory-leak_New.zip] to Wildfly 10.1.0.Final, access url http://[WF host]/memoryLeak/webresources/user. Undeploy the application, found class instances of 'person.joey.test.UserType' still in memory.
I used SQL Server 2014 as DB server to reproduce this issue, but I guess it doesn't matter which DB server is used. Please let me know if you need more information.
> Classes not unloaded after undeployment
> ---------------------------------------
>
> Key: WFLY-6173
> URL: https://issues.jboss.org/browse/WFLY-6173
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Reporter: Joey Wang
> Assignee: Martin Kouba
> Priority: Blocker
> Attachments: memory-leak.zip, memory-leak_New.zip
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded.
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment
by Joey Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.... ]
Joey Wang updated WFLY-6173:
----------------------------
Attachment: memory-leak_New.zip
Unfortunately I found some othe[^memory-leak_New.zip]r memory leak after undeployment. Please try to deploy to Wildfly 10.1.0.Final, access url http://[WF host]/memoryLeak/webresources/user. Undeploy the application, found class instances of 'person.joey.test.UserType' still in memory.
I used SQL Server 2014 as DB server to reproduce this issue, but I guess it doesn't matter which DB server is used. Please let me know if you need more information.
> Classes not unloaded after undeployment
> ---------------------------------------
>
> Key: WFLY-6173
> URL: https://issues.jboss.org/browse/WFLY-6173
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Reporter: Joey Wang
> Assignee: Martin Kouba
> Priority: Blocker
> Attachments: memory-leak.zip, memory-leak_New.zip
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded.
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment
by Joey Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.... ]
Joey Wang edited comment on WFLY-6173 at 9/2/16 12:47 AM:
----------------------------------------------------------
Unfortunately I found some other memory leak after undeployment. Please try to deploy [^memory-leak_New.zip] to Wildfly 10.1.0.Final, access url http://[WF host]/memoryLeak/webresources/user. Undeploy the application, found class instances of 'person.joey.test.UserType' still in memory.
I used SQL Server 2014 as DB server to reproduce this issue, but I guess it doesn't matter which DB server is used. Please let me know if you need more information.
was (Author: joeydaowang):
Unfortunately I found some othe[^memory-leak_New.zip]r memory leak after undeployment. Please try to deploy to Wildfly 10.1.0.Final, access url http://[WF host]/memoryLeak/webresources/user. Undeploy the application, found class instances of 'person.joey.test.UserType' still in memory.
I used SQL Server 2014 as DB server to reproduce this issue, but I guess it doesn't matter which DB server is used. Please let me know if you need more information.
> Classes not unloaded after undeployment
> ---------------------------------------
>
> Key: WFLY-6173
> URL: https://issues.jboss.org/browse/WFLY-6173
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Reporter: Joey Wang
> Assignee: Martin Kouba
> Priority: Blocker
> Attachments: memory-leak.zip, memory-leak_New.zip
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded.
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-7032) Optimize distributed web session creation
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-7032:
----------------------------------
Summary: Optimize distributed web session creation
Key: WFLY-7032
URL: https://issues.jboss.org/browse/WFLY-7032
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
Following session ID generation, we currently validate that the session ID is not already in use, in which case, we generate a new ID. This is not only racey, but requires a call to Cache.containsKey(...). This is potentially a costly call, since we need to search both memory and the cache store - particularly costly when using a remote cache store. We eventually add the new session via Cache.putIfAbsent(...), which already atomically ensures no session with that ID already exists.
Additionally, when creating the dependent cache entries for a session (i.e. access meta data, session attributes), we don't need putIfAbsent semantics - a AdvancedCache.withFlags(Flags.IGNORE_RETURN_VALUES).put(...) will suffice.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used
by Neal Dillman (JIRA)
[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ]
Neal Dillman commented on JGRP-2098:
------------------------------------
I believe that discovery should be limited to finding the coordinator. IP address mapping, logical names, what have you, can all be put into a separate, optional protocol.
Further, I am not convinced that discovery is even really needed in the manner in which it is currently done. For example, if one were to listen for sendInfo() messages from MERGE3, one would be able to determine who the coordinator is and act upon that. In other words, I believe we may wish to handle discovery as a byproduct of another protocol.
> Discovery: reduce messages when IpAddressUUID is used
> -----------------------------------------------------
>
> Key: JGRP-2098
> URL: https://issues.jboss.org/browse/JGRP-2098
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase.
> Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID.
> Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used
by Neal Dillman (JIRA)
[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ]
Neal Dillman edited comment on JGRP-2098 at 9/1/16 5:16 PM:
------------------------------------------------------------
In our implementation we created:
{{public class LESS_PING extends PING
{
@Override
public void findMembers( List<Address> members, boolean initial_discovery, Responses responses )
{
// no discovery except for the initial request
if ( initial_discovery )
{
try
{
sendDiscoveryRequest( cluster_name, members );
}
catch ( InterruptedIOException ie )
{
;
}
catch ( InterruptedException ex )
{
;
}
catch ( Throwable ex )
{
log.error( Util.getMessage( "FailedSendingDiscoveryRequest" ), ex );
}
}
}
protected void sendDiscoveryResponse(Address logical_addr, PhysicalAddress physical_addr,
String logical_name, final Address sender, boolean coord) {
final PingData data=new PingData(logical_addr, is_server, logical_name, physical_addr).coord(coord);
final Message rsp_msg=new Message(sender).setFlag(Message.Flag.INTERNAL, Message.Flag.OOB,
Message.Flag.DONT_BUNDLE)
.putHeader(this.id, new PingHeader(PingHeader.GET_MBRS_RSP)).setBuffer(marshal(data));
if(stagger_timeout > 0) {
int view_size=view != null? view.size() : 10;
int rank=Util.getRank(view, local_addr); // returns 0 if view or local_addr are null
if( rank > 5 )
{
// there will be plenty of responders
log.trace("%s: received GET_MBRS_REQ from %s, skipping response due to rank %d > max allowed of %d",
local_addr, sender, rank, max_rank_for_response );
}
else
{
long sleep_time = rank == 0 ? Util.random( stagger_timeout )
: stagger_timeout * rank / view_size - (stagger_timeout / view_size);
timer.schedule( new Runnable()
{
@Override
public void run()
{
log.trace( "%s: received GET_MBRS_REQ from %s, sending staggered response %s", local_addr, sender,
data );
down_prot.down( new Event( Event.MSG, rsp_msg ) );
}
}, sleep_time, TimeUnit.MILLISECONDS );
}
}
else
{
log.trace( "%s: received GET_MBRS_REQ from %s, sending response %s", local_addr, sender, data );
down_prot.down( new Event( Event.MSG, rsp_msg ) );
}
}
}
}}
This in effect limits discovery to initial discovery. In addition, discovery only responds if the rank < 5. Both of these changes work together to most eliminate discovery from the channel (because we have the IP address in the UUID)
was (Author: ndillman):
In our implementation we created:
public class LESS_PING extends PING
{
@Override
public void findMembers( List<Address> members, boolean initial_discovery, Responses responses )
{
// no discovery except for the initial request
if ( initial_discovery )
{
try
{
sendDiscoveryRequest( cluster_name, members );
}
catch ( InterruptedIOException ie )
{
;
}
catch ( InterruptedException ex )
{
;
}
catch ( Throwable ex )
{
log.error( Util.getMessage( "FailedSendingDiscoveryRequest" ), ex );
}
}
}
protected void sendDiscoveryResponse(Address logical_addr, PhysicalAddress physical_addr,
String logical_name, final Address sender, boolean coord) {
final PingData data=new PingData(logical_addr, is_server, logical_name, physical_addr).coord(coord);
final Message rsp_msg=new Message(sender).setFlag(Message.Flag.INTERNAL, Message.Flag.OOB,
Message.Flag.DONT_BUNDLE)
.putHeader(this.id, new PingHeader(PingHeader.GET_MBRS_RSP)).setBuffer(marshal(data));
if(stagger_timeout > 0) {
int view_size=view != null? view.size() : 10;
int rank=Util.getRank(view, local_addr); // returns 0 if view or local_addr are null
if( rank > 5 )
{
// there will be plenty of responders
log.trace("%s: received GET_MBRS_REQ from %s, skipping response due to rank %d > max allowed of %d",
local_addr, sender, rank, max_rank_for_response );
}
else
{
long sleep_time = rank == 0 ? Util.random( stagger_timeout )
: stagger_timeout * rank / view_size - (stagger_timeout / view_size);
timer.schedule( new Runnable()
{
@Override
public void run()
{
log.trace( "%s: received GET_MBRS_REQ from %s, sending staggered response %s", local_addr, sender,
data );
down_prot.down( new Event( Event.MSG, rsp_msg ) );
}
}, sleep_time, TimeUnit.MILLISECONDS );
}
}
else
{
log.trace( "%s: received GET_MBRS_REQ from %s, sending response %s", local_addr, sender, data );
down_prot.down( new Event( Event.MSG, rsp_msg ) );
}
}
}
This in effect limits discovery to initial discovery. In addition, discovery only responds if the rank < 5. Both of these changes work together to most eliminate discovery from the channel (because we have the IP address in the UUID)
> Discovery: reduce messages when IpAddressUUID is used
> -----------------------------------------------------
>
> Key: JGRP-2098
> URL: https://issues.jboss.org/browse/JGRP-2098
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase.
> Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID.
> Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used
by Neal Dillman (JIRA)
[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ]
Neal Dillman commented on JGRP-2098:
------------------------------------
In our implementation we created:
public class LESS_PING extends PING
{
@Override
public void findMembers( List<Address> members, boolean initial_discovery, Responses responses )
{
// no discovery except for the initial request
if ( initial_discovery )
{
try
{
sendDiscoveryRequest( cluster_name, members );
}
catch ( InterruptedIOException ie )
{
;
}
catch ( InterruptedException ex )
{
;
}
catch ( Throwable ex )
{
log.error( Util.getMessage( "FailedSendingDiscoveryRequest" ), ex );
}
}
}
protected void sendDiscoveryResponse(Address logical_addr, PhysicalAddress physical_addr,
String logical_name, final Address sender, boolean coord) {
final PingData data=new PingData(logical_addr, is_server, logical_name, physical_addr).coord(coord);
final Message rsp_msg=new Message(sender).setFlag(Message.Flag.INTERNAL, Message.Flag.OOB,
Message.Flag.DONT_BUNDLE)
.putHeader(this.id, new PingHeader(PingHeader.GET_MBRS_RSP)).setBuffer(marshal(data));
if(stagger_timeout > 0) {
int view_size=view != null? view.size() : 10;
int rank=Util.getRank(view, local_addr); // returns 0 if view or local_addr are null
if( rank > 5 )
{
// there will be plenty of responders
log.trace("%s: received GET_MBRS_REQ from %s, skipping response due to rank %d > max allowed of %d",
local_addr, sender, rank, max_rank_for_response );
}
else
{
long sleep_time = rank == 0 ? Util.random( stagger_timeout )
: stagger_timeout * rank / view_size - (stagger_timeout / view_size);
timer.schedule( new Runnable()
{
@Override
public void run()
{
log.trace( "%s: received GET_MBRS_REQ from %s, sending staggered response %s", local_addr, sender,
data );
down_prot.down( new Event( Event.MSG, rsp_msg ) );
}
}, sleep_time, TimeUnit.MILLISECONDS );
}
}
else
{
log.trace( "%s: received GET_MBRS_REQ from %s, sending response %s", local_addr, sender, data );
down_prot.down( new Event( Event.MSG, rsp_msg ) );
}
}
}
This in effect limits discovery to initial discovery. In addition, discovery only responds if the rank < 5. Both of these changes work together to most eliminate discovery from the channel (because we have the IP address in the UUID)
> Discovery: reduce messages when IpAddressUUID is used
> -----------------------------------------------------
>
> Key: JGRP-2098
> URL: https://issues.jboss.org/browse/JGRP-2098
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase.
> Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID.
> Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[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 commented on WFCORE-952:
-----------------------------------------
Sure, or just feel free to schedule it again for whenever. As part of releasing Alpha7 I went through all the JIRAs scheduled for it that just seemed to be rolling from release to release and tried to clean some of those out. My previous comment is generic one that I pasted into all of them.
> 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
> Priority: Minor
>
> 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
[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/1/16 4:28 PM:
-------------------------------------------------------------------
Just a summary of the circumstances:
- cluster of node-0 and node-1, with SFSB SlowToDestroyStatefulIncrementorBean deployed on both nodes
- a session is created on node-0, which is the owner node
- invocations progress normally against node-0
- on node-0, the process of undeploying the deployment and shutting down the node is started
- an invocation arrives at node-0 as the deployment is undeploying
-- the EJB interceptor returns a EJBComponentUnavailable exception to the EJB client for the invocation
-- the invocation is retried on node-1
- the invocation proceeds on node-1, within a container managed transaction (CMTTxInterceptor)
- we get the session corresponding to the session id from the ISPN cache (StatefulComponentInstanceInterceptor)
- a GetKeyValueCommand is invoked on node-1 and this causes an RPC to get the session from its owner on node-0
- the RPC arrives at node-0, but as the cache is in stopping mode, the exception of this issue arises
- the ISPN caller of get() receives a RemoteException
- the CMTTxInterceptor fails the invocation by rolling back and returns an exception to the client
Note that despite the fact that clean shutdown was used on node-0 with a timeout of 15 seconds, it still allows node-0 to shutdown fairly quickly, as there are probably few pending invocations at the time of shutdown which the suspend mechanism needs to wait for to complete.
Need to check:
a) when is the topology change received by node-1?
-- hard to tell, I don't see any topology change messages after node-0 stops; only after it has restarted
-- however, the JGroups view change is is visible and it is received after the exception arises
4:31:43:502 -> exception is raised
4:31:43:732 -> JGroups view change arrives
-- I assume that the reason why node-1 sends the RPC to node-0 is because it is using the latest (but out of date) topoology that it has on hand
b) Is this simply a case that it is impossible for ISPN to react to topology changes as quickly as invocations may get redirected by the EJB client (i.e. in a few ms)?
If that is the case, i'm wondering what to do in general in the case where an owner node is no longer available in the current topology (as is the case here with node-0 and the session instance it is holding) despite the fact that the current topology says it should be? Unless the numOwners=1, should it not look elsewhere for a copy of the cache entry and return that as a result of the invocation, rather than throw an exception if the owner node is not available?
Here is the cache configuration from the server configuration:
{code:xml}
<cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">
<transport lock-timeout="60000"/>
<distributed-cache name="dist" mode="ASYNC" l1-lifespan="0" owners="2">
<locking isolation="REPEATABLE_READ"/>
<transaction mode="BATCH"/>
<file-store/>
</distributed-cache>
</cache-container>
{code}
was (Author: rachmato):
Just a summary of the circumstances:
- cluster of node-0 and node-1, with SFSB SlowToDestroyStatefulIncrementorBean deployed on both nodes
- a session is created on node-0, which is the owner node
- invocations progress normally against node-0
- on node-0, the process of undeploying the deployment and shutting down the node is started
- an invocation arrives at node-0 as the deployment is undeploying
-- the EJB interceptor returns a EJBComponentUnavailable exception to the EJB client for the invocation
-- the invocation is retried on node-1
- the invocation proceeds on node-1, within a container managed transaction (CMTTxInterceptor)
- in one EJB interceptor (???? - forgot), we get the session corresponding to the session id from the ISPN cache
- a GetKeyValueCommand is invoked on node-1 and this causes an RPC to get the session from its owner on node-0
- the RPC arrives at node-0, but as the cache is in stopping mode, the exception of this issue arises
- the ISPN caller of get() receives a RemoteException
- the CMTTxInterceptor fails the invocation by rolling back and returns an exception to the client
Note that despite the fact that clean shutdown was used on node-0 with a timeout of 15 seconds, it still allows node-0 to shutdown fairly quickly, as there are probably few pending invocations at the time of shutdown which the suspend mechanism needs to wait for to complete.
Need to check:
a) when is the topology change received by node-1?
-- hard to tell, I don't see any topology change messages after node-0 stops; only after it has restarted
-- however, the JGroups view change is is visible and it is received after the exception arises
4:31:43:502 -> exception is raised
4:31:43:732 -> JGroups view change arrives
-- I assume that the reason why node-1 sends the RPC to node-0 is because it is using the latest (but out of date) topoology that it has on hand
b) Is this simply a case that it is impossible for ISPN to react to topology changes as quickly as invocations may get redirected by the EJB client (i.e. in a few ms)?
If that is the case, i'm wondering what to do in general in the case where an owner node is no longer available in the current topology (as is the case here with node-0 and the session instance it is holding) despite the fact that the current topology says it should be? Unless the numOwners=1, should it not look elsewhere for a copy of the cache entry and return that as a result of the invocation, rather than throw an exception if the owner node is not available?
Here is the cache configuration from the server configuration:
{code:xml}
<cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">
<transport lock-timeout="60000"/>
<distributed-cache name="dist" mode="ASYNC" l1-lifespan="0" owners="2">
<locking isolation="REPEATABLE_READ"/>
<transaction mode="BATCH"/>
<file-store/>
</distributed-cache>
</cache-container>
{code}
> 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
> &#27;[0m04:31:43,338 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0211: Suspending server with 15000 ms timeout.
> &#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)
> &#27;[0m04:31:43,345 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown'
> &#27;[0m&#27;[0m04:31:43,430 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping
> &#27;[0m&#27;[0m04:31:43,436 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 29) MODCLUSTER000002: Initiating mod_cluster shutdown
> &#27;[0m&#27;[0m04:31:43,445 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 74) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:/ConnectionFactory
> &#27;[0m&#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000080: Disconnecting JGroups channel hibernate
> &#27;[0m&#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher for channel hibernate
> &#27;[0m&#27;[0m04:31:43,463 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000080: Disconnecting JGroups channel server
> &#27;[0m&#27;[0m04:31:43,464 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000082: Stopping the RpcDispatcher for channel server
> &#27;[0m&#27;[0m04:31:43,471 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000029: Passivating all entries to disk
> &#27;[0m&#27;[0m04:31:43,472 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000030: Passivated 2 entries in 0 milliseconds
> &#27;[0m&#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel web
> &#27;[0m&#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel web
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel testDbPersistence
> &#27;[0m&#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel testDbPersistence
> &#27;[0m&#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)
> &#27;[0m&#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
> &#27;[0m&#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]
> &#27;[0m&#27;[0m04:31:43,518 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA]
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,547 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 2) WFLYCLINF0003: Stopped client-mappings cache from ejb container
> &#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
> &#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000080: Disconnecting JGroups channel ejb
> &#27;[0m&#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000082: Stopping the RpcDispatcher for channel ejb
> &#27;[0m&#27;[0m04:31:43,575 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 35) AMQ151003: resource adaptor stopped
> &#27;[0m&#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow AJP listener ajp suspending
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTPS listener https suspending
> &#27;[0m&#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
> &#27;[0m&#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
> &#27;[0m&#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
[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/1/16 4:25 PM:
-------------------------------------------------------------------
Just a summary of the circumstances:
- cluster of node-0 and node-1, with SFSB SlowToDestroyStatefulIncrementorBean deployed on both nodes
- a session is created on node-0, which is the owner node
- invocations progress normally against node-0
- on node-0, the process of undeploying the deployment and shutting down the node is started
- an invocation arrives at node-0 as the deployment is undeploying
-- the EJB interceptor returns a EJBComponentUnavailable exception to the EJB client for the invocation
-- the invocation is retried on node-1
- the invocation proceeds on node-1, within a container managed transaction (CMTTxInterceptor)
- in one EJB interceptor (???? - forgot), we get the session corresponding to the session id from the ISPN cache
- a GetKeyValueCommand is invoked on node-1 and this causes an RPC to get the session from its owner on node-0
- the RPC arrives at node-0, but as the cache is in stopping mode, the exception of this issue arises
- the ISPN caller of get() receives a RemoteException
- the CMTTxInterceptor fails the invocation by rolling back and returns an exception to the client
Note that despite the fact that clean shutdown was used on node-0 with a timeout of 15 seconds, it still allows node-0 to shutdown fairly quickly, as there are probably few pending invocations at the time of shutdown which the suspend mechanism needs to wait for to complete.
Need to check:
a) when is the topology change received by node-1?
-- hard to tell, I don't see any topology change messages after node-0 stops; only after it has restarted
-- however, the JGroups view change is is visible and it is received after the exception arises
4:31:43:502 -> exception is raised
4:31:43:732 -> JGroups view change arrives
-- I assume that the reason why node-1 sends the RPC to node-0 is because it is using the latest (but out of date) topoology that it has on hand
b) Is this simply a case that it is impossible for ISPN to react to topology changes as quickly as invocations may get redirected by the EJB client (i.e. in a few ms)?
If that is the case, i'm wondering what to do in general in the case where an owner node is no longer available in the current topology (as is the case here with node-0 and the session instance it is holding) despite the fact that the current topology says it should be? Unless the numOwners=1, should it not look elsewhere for a copy of the cache entry and return that as a result of the invocation, rather than throw an exception if the owner node is not available?
Here is the cache configuration from the server configuration:
{code:xml}
<cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">
<transport lock-timeout="60000"/>
<distributed-cache name="dist" mode="ASYNC" l1-lifespan="0" owners="2">
<locking isolation="REPEATABLE_READ"/>
<transaction mode="BATCH"/>
<file-store/>
</distributed-cache>
</cache-container>
{code}
was (Author: rachmato):
Just a summary of the circumstances:
- cluster of node-0 and node-1, with SFSB SlowToDestroyStatefulIncrementorBean deployed on both nodes
- a session is created on node-0, which is the owner node
- invocations progress normally against node-0
- on node-0, the process of undeploying the deployment and shutting down the node is started
- an invocation arrives at node-0 as the deployment is undeploying
-- the EJB interceptor returns a EJBComponentUnavailable exception to the EJB client for the invocation
-- the invocation is retried on node-1
- the invocation proceeds on node-1, within a container managed transaction (CMTTxInterceptor)
- in one EJB interceptor (???? - forgot), we get the session corresponding to the session id from the ISPN cache
- a GetKeyValueCommand is invoked on node-1 and this causes an RPC to get the session from its owner on node-0
- the RPC arrives at node-0, but as the cache is in stopping mode, the exception of this issue arises
- the ISPN caller of get() receives a RemoteException
- the CMTTxInterceptor fails the invocation by rolling back and returns an exception to the client
Note that despite the fact that clean shutdown was used on node-0 with a timeout of 15 seconds, it still allows node-0 to shutdown fairly quickly, as there are probably few pending invocations at the time of shutdown which the suspend mechanism needs to wait for to complete.
Need to check:
a) when is the topology change received by node-1?
-- hard to tell, I don't see any topology change messages after node-0 stops; only after it has restarted
-- however, the JGroups view change is is visible and it is received after the exception arises
4:31:43:502 -> exception is raised
4:31:43:732 -> JGroups view change arrives
-- I assume that the reason why node-1 sends the RPC to node-0 is because it is using the latest (but out of date) topoology that it has on hand
b) Is this simply a case that it is impossible for ISPN to react to topology changes as quickly as invocations may get redirected by the EJB client (i.e. in a few ms)?
If that is the case, i'm wondering what to do in general in the case where an owner node is no longer available in the current topology (as is the case here with node-0 and the session instance it is holding) despite the fact that the current topology says it should be? Unless the numOwners=1, should it not look elsewhere for a copy of the cache entry and return that as a result of the invocation, rather than throw an exception if the owner node is not available?
Here is the cache configuration from the server configuration:
{code:xml}
<cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">
<transport lock-timeout="60000"/>
<distributed-cache name="dist" mode="ASYNC" l1-lifespan="0" owners="2">
<locking isolation="REPEATABLE_READ"/>
<transaction mode="BATCH"/>
<file-store/>
</distributed-cache>
</cache-container>
{code}
> 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
> &#27;[0m04:31:43,338 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0211: Suspending server with 15000 ms timeout.
> &#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)
> &#27;[0m04:31:43,345 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown'
> &#27;[0m&#27;[0m04:31:43,430 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping
> &#27;[0m&#27;[0m04:31:43,436 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 29) MODCLUSTER000002: Initiating mod_cluster shutdown
> &#27;[0m&#27;[0m04:31:43,445 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 74) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:/ConnectionFactory
> &#27;[0m&#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000080: Disconnecting JGroups channel hibernate
> &#27;[0m&#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher for channel hibernate
> &#27;[0m&#27;[0m04:31:43,463 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000080: Disconnecting JGroups channel server
> &#27;[0m&#27;[0m04:31:43,464 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000082: Stopping the RpcDispatcher for channel server
> &#27;[0m&#27;[0m04:31:43,471 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000029: Passivating all entries to disk
> &#27;[0m&#27;[0m04:31:43,472 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000030: Passivated 2 entries in 0 milliseconds
> &#27;[0m&#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel web
> &#27;[0m&#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel web
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel testDbPersistence
> &#27;[0m&#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel testDbPersistence
> &#27;[0m&#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)
> &#27;[0m&#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
> &#27;[0m&#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]
> &#27;[0m&#27;[0m04:31:43,518 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA]
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,547 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 2) WFLYCLINF0003: Stopped client-mappings cache from ejb container
> &#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
> &#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000080: Disconnecting JGroups channel ejb
> &#27;[0m&#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000082: Stopping the RpcDispatcher for channel ejb
> &#27;[0m&#27;[0m04:31:43,575 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 35) AMQ151003: resource adaptor stopped
> &#27;[0m&#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow AJP listener ajp suspending
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTPS listener https suspending
> &#27;[0m&#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
> &#27;[0m&#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
> &#27;[0m&#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
[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/1/16 4:24 PM:
-------------------------------------------------------------------
Just a summary of the circumstances:
- cluster of node-0 and node-1, with SFSB SlowToDestroyStatefulIncrementorBean deployed on both nodes
- a session is created on node-0, which is the owner node
- invocations progress normally against node-0
- on node-0, the process of undeploying the deployment and shutting down the node is started
- an invocation arrives at node-0 as the deployment is undeploying
-- the EJB interceptor returns a EJBComponentUnavailable exception to the EJB client for the invocation
-- the invocation is retried on node-1
- the invocation proceeds on node-1, within a container managed transaction (CMTTxInterceptor)
- in one EJB interceptor (???? - forgot), we get the session corresponding to the session id from the ISPN cache
- a GetKeyValueCommand is invoked on node-1 and this causes an RPC to get the session from its owner on node-0
- the RPC arrives at node-0, but as the cache is in stopping mode, the exception of this issue arises
- the ISPN caller of get() receives a RemoteException
- the CMTTxInterceptor fails the invocation by rolling back and returns an exception to the client
Note that despite the fact that clean shutdown was used on node-0 with a timeout of 15 seconds, it still allows node-0 to shutdown fairly quickly, as there are probably few pending invocations at the time of shutdown which the suspend mechanism needs to wait for to complete.
Need to check:
a) when is the topology change received by node-1?
-- hard to tell, I don't see any topology change messages after node-0 stops; only after it has restarted
-- however, the JGroups view change is is visible and it is received after the exception arises
4:31:43:502 -> exception is raised
4:31:43:732 -> JGroups view change arrives
-- I assume that the reason why node-1 sends the RPC to node-0 is because it is using the latest (but out of date) topoology that it has on hand
b) Is this simply a case that it is impossible for ISPN to react to topology changes as quickly as invocations may get redirected by the EJB client (i.e. in a few ms)?
If that is the case, i'm wondering what to do in general in the case where an owner node is no longer available in the current topology (as is the case here with node-0 and the session instance it is holding) despite the fact that the current topology says it should be? Unless the numOwners=1, should it not look elsewhere for a copy of the cache entry and return that as a result of the invocation, rather than throw an exception if the owner node is not available?
Here is the cache configuration from the server configuration:
{code:xml}
<cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">
<transport lock-timeout="60000"/>
<distributed-cache name="dist" mode="ASYNC" l1-lifespan="0" owners="2">
<locking isolation="REPEATABLE_READ"/>
<transaction mode="BATCH"/>
<file-store/>
</distributed-cache>
</cache-container>
{code}
was (Author: rachmato):
Just a summary of the circumstances:
- cluster of node-0 and node-1, with SFSB SlowToDestroyStatefulIncrementorBean deployed on both nodes
- a session is created on node-0, which is the owner node
- invocations progress normally against node-0
- on node-0, the process of undeploying the deployment and shutting down the node is started
- an invocation arrives at node-0 as the deployment is undeploying
-- the EJB interceptor returns a EJBComponentUnavailable exception to the EJB client for the invocation
-- the invocation is retried on node-1
- the invocation proceeds on node-1, within a container managed transaction (CMTTxInterceptor)
- in one EJB interceptor (???? - forgot), we get the session corresponding to the session id from the ISPN cache
- a GetKeyValueCommand is invoked on node-1 and this causes an RPC to get the session from its owner on node-0
- the RPC arrives at node-0, but as the cache is in stopping mode, the exception of this issue arises
- the ISPN caller of get() receives a RemoteException
- the CMTTxInterceptor fails the invocation by rolling back and returns an exception to the client
Note that despite the fact that clean shutdown was used on node-0 with a timeout of 15 seconds, it still allows node-0 to shutdown fairly quickly, as there are probably few pending invocations at the time of shutdown which the suspend mechanism needs to wait for to complete.
Need to check:
a) when is the topology change received by node-1?
-- hard to tell, I don't see any topology change messages after node-0 stops; only after it has restarted
-- however, the JGroups view change is is visible and it is received after the exception arises
4:31:43:502 -> exception is raised
4:31:43:732 -> JGroups view change arrives
-- I assume that the reason why node-1 sends the RPC to node-0 is because it is using the latest (but out of date) topoology that it has on hand
b) Is this simply a case that it is impossible for ISPN to react to topology changes as quickly as invocations may get redirected by the EJB client (i.e. in a few ms)?
If that is the case, i'm wondering what to do in general in the case where an owner node is no longer available in the current topology (as is the case here with node-0 and the session instance it is holding) despite the fact that the current topology says it should be? Unless the numOwners=1, should it not look elsewhere for a copy of the cache entry and return that as a result of the invocation, rather than throw an exception if the owner node is not available?
Here is the cache configuration from the server configuration:
{code:xml}
<cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">
<transport lock-timeout="60000"/>
<distributed-cache name="dist" mode="ASYNC" l1-lifespan="0" owners="2">
<locking isolation="REPEATABLE_READ"/>
<transaction mode="BATCH"/>
<file-store/>
</distributed-cache>
</cache-container>
{code:xml}
> 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
> &#27;[0m04:31:43,338 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0211: Suspending server with 15000 ms timeout.
> &#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)
> &#27;[0m04:31:43,345 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown'
> &#27;[0m&#27;[0m04:31:43,430 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping
> &#27;[0m&#27;[0m04:31:43,436 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 29) MODCLUSTER000002: Initiating mod_cluster shutdown
> &#27;[0m&#27;[0m04:31:43,445 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 74) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:/ConnectionFactory
> &#27;[0m&#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000080: Disconnecting JGroups channel hibernate
> &#27;[0m&#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher for channel hibernate
> &#27;[0m&#27;[0m04:31:43,463 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000080: Disconnecting JGroups channel server
> &#27;[0m&#27;[0m04:31:43,464 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000082: Stopping the RpcDispatcher for channel server
> &#27;[0m&#27;[0m04:31:43,471 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000029: Passivating all entries to disk
> &#27;[0m&#27;[0m04:31:43,472 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000030: Passivated 2 entries in 0 milliseconds
> &#27;[0m&#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel web
> &#27;[0m&#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel web
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel testDbPersistence
> &#27;[0m&#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel testDbPersistence
> &#27;[0m&#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)
> &#27;[0m&#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
> &#27;[0m&#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]
> &#27;[0m&#27;[0m04:31:43,518 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA]
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,547 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 2) WFLYCLINF0003: Stopped client-mappings cache from ejb container
> &#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
> &#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000080: Disconnecting JGroups channel ejb
> &#27;[0m&#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000082: Stopping the RpcDispatcher for channel ejb
> &#27;[0m&#27;[0m04:31:43,575 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 35) AMQ151003: resource adaptor stopped
> &#27;[0m&#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow AJP listener ajp suspending
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTPS listener https suspending
> &#27;[0m&#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
> &#27;[0m&#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
> &#27;[0m&#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
[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/1/16 4:23 PM:
-------------------------------------------------------------------
Just a summary of the circumstances:
- cluster of node-0 and node-1, with SFSB SlowToDestroyStatefulIncrementorBean deployed on both nodes
- a session is created on node-0, which is the owner node
- invocations progress normally against node-0
- on node-0, the process of undeploying the deployment and shutting down the node is started
- an invocation arrives at node-0 as the deployment is undeploying
-- the EJB interceptor returns a EJBComponentUnavailable exception to the EJB client for the invocation
-- the invocation is retried on node-1
- the invocation proceeds on node-1, within a container managed transaction (CMTTxInterceptor)
- in one EJB interceptor (???? - forgot), we get the session corresponding to the session id from the ISPN cache
- a GetKeyValueCommand is invoked on node-1 and this causes an RPC to get the session from its owner on node-0
- the RPC arrives at node-0, but as the cache is in stopping mode, the exception of this issue arises
- the ISPN caller of get() receives a RemoteException
- the CMTTxInterceptor fails the invocation by rolling back and returns an exception to the client
Note that despite the fact that clean shutdown was used on node-0 with a timeout of 15 seconds, it still allows node-0 to shutdown fairly quickly, as there are probably few pending invocations at the time of shutdown which the suspend mechanism needs to wait for to complete.
Need to check:
a) when is the topology change received by node-1?
-- hard to tell, I don't see any topology change messages after node-0 stops; only after it has restarted
-- however, the JGroups view change is is visible and it is received after the exception arises
4:31:43:502 -> exception is raised
4:31:43:732 -> JGroups view change arrives
-- I assume that the reason why node-1 sends the RPC to node-0 is because it is using the latest (but out of date) topoology that it has on hand
b) Is this simply a case that it is impossible for ISPN to react to topology changes as quickly as invocations may get redirected by the EJB client (i.e. in a few ms)?
If that is the case, i'm wondering what to do in general in the case where an owner node is no longer available in the current topology (as is the case here with node-0 and the session instance it is holding) despite the fact that the current topology says it should be? Unless the numOwners=1, should it not look elsewhere for a copy of the cache entry and return that as a result of the invocation, rather than throw an exception if the owner node is not available?
Here is the cache configuration from the server configuration:
{code:xml}
<cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">
<transport lock-timeout="60000"/>
<distributed-cache name="dist" mode="ASYNC" l1-lifespan="0" owners="2">
<locking isolation="REPEATABLE_READ"/>
<transaction mode="BATCH"/>
<file-store/>
</distributed-cache>
</cache-container>
{code:xml}
was (Author: rachmato):
Just a summary of the circumstances:
- cluster of node-0 and node-1, with SFSB SlowToDestroyStatefulIncrementorBean deployed on both nodes
- a session is created on node-0, which is the owner node
- invocations progress normally against node-0
- on node-0, the process of undeploying the deployment and shutting down the node is started
- an invocation arrives at node-0 as the deployment is undeploying
-- the EJB interceptor returns a EJBComponentUnavailable exception to the EJB client for the invocation
-- the invocation is retried on node-1
- the invocation proceeds on node-1, within a container managed transaction (CMTTxInterceptor)
- in one EJB interceptor (???? - forgot), we get the session corresponding to the session id from the ISPN cache
- a GetKeyValueCommand is invoked on node-1 and this causes an RPC to get the session from its owner on node-0
- the RPC arrives at node-0, but as the cache is in stopping mode, the exception of this issue arises
- the ISPN caller of get() receives a RemoteException
- the CMTTxInterceptor fails the invocation by rolling back and returns an exception to the client
Note that despite the fact that clean shutdown was used on node-0 with a timeout of 15 seconds, it still allows node-0 to shutdown fairly quickly, as there are probably few pending invocations at the time of shutdown which the suspend mechanism needs to wait for to complete.
Need to check:
a) when is the topology change received by node-1?
-- hard to tell, I don't see any topology change messages after node-0 stops; only after it has restarted
-- however, the JGroups view change is is visible and it is received after the exception arises
4:31:43:502 -> exception is raised
4:31:43:732 -> JGroups view change arrives
-- I assume that the reason why node-1 sends the RPC to node-0 is because it is using the latest (but out of date) topoology that it has on hand
b) Is this simply a case that it is impossible for ISPN to react to topology changes as quickly as invocations may get redirected by the EJB client (i.e. in a few ms)?
If that is the case, i'm wondering what to do in general in the case where an owner node is no longer available in the current topology (as is the case here with node-0 and the session instance it is holding) despite the fact that the current topology says it should be? Unless the numOwners=1, should it not look elsewhere for a copy of the cache entry and return that as a result of the invocation, rather than throw an exception if the owner node is not available?
> 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
> &#27;[0m04:31:43,338 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0211: Suspending server with 15000 ms timeout.
> &#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)
> &#27;[0m04:31:43,345 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown'
> &#27;[0m&#27;[0m04:31:43,430 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping
> &#27;[0m&#27;[0m04:31:43,436 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 29) MODCLUSTER000002: Initiating mod_cluster shutdown
> &#27;[0m&#27;[0m04:31:43,445 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 74) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:/ConnectionFactory
> &#27;[0m&#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000080: Disconnecting JGroups channel hibernate
> &#27;[0m&#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher for channel hibernate
> &#27;[0m&#27;[0m04:31:43,463 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000080: Disconnecting JGroups channel server
> &#27;[0m&#27;[0m04:31:43,464 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000082: Stopping the RpcDispatcher for channel server
> &#27;[0m&#27;[0m04:31:43,471 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000029: Passivating all entries to disk
> &#27;[0m&#27;[0m04:31:43,472 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000030: Passivated 2 entries in 0 milliseconds
> &#27;[0m&#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel web
> &#27;[0m&#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel web
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel testDbPersistence
> &#27;[0m&#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel testDbPersistence
> &#27;[0m&#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)
> &#27;[0m&#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
> &#27;[0m&#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]
> &#27;[0m&#27;[0m04:31:43,518 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA]
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,547 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 2) WFLYCLINF0003: Stopped client-mappings cache from ejb container
> &#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
> &#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000080: Disconnecting JGroups channel ejb
> &#27;[0m&#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000082: Stopping the RpcDispatcher for channel ejb
> &#27;[0m&#27;[0m04:31:43,575 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 35) AMQ151003: resource adaptor stopped
> &#27;[0m&#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow AJP listener ajp suspending
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTPS listener https suspending
> &#27;[0m&#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
> &#27;[0m&#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
> &#27;[0m&#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
[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/1/16 4:19 PM:
-------------------------------------------------------------------
Just a summary of the circumstances:
- cluster of node-0 and node-1, with SFSB SlowToDestroyStatefulIncrementorBean deployed on both nodes
- a session is created on node-0, which is the owner node
- invocations progress normally against node-0
- on node-0, the process of undeploying the deployment and shutting down the node is started
- an invocation arrives at node-0 as the deployment is undeploying
-- the EJB interceptor returns a EJBComponentUnavailable exception to the EJB client for the invocation
-- the invocation is retried on node-1
- the invocation proceeds on node-1, within a container managed transaction (CMTTxInterceptor)
- in one EJB interceptor (???? - forgot), we get the session corresponding to the session id from the ISPN cache
- a GetKeyValueCommand is invoked on node-1 and this causes an RPC to get the session from its owner on node-0
- the RPC arrives at node-0, but as the cache is in stopping mode, the exception of this issue arises
- the ISPN caller of get() receives a RemoteException
- the CMTTxInterceptor fails the invocation by rolling back and returns an exception to the client
Note that despite the fact that clean shutdown was used on node-0 with a timeout of 15 seconds, it still allows node-0 to shutdown fairly quickly, as there are probably few pending invocations at the time of shutdown which the suspend mechanism needs to wait for to complete.
Need to check:
a) when is the topology change received by node-1?
-- hard to tell, I don't see any topology change messages after node-0 stops; only after it has restarted
-- however, the JGroups view change is is visible and it is received after the exception arises
4:31:43:502 -> exception is raised
4:31:43:732 -> JGroups view change arrives
-- I assume that the reason why node-1 sends the RPC to node-0 is because it is using the latest (but out of date) topoology that it has on hand
b) Is this simply a case that it is impossible for ISPN to react to topology changes as quickly as invocations may get redirected by the EJB client (i.e. in a few ms)?
If that is the case, i'm wondering what to do in general in the case where an owner node is no longer available in the current topology (as is the case here with node-0 and the session instance it is holding) despite the fact that the current topology says it should be? Unless the numOwners=1, should it not look elsewhere for a copy of the cache entry and return that as a result of the invocation, rather than throw an exception if the owner node is not available?
was (Author: rachmato):
Just a summary of the circumstances:
- cluster of node-0 and node-1, with SFSB SlowToDestroyStatefulIncrementorBean deployed on both nodes
- a session is created on node-0, which is the owner node
- invocations progress normally against node-0
- on node-0, the process of undeploying the deployment and shutting down the node is started
- an invocation arrives at node-0 as the deployment is undeploying
-- the EJB interceptor returns a EJBComponentUnavailable exception to the EJB client for the invocation
-- the invocation is retried on node-1
- the invocation proceeds on node-1, within a container managed transaction (CMTTxInterceptor)
- in one EJB interceptor (???? - forgot), we get the session corresponding to the session id from the ISPN cache
- a GetKeyValueCommand is invoked on node-1 and this causes an RPC to get the session from its owner on node-0
- the RPC arrives at node-0, but as the cache is in stopping mode, the exception of this issue arises
- the ISPN caller of get() receives a RemoteException
- the CMTTxInterceptor fails the invocation by rolling back and returns an exception to the client
Note that despite the fact that clean shutdown was used on node-0 with a timeout of 15 seconds, it still allows node-0 to shutdown fairly quickly, as there are probably few pending invocations at the time of shutdown which the suspend mechanism needs to wait for to complete.
Need to check:
a) when is the topology change received by node-1?
-- hard to tell, I don't see any topology change messages after node-0 stops; only after it has restarted
-- however, the JGroups view change is is visible and it is received after the exception arises
4:31:43:502 -> exception is raised
4:31:43:732 -> JGroups view change arrives
-- I assume that the reason why node-1 sends the RPC to node-0 is because it is using the latest (but out of date) topoology that it has on hand
b) Is this simply a case that it is impossible for ISPN to react to topology changes as quickly as invocations may get redirected by the EJB client (i.e. in a few ms)?
If that is the case, i'm wondering what to do in general in the case where an owner node is no longer available in the current topology (as is the case here with node-0 and the session instance it is holding) despite the fact that the current topology says it should be?
> 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
> &#27;[0m04:31:43,338 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0211: Suspending server with 15000 ms timeout.
> &#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)
> &#27;[0m04:31:43,345 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown'
> &#27;[0m&#27;[0m04:31:43,430 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping
> &#27;[0m&#27;[0m04:31:43,436 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 29) MODCLUSTER000002: Initiating mod_cluster shutdown
> &#27;[0m&#27;[0m04:31:43,445 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 74) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:/ConnectionFactory
> &#27;[0m&#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000080: Disconnecting JGroups channel hibernate
> &#27;[0m&#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher for channel hibernate
> &#27;[0m&#27;[0m04:31:43,463 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000080: Disconnecting JGroups channel server
> &#27;[0m&#27;[0m04:31:43,464 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000082: Stopping the RpcDispatcher for channel server
> &#27;[0m&#27;[0m04:31:43,471 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000029: Passivating all entries to disk
> &#27;[0m&#27;[0m04:31:43,472 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000030: Passivated 2 entries in 0 milliseconds
> &#27;[0m&#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel web
> &#27;[0m&#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel web
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel testDbPersistence
> &#27;[0m&#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel testDbPersistence
> &#27;[0m&#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)
> &#27;[0m&#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
> &#27;[0m&#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]
> &#27;[0m&#27;[0m04:31:43,518 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA]
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,547 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 2) WFLYCLINF0003: Stopped client-mappings cache from ejb container
> &#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
> &#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000080: Disconnecting JGroups channel ejb
> &#27;[0m&#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000082: Stopping the RpcDispatcher for channel ejb
> &#27;[0m&#27;[0m04:31:43,575 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 35) AMQ151003: resource adaptor stopped
> &#27;[0m&#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow AJP listener ajp suspending
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTPS listener https suspending
> &#27;[0m&#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
> &#27;[0m&#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
> &#27;[0m&#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
[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/1/16 4:15 PM:
-------------------------------------------------------------------
Just a summary of the circumstances:
- cluster of node-0 and node-1, with SFSB SlowToDestroyStatefulIncrementorBean deployed on both nodes
- a session is created on node-0, which is the owner node
- invocations progress normally against node-0
- on node-0, the process of undeploying the deployment and shutting down the node is started
- an invocation arrives at node-0 as the deployment is undeploying
-- the EJB interceptor returns a EJBComponentUnavailable exception to the EJB client for the invocation
-- the invocation is retried on node-1
- the invocation proceeds on node-1, within a container managed transaction (CMTTxInterceptor)
- in one EJB interceptor (???? - forgot), we get the session corresponding to the session id from the ISPN cache
- a GetKeyValueCommand is invoked on node-1 and this causes an RPC to get the session from its owner on node-0
- the RPC arrives at node-0, but as the cache is in stopping mode, the exception of this issue arises
- the ISPN caller of get() receives a RemoteException
- the CMTTxInterceptor fails the invocation by rolling back and returns an exception to the client
Note that despite the fact that clean shutdown was used on node-0 with a timeout of 15 seconds, it still allows node-0 to shutdown fairly quickly, as there are probably few pending invocations at the time of shutdown which the suspend mechanism needs to wait for to complete.
Need to check:
a) when is the topology change received by node-1?
-- hard to tell, I don't see any topology change messages after node-0 stops; only after it has restarted
-- however, the JGroups view change is is visible and it is received after the exception arises
4:31:43:502 -> exception is raised
4:31:43:732 -> JGroups view change arrives
-- I assume that the reason why node-1 sends the RPC to node-0 is because it is using the latest (but out of date) topoology that it has on hand
b) Is this simply a case that it is impossible for ISPN to react to topology changes as quickly as invocations may get redirected by the EJB client (i.e. in a few ms)?
If that is the case, i'm wondering what to do in general in the case where an owner node is no longer available in the current topology (as is the case here with node-0 and the session instance it is holding) despite the fact that the current topology says it should be?
was (Author: rachmato):
Just a summary of the circumstances:
- cluster of node-0 and node-1, with SFSB SlowToDestroyStatefulIncrementorBean deployed on both nodes
- a session is created on node-0, which is the owner node
- invocations progress normally against node-0
- on node-0, the process of undeploying the deployment and shutting down the node is started
- an invocation arrives at node-0 as the deployment is undeploying
-- the EJB interceptor returns a EJBComponentUnavailable exception to the EJB client for the invocation
-- the invocation is retried on node-1
- the invocation proceeds on node-1, within a container managed transaction (CMTTxInterceptor)
- in one EJB interceptor (???? - forgot), we get the session corresponding to the session id from the ISPN cache
- a GetKeyValueCommand is invoked on node-1 and this causes an RPC to get the session from its owner on node-0
- the RPC arrives at node-0, but as the cache is in stopping mode, the exception of this issue arises
- the ISPN caller of get() receives a RemoteException
- the CMTTxInterceptor fails the invocation by rolling back and returns an exception to the client
Need to check:
- when is the topology change received by node-1?
- what to do in case an owner node is no longer available?
> 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
> &#27;[0m04:31:43,338 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0211: Suspending server with 15000 ms timeout.
> &#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)
> &#27;[0m04:31:43,345 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown'
> &#27;[0m&#27;[0m04:31:43,430 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping
> &#27;[0m&#27;[0m04:31:43,436 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 29) MODCLUSTER000002: Initiating mod_cluster shutdown
> &#27;[0m&#27;[0m04:31:43,445 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 74) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:/ConnectionFactory
> &#27;[0m&#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000080: Disconnecting JGroups channel hibernate
> &#27;[0m&#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher for channel hibernate
> &#27;[0m&#27;[0m04:31:43,463 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000080: Disconnecting JGroups channel server
> &#27;[0m&#27;[0m04:31:43,464 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000082: Stopping the RpcDispatcher for channel server
> &#27;[0m&#27;[0m04:31:43,471 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000029: Passivating all entries to disk
> &#27;[0m&#27;[0m04:31:43,472 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000030: Passivated 2 entries in 0 milliseconds
> &#27;[0m&#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel web
> &#27;[0m&#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel web
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel testDbPersistence
> &#27;[0m&#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel testDbPersistence
> &#27;[0m&#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)
> &#27;[0m&#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
> &#27;[0m&#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]
> &#27;[0m&#27;[0m04:31:43,518 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA]
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,547 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 2) WFLYCLINF0003: Stopped client-mappings cache from ejb container
> &#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
> &#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000080: Disconnecting JGroups channel ejb
> &#27;[0m&#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000082: Stopping the RpcDispatcher for channel ejb
> &#27;[0m&#27;[0m04:31:43,575 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 35) AMQ151003: resource adaptor stopped
> &#27;[0m&#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow AJP listener ajp suspending
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTPS listener https suspending
> &#27;[0m&#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
> &#27;[0m&#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
> &#27;[0m&#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
[JBoss JIRA] (WFCORE-952) Use WildFly Common for null param checks
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-952?page=com.atlassian.jira.plugin... ]
David Lloyd commented on WFCORE-952:
------------------------------------
This really represents about an hour or two of work at most, but it doesn't seem right to do such a broad (if shallow) change while so much else is going on. If you think it'd be fine though, I'll just whip up a PR tomorrow and close this one up.
> 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
> Priority: Minor
>
> 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
[JBoss JIRA] (WFLY-3858) Infinispan cache configuration is not always applied to security-domain
by R O (JIRA)
[ https://issues.jboss.org/browse/WFLY-3858?page=com.atlassian.jira.plugin.... ]
R O commented on WFLY-3858:
---------------------------
I guess that problem is located somewhere on subsystems level. Sometimes security subsystem starts before infinispan subsystem is ready to use.
> Infinispan cache configuration is not always applied to security-domain
> -----------------------------------------------------------------------
>
> Key: WFLY-3858
> URL: https://issues.jboss.org/browse/WFLY-3858
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 8.1.0.Final
> Reporter: Robert Tuck
> Assignee: Darran Lofthouse
> Attachments: debugger output.txt
>
>
> On Wildfly 8.1.0.Final, I have the following standalone-ha.xml:
> <subsystem xmlns="urn:jboss:domain:infinispan:2.0">
> ...
> <cache-container name="security" default-cache="auth-cache" start="EAGER">
> <transport cluster="${cluster.name}_SEC" lock-timeout="60000"/>
> <replicated-cache name="auth-cache" batching="true" mode="ASYNC">
> <eviction strategy="LRU" max-entries="10000"/>
> <expiration lifespan="60000"/>
> </replicated-cache>
> </cache-container>
> </subsystem>
> ...
> <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-domains>
> ...
> <security-domain name="OAuth-Consumer" cache-type="infinispan">
> <authentication>
> <login-module code="com.idbs.ewb.server.auth.module.OAuthConsumerLoginModule" flag="sufficient"
> module="deployment.ewb-server-ear.ear">
> <module-option name="allowedConsumerAuthFailures" value="-1"/>
> <module-option name="consumerLoginFailureTimeoutMs" value="3000"/>
> </login-module>
> </authentication>
> </security-domain>
> </security-domains>
> </subsystem>
> After startup the OAuth-Consumer security domain cache "auth-cache" is not always configured with the specified settings (~50% of the time). This can be verified by monitoring the jboss.infinispan nodes with JConsole and retrieving the cache settings, and tracking the cache hits during logins. This shows that succesful logins are cached but do not expire after the expected 60s, and that the expiration lifespan is set to -1 rather than 60000, as are eviction max entries.
> After some debugging I have narrowed down the problem to some code that gets called from inside org.jboss.as.security.plugins.JNDIBasedSecurityManagement:
> public SecurityDomainContext createSecurityDomainContext(String securityDomain, Object cacheFactory) throws Exception {
> log.debugf("Creating SDC for domain=" + securityDomain);
> AuthenticationManager am = createAuthenticationManager(securityDomain);
> // create authentication cache
> if (cacheFactory instanceof EmbeddedCacheManager) {
> EmbeddedCacheManager cacheManager = EmbeddedCacheManager.class.cast(cacheFactory);
> @SuppressWarnings("rawtypes")
> Cache cache = null;
> if (cacheManager != null) {
> // TODO override global settings with security domain specific
> ConfigurationBuilder builder = new ConfigurationBuilder();
> Configuration baseCfg = cacheManager.getCacheConfiguration("auth-cache");
> ^^^^ This call here doesn’t always return the correct configuration, baseCfg is then null.
> if (baseCfg != null) {
> builder.read(baseCfg);
> }
> cacheManager.defineConfiguration(securityDomain, builder.build());
> cache = cacheManager.getCache(securityDomain);
> }
> if (cache != null && am instanceof CacheableManager) {
> @SuppressWarnings({ "unchecked", "rawtypes" })
> CacheableManager<Map, Principal> cm = (CacheableManager<Map, Principal>) am;
> cm.setCache(cache);
> }
> } else if (cacheFactory instanceof DefaultAuthenticationCacheFactory) {
> <…>
> }
> getCacheConfiguration(String) is implemented inside org.infinispan.manager.DefaultCacheManager:
> @Override
> public Configuration getCacheConfiguration(String name) {
> Configuration configuration = configurationOverrides.get(name);
> if (configuration == null && cacheExists(name)) {
> return defaultConfiguration;
> }
> return configuration;
> }
> Seems like the condition configuration == null occurs when the cache doesn’t exist, therefore it returns null. This appears to be a race condition between this code and where it gets registered in wireAndStartCache(String).
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[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/1/16 3:53 PM:
-------------------------------------------------------------------
Just a summary of the circumstances:
- cluster of node-0 and node-1, with SFSB SlowToDestroyStatefulIncrementorBean deployed on both nodes
- a session is created on node-0, which is the owner node
- invocations progress normally against node-0
- on node-0, the process of undeploying the deployment and shutting down the node is started
- an invocation arrives at node-0 as the deployment is undeploying
-- the EJB interceptor returns a EJBComponentUnavailable exception to the EJB client for the invocation
-- the invocation is retried on node-1
- the invocation proceeds on node-1, within a container managed transaction (CMTTxInterceptor)
- in one EJB interceptor (???? - forgot), we get the session corresponding to the session id from the ISPN cache
- a GetKeyValueCommand is invoked on node-1 and this causes an RPC to get the session from its owner on node-0
- the RPC arrives at node-0, but as the cache is in stopping mode, the exception of this issue arises
- the ISPN caller of get() receives a RemoteException
- the CMTTxInterceptor fails the invocation by rolling back and returns an exception to the client
Need to check:
- when is the topology change received by node-1?
- what to do in case an owner node is no longer available?
was (Author: rachmato):
Just a summary of the circumstances:
- cluster of node-0 and node-1, with SFSB SlowToDestroyStatefulIncrementorBean deployed on both nodes
- a session is created on node-0, which is the owner node
- invocations progress normally against node-0
- on node-0, the process of undeploying the deployment and shutting down the node is started
- an invocation arrives at node-0 as the deployment is undeploying
-- the EJB interceptor returns a EJBComponentUnavailable exception to the EJB client for the invocation
-- the invocation is retried on node-1
- the invocation proceeds on node-1, within a container managed transaction (CMTTxInterceptor)
- in one EJB interceptor (???? - forgot), we get the session corresponding to the session id from the ISPN cache
- a GetKeyValueCommand is invoked on node-1 and this causes an RPC to get the session from its owner on node-0
- the RPC arrives at node-0, but as the cache is in stopping mode, the exception of this issue arises
- the ISPN caller of get() receives a RemoteException
- the CMTTxInterceptor fails the invocation and returns an exception to the client
Need to check:
- when is the topology change received by node-1?
- what to do in case an owner node is no longer available?
> 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
> &#27;[0m04:31:43,338 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0211: Suspending server with 15000 ms timeout.
> &#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)
> &#27;[0m04:31:43,345 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown'
> &#27;[0m&#27;[0m04:31:43,430 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping
> &#27;[0m&#27;[0m04:31:43,436 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 29) MODCLUSTER000002: Initiating mod_cluster shutdown
> &#27;[0m&#27;[0m04:31:43,445 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 74) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:/ConnectionFactory
> &#27;[0m&#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000080: Disconnecting JGroups channel hibernate
> &#27;[0m&#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher for channel hibernate
> &#27;[0m&#27;[0m04:31:43,463 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000080: Disconnecting JGroups channel server
> &#27;[0m&#27;[0m04:31:43,464 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000082: Stopping the RpcDispatcher for channel server
> &#27;[0m&#27;[0m04:31:43,471 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000029: Passivating all entries to disk
> &#27;[0m&#27;[0m04:31:43,472 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000030: Passivated 2 entries in 0 milliseconds
> &#27;[0m&#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel web
> &#27;[0m&#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel web
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel testDbPersistence
> &#27;[0m&#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel testDbPersistence
> &#27;[0m&#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)
> &#27;[0m&#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
> &#27;[0m&#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]
> &#27;[0m&#27;[0m04:31:43,518 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA]
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,547 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 2) WFLYCLINF0003: Stopped client-mappings cache from ejb container
> &#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
> &#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000080: Disconnecting JGroups channel ejb
> &#27;[0m&#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000082: Stopping the RpcDispatcher for channel ejb
> &#27;[0m&#27;[0m04:31:43,575 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 35) AMQ151003: resource adaptor stopped
> &#27;[0m&#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow AJP listener ajp suspending
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTPS listener https suspending
> &#27;[0m&#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
> &#27;[0m&#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
> &#27;[0m&#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
[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/1/16 3:52 PM:
-------------------------------------------------------------------
Just a summary of the circumstances:
- cluster of node-0 and node-1, with SFSB SlowToDestroyStatefulIncrementorBean deployed on both nodes
- a session is created on node-0, which is the owner node
- invocations progress normally against node-0
- on node-0, the process of undeploying the deployment and shutting down the node is started
- an invocation arrives at node-0 as the deployment is undeploying
-- the EJB interceptor returns a EJBComponentUnavailable exception to the EJB client for the invocation
-- the invocation is retried on node-1
- the invocation proceeds on node-1, within a container managed transaction (CMTTxInterceptor)
- in one EJB interceptor (???? - forgot), we get the session corresponding to the session id from the ISPN cache
- a GetKeyValueCommand is invoked on node-1 and this causes an RPC to get the session from its owner on node-0
- the RPC arrives at node-0, but as the cache is in stopping mode, the exception of this issue arises
- the ISPN caller of get() receives a RemoteException
- the CMTTxInterceptor fails the invocation and returns an exception to the client
Need to check:
- when is the topology change received by node-1?
- what to do in case an owner node is no longer available?
was (Author: rachmato):
Just a summary of the circumstances:
- cluster of node-0 and node-1, with SFSB SlowToDestroyStatefulIncrementorBean deployed on both nodes
- a session is created on node-0, which is the owner node
- invocations progress normally against node-0
- on node-0, the process of undeploying the deployment and shutting down the node is started
- an invocation arrives at node-0 as the deployment is undeploying
-- the EJB interceptor returns a EJBComponentUnavailable exception to the EJB client for invocation Y
-- the invocation is retried on node-1
- the invocation proceeds on node-1, within a container managed transaction (CMTTxInterceptor)
- in one EJB interceptor (???? - forgot), we get the session corresponding to the session id from the ISPN cache
- a GetKeyValueCommand is invoked on node-1 and this causes an RPC to get the session from its owner on node-0
- the RPC arrives at node-0, but as the cache is in stopping mode, the exception of this issue arises
- the ISPN caller of get() receives a RemoteException
- the CMTTxInterceptor fails the invocation and returns an exception to the client
Need to check:
- when is the topology change received by node-1?
- what to do in case an owner node is no longer available?
> 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
> &#27;[0m04:31:43,338 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0211: Suspending server with 15000 ms timeout.
> &#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)
> &#27;[0m04:31:43,345 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown'
> &#27;[0m&#27;[0m04:31:43,430 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping
> &#27;[0m&#27;[0m04:31:43,436 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 29) MODCLUSTER000002: Initiating mod_cluster shutdown
> &#27;[0m&#27;[0m04:31:43,445 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 74) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:/ConnectionFactory
> &#27;[0m&#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000080: Disconnecting JGroups channel hibernate
> &#27;[0m&#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher for channel hibernate
> &#27;[0m&#27;[0m04:31:43,463 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000080: Disconnecting JGroups channel server
> &#27;[0m&#27;[0m04:31:43,464 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000082: Stopping the RpcDispatcher for channel server
> &#27;[0m&#27;[0m04:31:43,471 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000029: Passivating all entries to disk
> &#27;[0m&#27;[0m04:31:43,472 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000030: Passivated 2 entries in 0 milliseconds
> &#27;[0m&#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel web
> &#27;[0m&#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel web
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel testDbPersistence
> &#27;[0m&#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel testDbPersistence
> &#27;[0m&#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)
> &#27;[0m&#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
> &#27;[0m&#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]
> &#27;[0m&#27;[0m04:31:43,518 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA]
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,547 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 2) WFLYCLINF0003: Stopped client-mappings cache from ejb container
> &#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
> &#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000080: Disconnecting JGroups channel ejb
> &#27;[0m&#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000082: Stopping the RpcDispatcher for channel ejb
> &#27;[0m&#27;[0m04:31:43,575 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 35) AMQ151003: resource adaptor stopped
> &#27;[0m&#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow AJP listener ajp suspending
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTPS listener https suspending
> &#27;[0m&#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
> &#27;[0m&#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
> &#27;[0m&#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
[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/1/16 3:51 PM:
-------------------------------------------------------------------
Just a summary of the circumstances:
- cluster of node-0 and node-1, with SFSB SlowToDestroyStatefulIncrementorBean deployed on both nodes
- a session is created on node-0, which is the owner node
- invocations progress normally against node-0
- on node-0, the process of undeploying the deployment and shutting down the node is started
- an invocation arrives at node-0 as the deployment is undeploying
-- the EJB interceptor returns a EJBComponentUnavailable exception to the EJB client for invocation Y
-- the invocation is retried on node-1
- the invocation proceeds on node-1, within a container managed transaction (CMTTxInterceptor)
- in one EJB interceptor (???? - forgot), we get the session corresponding to the session id from the ISPN cache
- a GetKeyValueCommand is invoked on node-1 and this causes an RPC to get the session from its owner on node-0
- the RPC arrives at node-0, but as the cache is in stopping mode, the exception of this issue arises
- the ISPN caller of get() receives a RemoteException
- the CMTTxInterceptor fails the invocation and returns an exception to the client
Need to check:
- when is the topology change received by node-1?
- what to do in case an owner node is no longer available?
was (Author: rachmato):
Just a summary of the circumstances:
- cluster of node-0 and node-1, with SFSB SlowToDestroyStatefulIncrementorBean deployed on both nodes
- a session is created on node-0, which is the owner node of the session id
- invocations progress normally against node-0
- on node-0, the process of undeploying the deployment and shutting down the node is started
- an invocation arrives at node-0 as the deployment is undeploying
-- the EJB interceptor returns a EJBComponentUnavailable exception to the EJB client for invocation Y
-- the invocation is retried on node-1
- the invocation proceeds on node-1, within a container managed transaction (CMTTxInterceptor)
- in one EJB interceptor (???? - forgot), we get the session corresponding to the session id from the ISPN cache
- a GetKeyValueCommand is invoked on node-1 and this causes an RPC to get the session from its owner on node-0
- the RPC arrives at node-0, but as the cache is in stopping mode, the exception of this issue arises
- the ISPN caller of get() receives a RemoteException
- the CMTTxInterceptor fails the invocation and returns an exception to the client
Need to check:
- when is the topology change received by node-1?
- what to do in case an owner node is no longer available?
> 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
> &#27;[0m04:31:43,338 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0211: Suspending server with 15000 ms timeout.
> &#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)
> &#27;[0m04:31:43,345 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown'
> &#27;[0m&#27;[0m04:31:43,430 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping
> &#27;[0m&#27;[0m04:31:43,436 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 29) MODCLUSTER000002: Initiating mod_cluster shutdown
> &#27;[0m&#27;[0m04:31:43,445 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 74) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:/ConnectionFactory
> &#27;[0m&#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000080: Disconnecting JGroups channel hibernate
> &#27;[0m&#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher for channel hibernate
> &#27;[0m&#27;[0m04:31:43,463 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000080: Disconnecting JGroups channel server
> &#27;[0m&#27;[0m04:31:43,464 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000082: Stopping the RpcDispatcher for channel server
> &#27;[0m&#27;[0m04:31:43,471 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000029: Passivating all entries to disk
> &#27;[0m&#27;[0m04:31:43,472 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000030: Passivated 2 entries in 0 milliseconds
> &#27;[0m&#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel web
> &#27;[0m&#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel web
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel testDbPersistence
> &#27;[0m&#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel testDbPersistence
> &#27;[0m&#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)
> &#27;[0m&#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
> &#27;[0m&#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]
> &#27;[0m&#27;[0m04:31:43,518 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA]
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,547 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 2) WFLYCLINF0003: Stopped client-mappings cache from ejb container
> &#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
> &#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000080: Disconnecting JGroups channel ejb
> &#27;[0m&#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000082: Stopping the RpcDispatcher for channel ejb
> &#27;[0m&#27;[0m04:31:43,575 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 35) AMQ151003: resource adaptor stopped
> &#27;[0m&#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow AJP listener ajp suspending
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTPS listener https suspending
> &#27;[0m&#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
> &#27;[0m&#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
> &#27;[0m&#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
[JBoss JIRA] (WFLY-6596) WrongClassException when using infinispan as remote-store for hibernate entity cache
by Gunther v. Wolffersdorff (JIRA)
[ https://issues.jboss.org/browse/WFLY-6596?page=com.atlassian.jira.plugin.... ]
Gunther v. Wolffersdorff edited comment on WFLY-6596 at 9/1/16 3:41 PM:
------------------------------------------------------------------------
sample-10.1.0.Final-2.zip added :reduced data (import.sql)
was (Author: gvwolf3d):
reduced data (import.sql)
> WrongClassException when using infinispan as remote-store for hibernate entity cache
> ------------------------------------------------------------------------------------
>
> Key: WFLY-6596
> URL: https://issues.jboss.org/browse/WFLY-6596
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Java version: 1.8.0_45, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_45\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos"
> Infifnspan 8.1.2 or 8.2.0
> Reporter: Gunther v. Wolffersdorff
> Assignee: Scott Marlow
> Labels: inifinispan-commons, org.hibernate.WrongClassException, remote-store
> Attachments: clustered.sample.xml, infinispan.zip, sample-10.1.0.Final-2.zip, sample-10.1.0.Final.zip, sample.zip, standalone.sample.ha-10.1.0.Final.xml, standalone.sample.ha.xml
>
>
> Starting an application and then requesting a list of cachable JPA entitties ( configured cachable using a hibernate entity invalidation-cache with a remote-server as remote-store ) causes:
> {code}
> 13:00:52,541 MESZ ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /sample-web/rest/members/listAll: org.jboss.resteasy.spi.UnhandledException: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
> Caused by: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:492) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.criteria.compile.CriteriaQueryTypeQueryAdapter.getResultList(CriteriaQueryTypeQueryAdapter.java:50) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.jboss.as.jpa.container.TypedQueryNonTxInvocationDetacher.getResultList(TypedQueryNonTxInvocationDetacher.java:58) [wildfly-jpa-10.1.0.Final.jar:10.1.0.Final]
> at de.alvara.ticket.sample.data.MemberRepository.findAllOrderedByName(MemberRepository.java:58) [sample-ejb.jar:]
> at de.alvara.ticket.sample.data.MemberRepository$Proxy$_$$_WeldClientProxy.findAllOrderedByName(Unknown Source) [sample-ejb.jar:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService.listAllMembers(MemberResourceRESTService.java:75) [classes:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService$Proxy$_$$_WeldClientProxy.listAllMembers(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_66]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_66]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_66]
> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_66]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> ... 43 more
> Caused by: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.event.internal.DefaultLoadEventListener.processCachedEntry(DefaultLoadEventListener.java:631) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:602) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:462) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.internalLoad(SessionImpl.java:1022) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:632) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolve(EntityType.java:424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:154) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:128) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1133) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.processResultSet(Loader.java:992) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQuery(Loader.java:930) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:336) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2617) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2600) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2429) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.list(Loader.java:2424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:501) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:371) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1326) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> ... 58 more
> {code}
> Entity cache is configured like this:
> {code:xml}
> ...
> <invalidation-cache name="entity" mode="SYNC">
> <eviction strategy="LRU" max-entries="1000"/>
> <expiration lifespan="45000" max-idle="30000"/>
> <remote-store cache="hibernateDistributed" socket-timeout="60000" tcp-no-delay="true" remote-servers="local-cache-server" fetch-state="false" passivation="false" preload="false" purge="true" shared="true"/>
> </invalidation-cache>
> ...
> <outbound-socket-binding name="local-cache-server">
> <remote-destination host="${jboss.bind.address:127.0.0.1}" port="11322"/>
> </outbound-socket-binding>
> ...
> {code}
> see standalone.sample.ha-10.1.0.Final.xml .
> *This constellation works fine using Wildfly 8.2.0 and Infinispan 7.2.5 .*
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6596) WrongClassException when using infinispan as remote-store for hibernate entity cache
by Gunther v. Wolffersdorff (JIRA)
[ https://issues.jboss.org/browse/WFLY-6596?page=com.atlassian.jira.plugin.... ]
Gunther v. Wolffersdorff edited comment on WFLY-6596 at 9/1/16 3:38 PM:
------------------------------------------------------------------------
I don't think so. We are running a big application hitting this bug in Wildly 10.0.0.Final. So I created a little sample
application just for bug reporting. Our application (and the sample application) runs fine using Wildly 8.2.0 and Infinispan 7.2.5 for months.
I digged a little bit deeper and stripped the data loaded by the sample application a bit (new sample-10.1.0.Final-2.zip with smaller import.sql file).
So the simple class model is a follows:
{code}
+----------------+
| Country |
+----------------+
| id : long |
| name : string |
| iso : string |
+----------------+
| 1
|
|
| 0..*
+----------------------+
| Member |
+----------------------+
| id : long |
| name : string |
| email : string |
| phoneNumber : string |
| country ; Country |
+----------------------+
{code}
Both classes are @Cacheable .
The tables are populated by import.sql as shown below:
{code:sql}
insert into Country(id, name, iso) values (100, 'Deutschland', 'DE')
insert into Country(id, name, iso) values (102, 'Espana', 'ES')
insert into Member(id, name, email, phone_number, country_id) values (100, 'John Smith', 'john.smith(a)mailinator.com', '2125551212', 102 )
insert into Member(id, name, email, phone_number, country_id) values (110, 'Ed Moos', 'ed.moos(a)mailinator.com', '212500', 100 )
{code}
As you can see we have two countries (id=100 and id=102). Also we have a member id=100 referencing country id=102 . And we have a second member id=110 referencing country 100;
The Hibernate entity cache has a remote-store.
We can now query all members order by id:
{code}
curl http://localhost:2680/sample-web/rest/members/listAllOrderedByIdAsc
{code}
So hibernate fetches at first member (id=100). When hibernate will fetch the second member (id=110). This member references country (id=100). But instead to fetch this country hibernate gets member (id=100) from cache.
This results in Object [id=100] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member .(I changed the data a bit so we have new id's here)
If we remove the remote-store configuration from the cache-container configuration (<invalidation-cache name="entity">) everything runs fine.
Also if we query the members in the reverse order no error occurs:
{code}
curl http://localhost:2680/sample-web/rest/members/listAllOrderedByIdDesc
{code}
This makes sense because no country is in cache having the same id as an already known (fetched) member.
was (Author: gvwolf3d):
I don't think so. We are running a big application hitting this bug in Wildly 10.0.0.Final. So I created a little sample
application just for bug reporting. Our application (and the sample application) runs fine using Wildly 8.2.0 and Infinispan 7.2.5 for months.
I digged a little bit deeper and stripped the data loaded by the sample application a bit (new sample-10.1.0.Final-2.zip with smaller import.sql file).
So the simple class model is a follows:
{code}
+----------------+
| Country |
+----------------+
| id : long |
| name : string |
| iso : string |
+----------------+
| 1
|
|
| 0..*
+----------------------+
| Member |
+----------------------+
| id : long |
| name : string |
| email : string |
| phoneNumber : string |
| country ; Country |
+----------------------+
{code}
Both classes are @Cacheable .
The table are populated by import.sql as shown below:
{code:sql}
insert into Country(id, name, iso) values (100, 'Deutschland', 'DE')
insert into Country(id, name, iso) values (102, 'Espana', 'ES')
insert into Member(id, name, email, phone_number, country_id) values (100, 'John Smith', 'john.smith(a)mailinator.com', '2125551212', 102 )
insert into Member(id, name, email, phone_number, country_id) values (110, 'Ed Moos', 'ed.moos(a)mailinator.com', '212500', 100 )
{code}
As you can see we have two countries (id=100 and id=102). Also we have a member id=100 referencing country id=102 . And we have a second member id=110 referencing country 100;
The Hibernate entity cache has a remote-store.
We can now query all members order by id:
{code}
curl http://localhost:2680/sample-web/rest/members/listAllOrderedByIdAsc
{code}
So hibernate fetches at first member (id=100). When hibernate will fetch the second member (id=110). This member references country (id=100). But instead to fetch this country hibernate gets member (id=100) from cache.
This results in Object [id=100] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member .(I changed the data a bit so we have new id's here)
If we remove the remote-store configuration from the cache-container configuration (<invalidation-cache name="entity">) everything runs fine.
Also if we query the members in the reverse order no error occurs:
{code}
curl http://localhost:2680/sample-web/rest/members/listAllOrderedByIdDesc
{code}
This makes sense because no country is in cache having the same id as an already known (fetched) member.
> WrongClassException when using infinispan as remote-store for hibernate entity cache
> ------------------------------------------------------------------------------------
>
> Key: WFLY-6596
> URL: https://issues.jboss.org/browse/WFLY-6596
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Java version: 1.8.0_45, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_45\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos"
> Infifnspan 8.1.2 or 8.2.0
> Reporter: Gunther v. Wolffersdorff
> Assignee: Scott Marlow
> Labels: inifinispan-commons, org.hibernate.WrongClassException, remote-store
> Attachments: clustered.sample.xml, infinispan.zip, sample-10.1.0.Final-2.zip, sample-10.1.0.Final.zip, sample.zip, standalone.sample.ha-10.1.0.Final.xml, standalone.sample.ha.xml
>
>
> Starting an application and then requesting a list of cachable JPA entitties ( configured cachable using a hibernate entity invalidation-cache with a remote-server as remote-store ) causes:
> {code}
> 13:00:52,541 MESZ ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /sample-web/rest/members/listAll: org.jboss.resteasy.spi.UnhandledException: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
> Caused by: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:492) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.criteria.compile.CriteriaQueryTypeQueryAdapter.getResultList(CriteriaQueryTypeQueryAdapter.java:50) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.jboss.as.jpa.container.TypedQueryNonTxInvocationDetacher.getResultList(TypedQueryNonTxInvocationDetacher.java:58) [wildfly-jpa-10.1.0.Final.jar:10.1.0.Final]
> at de.alvara.ticket.sample.data.MemberRepository.findAllOrderedByName(MemberRepository.java:58) [sample-ejb.jar:]
> at de.alvara.ticket.sample.data.MemberRepository$Proxy$_$$_WeldClientProxy.findAllOrderedByName(Unknown Source) [sample-ejb.jar:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService.listAllMembers(MemberResourceRESTService.java:75) [classes:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService$Proxy$_$$_WeldClientProxy.listAllMembers(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_66]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_66]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_66]
> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_66]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> ... 43 more
> Caused by: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.event.internal.DefaultLoadEventListener.processCachedEntry(DefaultLoadEventListener.java:631) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:602) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:462) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.internalLoad(SessionImpl.java:1022) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:632) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolve(EntityType.java:424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:154) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:128) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1133) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.processResultSet(Loader.java:992) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQuery(Loader.java:930) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:336) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2617) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2600) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2429) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.list(Loader.java:2424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:501) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:371) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1326) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> ... 58 more
> {code}
> Entity cache is configured like this:
> {code:xml}
> ...
> <invalidation-cache name="entity" mode="SYNC">
> <eviction strategy="LRU" max-entries="1000"/>
> <expiration lifespan="45000" max-idle="30000"/>
> <remote-store cache="hibernateDistributed" socket-timeout="60000" tcp-no-delay="true" remote-servers="local-cache-server" fetch-state="false" passivation="false" preload="false" purge="true" shared="true"/>
> </invalidation-cache>
> ...
> <outbound-socket-binding name="local-cache-server">
> <remote-destination host="${jboss.bind.address:127.0.0.1}" port="11322"/>
> </outbound-socket-binding>
> ...
> {code}
> see standalone.sample.ha-10.1.0.Final.xml .
> *This constellation works fine using Wildfly 8.2.0 and Infinispan 7.2.5 .*
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6596) WrongClassException when using infinispan as remote-store for hibernate entity cache
by Gunther v. Wolffersdorff (JIRA)
[ https://issues.jboss.org/browse/WFLY-6596?page=com.atlassian.jira.plugin.... ]
Gunther v. Wolffersdorff updated WFLY-6596:
-------------------------------------------
Attachment: sample-10.1.0.Final-2.zip
reduced data (import.sql)
> WrongClassException when using infinispan as remote-store for hibernate entity cache
> ------------------------------------------------------------------------------------
>
> Key: WFLY-6596
> URL: https://issues.jboss.org/browse/WFLY-6596
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Java version: 1.8.0_45, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_45\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos"
> Infifnspan 8.1.2 or 8.2.0
> Reporter: Gunther v. Wolffersdorff
> Assignee: Scott Marlow
> Labels: inifinispan-commons, org.hibernate.WrongClassException, remote-store
> Attachments: clustered.sample.xml, infinispan.zip, sample-10.1.0.Final-2.zip, sample-10.1.0.Final.zip, sample.zip, standalone.sample.ha-10.1.0.Final.xml, standalone.sample.ha.xml
>
>
> Starting an application and then requesting a list of cachable JPA entitties ( configured cachable using a hibernate entity invalidation-cache with a remote-server as remote-store ) causes:
> {code}
> 13:00:52,541 MESZ ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /sample-web/rest/members/listAll: org.jboss.resteasy.spi.UnhandledException: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
> Caused by: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:492) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.criteria.compile.CriteriaQueryTypeQueryAdapter.getResultList(CriteriaQueryTypeQueryAdapter.java:50) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.jboss.as.jpa.container.TypedQueryNonTxInvocationDetacher.getResultList(TypedQueryNonTxInvocationDetacher.java:58) [wildfly-jpa-10.1.0.Final.jar:10.1.0.Final]
> at de.alvara.ticket.sample.data.MemberRepository.findAllOrderedByName(MemberRepository.java:58) [sample-ejb.jar:]
> at de.alvara.ticket.sample.data.MemberRepository$Proxy$_$$_WeldClientProxy.findAllOrderedByName(Unknown Source) [sample-ejb.jar:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService.listAllMembers(MemberResourceRESTService.java:75) [classes:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService$Proxy$_$$_WeldClientProxy.listAllMembers(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_66]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_66]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_66]
> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_66]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> ... 43 more
> Caused by: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.event.internal.DefaultLoadEventListener.processCachedEntry(DefaultLoadEventListener.java:631) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:602) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:462) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.internalLoad(SessionImpl.java:1022) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:632) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolve(EntityType.java:424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:154) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:128) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1133) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.processResultSet(Loader.java:992) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQuery(Loader.java:930) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:336) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2617) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2600) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2429) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.list(Loader.java:2424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:501) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:371) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1326) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> ... 58 more
> {code}
> Entity cache is configured like this:
> {code:xml}
> ...
> <invalidation-cache name="entity" mode="SYNC">
> <eviction strategy="LRU" max-entries="1000"/>
> <expiration lifespan="45000" max-idle="30000"/>
> <remote-store cache="hibernateDistributed" socket-timeout="60000" tcp-no-delay="true" remote-servers="local-cache-server" fetch-state="false" passivation="false" preload="false" purge="true" shared="true"/>
> </invalidation-cache>
> ...
> <outbound-socket-binding name="local-cache-server">
> <remote-destination host="${jboss.bind.address:127.0.0.1}" port="11322"/>
> </outbound-socket-binding>
> ...
> {code}
> see standalone.sample.ha-10.1.0.Final.xml .
> *This constellation works fine using Wildfly 8.2.0 and Infinispan 7.2.5 .*
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6596) WrongClassException when using infinispan as remote-store for hibernate entity cache
by Gunther v. Wolffersdorff (JIRA)
[ https://issues.jboss.org/browse/WFLY-6596?page=com.atlassian.jira.plugin.... ]
Gunther v. Wolffersdorff commented on WFLY-6596:
------------------------------------------------
I don't think so. We are running a big application hitting this bug in Wildly 10.0.0.Final. So I created a little sample
application just for bug reporting. Our application (and the sample application) runs fine using Wildly 8.2.0 and Infinispan 7.2.5 for months.
I digged a little bit deeper and stripped the data loaded by the sample application a bit (new sample-10.1.0.Final-2.zip with smaller import.sql file).
So the simple class model is a follows:
{code}
+----------------+
| Country |
+----------------+
| id : long |
| name : string |
| iso : string |
+----------------+
| 1
|
|
| 0..*
+----------------------+
| Member |
+----------------------+
| id : long |
| name : string |
| email : string |
| phoneNumber : string |
| country ; Country |
+----------------------+
{code}
Both classes are @Cacheable .
The table are populated by import.sql as shown below:
{code:sql}
insert into Country(id, name, iso) values (100, 'Deutschland', 'DE')
insert into Country(id, name, iso) values (102, 'Espana', 'ES')
insert into Member(id, name, email, phone_number, country_id) values (100, 'John Smith', 'john.smith(a)mailinator.com', '2125551212', 102 )
insert into Member(id, name, email, phone_number, country_id) values (110, 'Ed Moos', 'ed.moos(a)mailinator.com', '212500', 100 )
{code}
As you can see we have two countries (id=100 and id=102). Also we have a member id=100 referencing country id=102 . And we have a second member id=110 referencing country 100;
The Hibernate entity cache has a remote-store.
We can now query all members order by id:
{code}
curl http://localhost:2680/sample-web/rest/members/listAllOrderedByIdAsc
{code}
So hibernate fetches at first member (id=100). When hibernate will fetch the second member (id=110). This member references country (id=100). But instead to fetch this country hibernate gets member (id=100) from cache.
This results in Object [id=100] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member .(I changed the data a bit so we have new id's here)
If we remove the remote-store configuration from the cache-container configuration (<invalidation-cache name="entity">) everything runs fine.
Also if we query the members in the reverse order no error occurs:
{code}
curl http://localhost:2680/sample-web/rest/members/listAllOrderedByIdDesc
{code}
This makes sense because no country is in cache having the same id as an already known (fetched) member.
> WrongClassException when using infinispan as remote-store for hibernate entity cache
> ------------------------------------------------------------------------------------
>
> Key: WFLY-6596
> URL: https://issues.jboss.org/browse/WFLY-6596
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Java version: 1.8.0_45, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_45\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos"
> Infifnspan 8.1.2 or 8.2.0
> Reporter: Gunther v. Wolffersdorff
> Assignee: Scott Marlow
> Labels: inifinispan-commons, org.hibernate.WrongClassException, remote-store
> Attachments: clustered.sample.xml, infinispan.zip, sample-10.1.0.Final.zip, sample.zip, standalone.sample.ha-10.1.0.Final.xml, standalone.sample.ha.xml
>
>
> Starting an application and then requesting a list of cachable JPA entitties ( configured cachable using a hibernate entity invalidation-cache with a remote-server as remote-store ) causes:
> {code}
> 13:00:52,541 MESZ ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /sample-web/rest/members/listAll: org.jboss.resteasy.spi.UnhandledException: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
> Caused by: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:492) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.criteria.compile.CriteriaQueryTypeQueryAdapter.getResultList(CriteriaQueryTypeQueryAdapter.java:50) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.jboss.as.jpa.container.TypedQueryNonTxInvocationDetacher.getResultList(TypedQueryNonTxInvocationDetacher.java:58) [wildfly-jpa-10.1.0.Final.jar:10.1.0.Final]
> at de.alvara.ticket.sample.data.MemberRepository.findAllOrderedByName(MemberRepository.java:58) [sample-ejb.jar:]
> at de.alvara.ticket.sample.data.MemberRepository$Proxy$_$$_WeldClientProxy.findAllOrderedByName(Unknown Source) [sample-ejb.jar:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService.listAllMembers(MemberResourceRESTService.java:75) [classes:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService$Proxy$_$$_WeldClientProxy.listAllMembers(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_66]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_66]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_66]
> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_66]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> ... 43 more
> Caused by: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.event.internal.DefaultLoadEventListener.processCachedEntry(DefaultLoadEventListener.java:631) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:602) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:462) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.internalLoad(SessionImpl.java:1022) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:632) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolve(EntityType.java:424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:154) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:128) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1133) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.processResultSet(Loader.java:992) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQuery(Loader.java:930) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:336) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2617) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2600) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2429) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.list(Loader.java:2424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:501) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:371) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1326) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> ... 58 more
> {code}
> Entity cache is configured like this:
> {code:xml}
> ...
> <invalidation-cache name="entity" mode="SYNC">
> <eviction strategy="LRU" max-entries="1000"/>
> <expiration lifespan="45000" max-idle="30000"/>
> <remote-store cache="hibernateDistributed" socket-timeout="60000" tcp-no-delay="true" remote-servers="local-cache-server" fetch-state="false" passivation="false" preload="false" purge="true" shared="true"/>
> </invalidation-cache>
> ...
> <outbound-socket-binding name="local-cache-server">
> <remote-destination host="${jboss.bind.address:127.0.0.1}" port="11322"/>
> </outbound-socket-binding>
> ...
> {code}
> see standalone.sample.ha-10.1.0.Final.xml .
> *This constellation works fine using Wildfly 8.2.0 and Infinispan 7.2.5 .*
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[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:
-------------------------------------------
Just a summary of the circumstances:
- cluster of node-0 and node-1, with SFSB SlowToDestroyStatefulIncrementorBean deployed on both nodes
- a session is created on node-0, which is the owner node of the session id
- invocations progress normally against node-0
- on node-0, the process of undeploying the deployment and shutting down the node is started
- an invocation arrives at node-0 as the deployment is undeploying
-- the EJB interceptor returns a EJBComponentUnavailable exception to the EJB client for invocation Y
-- the invocation is retried on node-1
- the invocation proceeds on node-1, within a container managed transaction (CMTTxInterceptor)
- in one EJB interceptor (???? - forgot), we get the session corresponding to the session id from the ISPN cache
- a GetKeyValueCommand is invoked on node-1 and this causes an RPC to get the session from its owner on node-0
- the RPC arrives at node-0, but as the cache is in stopping mode, the exception of this issue arises
- the ISPN caller of get() receives a RemoteException
- the CMTTxInterceptor fails the invocation and returns an exception to the client
Need to check:
- when is the topology change received by node-1?
- what to do in case an owner node is no longer available?
> 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
> &#27;[0m04:31:43,338 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0211: Suspending server with 15000 ms timeout.
> &#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)
> &#27;[0m04:31:43,345 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown'
> &#27;[0m&#27;[0m04:31:43,430 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping
> &#27;[0m&#27;[0m04:31:43,436 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 29) MODCLUSTER000002: Initiating mod_cluster shutdown
> &#27;[0m&#27;[0m04:31:43,445 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 74) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:/ConnectionFactory
> &#27;[0m&#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000080: Disconnecting JGroups channel hibernate
> &#27;[0m&#27;[0m04:31:43,459 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher for channel hibernate
> &#27;[0m&#27;[0m04:31:43,463 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000080: Disconnecting JGroups channel server
> &#27;[0m&#27;[0m04:31:43,464 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000082: Stopping the RpcDispatcher for channel server
> &#27;[0m&#27;[0m04:31:43,471 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000029: Passivating all entries to disk
> &#27;[0m&#27;[0m04:31:43,472 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000030: Passivated 2 entries in 0 milliseconds
> &#27;[0m&#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel web
> &#27;[0m&#27;[0m04:31:43,501 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel web
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel testDbPersistence
> &#27;[0m&#27;[0m04:31:43,505 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher for channel testDbPersistence
> &#27;[0m&#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)
> &#27;[0m&#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
> &#27;[0m&#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]
> &#27;[0m&#27;[0m04:31:43,518 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA]
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,547 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 2) WFLYCLINF0003: Stopped client-mappings cache from ejb container
> &#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
> &#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000080: Disconnecting JGroups channel ejb
> &#27;[0m&#27;[0m04:31:43,576 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000082: Stopping the RpcDispatcher for channel ejb
> &#27;[0m&#27;[0m04:31:43,575 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 35) AMQ151003: resource adaptor stopped
> &#27;[0m&#27;[0m04:31:43,591 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow AJP listener ajp suspending
> &#27;[0m&#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
> &#27;[0m&#27;[0m04:31:43,592 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTPS listener https suspending
> &#27;[0m&#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
> &#27;[0m&#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
> &#27;[0m&#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
[JBoss JIRA] (WFCORE-234) Inconsistent synchronization in ConfigurationFile
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-234?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-234:
------------------------------------
Fix Version/s: 3.0.0.Alpha8
(was: 3.0.0.Alpha7)
> Inconsistent synchronization in ConfigurationFile
> -------------------------------------------------
>
> Key: WFCORE-234
> URL: https://issues.jboss.org/browse/WFCORE-234
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha11
> Reporter: Brian Stansberry
> Fix For: 3.0.0.Alpha8
>
>
> ConfigurationFile synchronizes on itself in some places and not in others. This may cause problems, particularly with the history dir.
> The one that comes to mind is successfulBoot is synchronized, but all the methods called by ConfigurationFilePersistenceResource are not. The latter is called with the controller lock held, but the former is not. So there's a possibility of two threads interacting with the files concurrently if an operation executes immediately after boot.
> The deployment scanner schedules such an op, so it's possible. Currently the schedule is for 200 ms after deployment-scanner add runs during boot.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-13) End users can call non-published management API operations
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-13?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFCORE-13:
-----------------------------------
Fix Version/s: 3.0.0.Alpha8
(was: 3.0.0.Alpha7)
> End users can call non-published management API operations
> ----------------------------------------------------------
>
> Key: WFCORE-13
> URL: https://issues.jboss.org/browse/WFCORE-13
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Ladislav Thon
> Labels: EAP
> Fix For: 3.0.0.Alpha8
>
>
> It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces.
> The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen.
> What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized.
> I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-301) Configuration of individual contexts for http management interface.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-301?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-301:
------------------------------------
Fix Version/s: 3.0.0.Alpha8
(was: 3.0.0.Alpha7)
> Configuration of individual contexts for http management interface.
> -------------------------------------------------------------------
>
> Key: WFCORE-301
> URL: https://issues.jboss.org/browse/WFCORE-301
> Project: WildFly Core
> Issue Type: Sub-task
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: affects_elytron
> Fix For: 3.0.0.Alpha8
>
>
> At the moment all management requests are handled over the '/management' context, we also have a '/console' context to serve up the files for the admin console.
> The '/management' context is secured using standard HTTP mechanisms, this decision was taken so that clients could be written in different languages and all they would need to know is how to use standard authentication mechanisms. Due to problems where web browsers could run malicious scripts cross origin resource sharing is completely disabled for this context.
> We need to start to open up the handling of cross origin requests for a couple of reasons: -
> - Enabling Keycloak SSO support.
> - Alternative console distribution options
> The '/management' context is going to be retained as-is for legacy clients, possibly even switched off by default.
> A new context can then be added using non-browser based authentication, this could be SSO Keycloak or could be a form of Digest authentication where the response is handled by the console and not the web browser - either way as the browser is bypassed it is no longer at risk of sending malicious cross origin requests.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-610) Integrate Elytron for management security.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-610?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-610:
------------------------------------
Fix Version/s: 3.0.0.Alpha8
(was: 3.0.0.Alpha7)
> Integrate Elytron for management security.
> ------------------------------------------
>
> Key: WFCORE-610
> URL: https://issues.jboss.org/browse/WFCORE-610
> Project: WildFly Core
> Issue Type: Sub-task
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Alpha8
>
>
> This is a top level container task for the integration of Elytron for domain management security.
> Do note however that the purpose of Elytron is a single unified security solution across the whole of the application server so many tasks here will be groundwork for the remainder of the integration.
> At the moment the Elytron subsystem is being developed outside of wildfly-core, this will need to change in the future due to dependency issues (i.e. to write a subsystem you need to depend on core and core will need to include the subsystem (I think.)). However this will make it easier for now to ensure that the subsystem is 100% with no WildFly code accessing the subsystem - and also verify that we can create a distribtion with out the subsystem and still have a functional server.
> Overall if someone came up with an alternative subsystem that provided the same capabilities it should be possible to drop it in.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-363) ManagementResourceRegistration.getOverrideModel never returns null
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-363?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-363:
------------------------------------
Fix Version/s: 3.0.0.Alpha8
(was: 3.0.0.Alpha7)
> ManagementResourceRegistration.getOverrideModel never returns null
> ------------------------------------------------------------------
>
> Key: WFCORE-363
> URL: https://issues.jboss.org/browse/WFCORE-363
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 3.0.0.Alpha8
>
>
> ManagementResourceRegistration.getOverrideModel ends up returning the wildcard registration if there is no override registration. This isn't correct.
> The fix isn't trivial because fixing it results in nasty failures in the smoke tests. From looking at the uses of this method (which all involve a null check) I assume there are some bugs in the code that calls this method that get exposed once it does what it should.
> This bug is the cause of the initial failure of my WFLY-2880 fix.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-311) Better error message if authentication is required to connect to the master but no realm is associated on the slave
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-311?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-311:
------------------------------------
Fix Version/s: 3.0.0.Alpha8
(was: 3.0.0.Alpha7)
> Better error message if authentication is required to connect to the master but no realm is associated on the slave
> -------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-311
> URL: https://issues.jboss.org/browse/WFCORE-311
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Environment: RH EL 6.3 - JBoss EAP 6.2
> Reporter: Riccardo Benvenuti
> Assignee: Brian Stansberry
> Priority: Minor
> Fix For: 3.0.0.Alpha8
>
>
> In JBoss 6.2 domain environment if in the host.xml file on the slave is missing the realm in the domain-controller tag as reported below
> <domain-controller>
> <remote host="10.123.137.200" port="9999"/>
> </domain-controller>
> we get the following error:
> JBoss Bootstrap Environment
> JBOSS_HOME: /opt/jboss7/jboss-eap-6.2
> JAVA: /usr/java/jdk1.7.0_51/bin/java
> JAVA_OPTS: -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 16:45:58,529 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final-redhat-2
> 16:45:58,746 INFO [org.jboss.as.process.Host Controller.status] (main) JBAS012017: Starting process 'Host Controller'
> [Host Controller] 16:45:59,735 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final-redhat-2
> [Host Controller] 16:45:59,913 INFO [org.jboss.msc] (main) JBoss MSC version 1.0.4.GA-redhat-1
> [Host Controller] 16:46:00,023 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015899: JBoss EAP 6.2.0.GA (AS 7.3.0.Final-redhat-14) starting
> [Host Controller] 16:46:00,991 INFO [org.xnio] (MSC service thread 1-1) XNIO Version 3.0.7.GA-redhat-1
> [Host Controller] 16:46:01,010 INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.0.7.GA-redhat-1
> [Host Controller] 16:46:01,033 INFO [org.jboss.as] (Controller Boot Thread) JBAS010902: Creating http management service using network interface (management) port (9990) securePort (-1)
> [Host Controller] 16:46:01,045 INFO [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 3.2.18.GA-redhat-1
> [Host Controller] 16:46:01,173 INFO [org.jboss.as.remoting] (MSC service thread 1-1) JBAS017100: Listening on 10.123.137.201:9999
> [Host Controller] 16:46:01,857 ERROR [org.jboss.remoting.remote.connection] (Remoting "testjb7s1:MANAGEMENT" read-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> [Host Controller] 16:46:01,869 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010901: Could not connect to master. Aborting. Error was: java.lang.IllegalStateException: JBAS010942: Unable to connect due to authentication failure.
> [Host Controller] 16:46:01,891 INFO [org.jboss.as.controller] (MSC service thread 1-2) JBAS014774: Service status report
> [Host Controller] JBAS014775: New missing/unsatisfied dependencies:
> [Host Controller] service jboss.server.controller.management.security_realm.ApplicationRealm.properties_authentication (missing) dependents: [service jboss.server.controller.management.security_realm.ApplicationRealm]
> [Host Controller]
> [Host Controller] 16:46:01,897 INFO [org.jboss.as.controller] (MSC service thread 1-1) JBAS014774: Service status report
> [Host Controller] JBAS014775: New missing/unsatisfied dependencies:
> [Host Controller] service jboss.server.controller.management.security_realm.ManagementRealm (missing) dependents: [service jboss.remoting.authentication_provider.management]
> [Host Controller]
> [Host Controller] 16:46:01,922 INFO [org.jboss.as.controller] (MSC service thread 1-2) JBAS014774: Service status report
> [Host Controller] JBAS014776: Newly corrected services:
> [Host Controller] service jboss.server.controller.management.security_realm.ApplicationRealm.properties_authentication (no longer required)
> [Host Controller] service jboss.server.controller.management.security_realm.ManagementRealm (no longer required)
> [Host Controller]
> [Host Controller] 16:46:01,927 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015950: JBoss EAP 6.2.0.GA (AS 7.3.0.Final-redhat-14) stopped in 28ms
> 16:46:02,245 INFO [org.jboss.as.process.Host Controller.status] (reaper for Host Controller) JBAS012010: Process 'Host Controller' finished with an exit status of 99
> 16:46:02,247 INFO [org.jboss.as.process] (Thread-8) JBAS012016: Shutting down process controller
> 16:46:02,247 INFO [org.jboss.as.process] (Thread-8) JBAS012015: All processes finished; exiting
> Adding the realm everything works correctly
> <domain-controller>
> <remote host="10.123.137.200" port="9999" security-realm="ManagementRealm"/>
> </domain-controller>
> Maybe a warning message could be useful to find the problem.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-673) Elytron Integration with Core
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-673?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-673:
------------------------------------
Fix Version/s: 3.0.0.Alpha8
(was: 3.0.0.Alpha7)
> Elytron Integration with Core
> -----------------------------
>
> Key: WFCORE-673
> URL: https://issues.jboss.org/browse/WFCORE-673
> Project: WildFly Core
> Issue Type: Task
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 3.0.0.Alpha8
>
>
> This is the top level tracking task for Elytron integration within core. The tasks for the changes actually being made will either be linked or added as sub-tasks.
> In addition to this general issues that affect the Elytron integration are being labelled with 'affects_elytron' and can be queried using the following query: -
> https://issues.jboss.org/issues/?filter=12323574
> The label is a general catch-all for issues that are of interest to us but are not automatically blockers for our progress.
> The general criteria for the resolution of this issue will be: -
> - Inclusion of the Elytron Subsystem in core
> - All network entry points in core to be securable using Elytron
> - All SSL artefacts to be obtainable from Elytron.
> Note: The legacy modes will become better defined as we progress but whilst it must be possible to use Elytron it's use may still be optional to a certain degree.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1145) Review of HostController / Application Server Remoting connections
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1145?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1145:
-------------------------------------
Fix Version/s: 3.0.0.Alpha8
(was: 3.0.0.Alpha7)
> Review of HostController / Application Server Remoting connections
> ------------------------------------------------------------------
>
> Key: WFCORE-1145
> URL: https://issues.jboss.org/browse/WFCORE-1145
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: affects_elytron
> Fix For: 3.0.0.Alpha8
>
>
> Where an application server connects back to it's host controller in domain mode it used the same Remoting connector exposed possibly for native domain management access.
> The problem with this is that as soon as any security restrictions are placed on the connector exposed by the host controller then the application servers require something to work with this - this is even though we are only ever talking about loopback communication between two process on the same machine.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1351) FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1351:
-------------------------------------
Fix Version/s: 3.0.0.Alpha8
(was: 3.0.0.Alpha7)
> FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager
> ------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1351
> URL: https://issues.jboss.org/browse/WFCORE-1351
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting, Security
> Reporter: Ondrej Kotek
> Assignee: David Lloyd
> Priority: Critical
> Fix For: 3.0.0.Alpha8
>
>
> # Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like
> {noformat}
> ./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager
> {noformat}
> results in exception:
> {noformat}
> java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found
> {noformat}
> To make it work, permissions like following need to be added to _permissions.xml_ of _ejb.ear_:
> {noformat}
> new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"),
> new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"),
> new RemotingPermission("createEndpoint"),
> new RuntimePermission("createXnioWorker"),
> new RemotingPermission("addConnectionProvider"),
> new RuntimePermission("modifyThread"),
> new RuntimePermission("accessDeclaredMembers"),
> new ReflectPermission("suppressAccessChecks")
> {noformat}
> which is very confusing.
> Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1282) Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1282?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1282:
-------------------------------------
Fix Version/s: 3.0.0.Alpha8
(was: 3.0.0.Alpha7)
> Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string
> ---------------------------------------------------------------------------------------
>
> Key: WFCORE-1282
> URL: https://issues.jboss.org/browse/WFCORE-1282
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 1.0.2.Final
> Environment: Oracle Java
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 3.0.0.Alpha8
>
> Attachments: client_debug_eap6.log, client_debug_eap7.log, server-cert-key-ec.jks, server_debug_eap6.log, server_debug_eap7.log
>
>
> User using these cipher suites / cipher name in EAP6 won't be able to use it in EAP7.
> Setting as critical as these cipher suites, are considered for strong and widely used in my opinion.
> In server log, error "no cipher suites in common" can be seen using -Djavax.net.debug=all.
> Note, that analogous configuration in EAP6 works fine.
> Issue can be seen on Oracle Java only, as on OpenJDK / IBM these suites are not provided by method getDefaultCipherSuites().
> Also is it possible to log "no cipher suites in common" and similar tls handshake errors without -Djavax.net.debug for better troubleshooting?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1533) Integrate Management Access Control permission assignment with Elytron
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1533?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1533:
-------------------------------------
Fix Version/s: 3.0.0.Alpha8
(was: 3.0.0.Alpha7)
> Integrate Management Access Control permission assignment with Elytron
> ----------------------------------------------------------------------
>
> Key: WFCORE-1533
> URL: https://issues.jboss.org/browse/WFCORE-1533
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: affects_elytron
> Fix For: 3.0.0.Alpha8
>
>
> A big portion of management role based access control is taking the assigned roles and then mapping these to the permissions for that role.
> Elytron provides a new PermissionMapper interface that takes a SecurityIdentity and the roles mapped for that identity and returns a PermissionVerifier which can be as simple as a wrapper around a PermissionCollection.
> This will also be a good opportunity to start to move the role mapping out of the core management model to Elytron.
> After that Elytron allows for custom PermissionMapper implementations to be provided and associated with the domain using capabilities and requirements so we arrive at a point where provided the permission checks performed by management are generic enough custom PermissionMapper / PermissionVerifier implementations can be added that may or may not be role based.
> _Note: As with everything we are doing old and new need to be supported in parallel for a while although this may be achieved by providing default Elytron implementations that are wrappers around the old._
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1598) Conversion of Elytron SecurityIdentity to Subject for communication with older hosts.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1598?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1598:
-------------------------------------
Fix Version/s: 3.0.0.Alpha8
(was: 3.0.0.Alpha7)
> Conversion of Elytron SecurityIdentity to Subject for communication with older hosts.
> -------------------------------------------------------------------------------------
>
> Key: WFCORE-1598
> URL: https://issues.jboss.org/browse/WFCORE-1598
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Alpha8
>
>
> In the domain hierarchy clients trust the server they communicate with so this server currently sends a serialized representation of the Subject containing information about the user initiating the request.
> For Elytron we will use the new identity propagation features however for older slaves we will need to convert to a Subject representation.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1701) In-VM Identity Representation
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1701?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1701:
-------------------------------------
Fix Version/s: 3.0.0.Alpha8
(was: 3.0.0.Alpha7)
> In-VM Identity Representation
> -----------------------------
>
> Key: WFCORE-1701
> URL: https://issues.jboss.org/browse/WFCORE-1701
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Alpha8
>
>
> If Elytron has no current SecurityIdentity then an anonymous identity is used. The issue however is that this anonymous identity could be because the current user does not have access to be inflowed to the SecurityDomain being used for management or it could be because it is an in-vm call and no identity is established.
> We need a solution to safely represent an in-vm call and differentiate it from a user with no appropriate identity,
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1741) read-content operation does not return the uuid of the stream as the operation result
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1741?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1741:
-------------------------------------
Fix Version/s: 3.0.0.Alpha8
(was: 3.0.0.Alpha7)
> read-content operation does not return the uuid of the stream as the operation result
> -------------------------------------------------------------------------------------
>
> Key: WFCORE-1741
> URL: https://issues.jboss.org/browse/WFCORE-1741
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
> Fix For: 3.0.0.Alpha8
>
>
> See the tail end of the discussion on WFCORE-1726.
> The rules around streams in responses are:
> 1) If the thing providing the stream is an attribute, the attribute value set by the read OperationStepHandler must be the uuid of the stream.
> 2) If the thing providing the stream is a custom operation like :read-content, the result value in the response must be the uuid of the stream or a complex result object one of whose fields is the uuid of the stream.
> Metadata about streams is propagated to the client using a response-header. But since a particular request can result in more than one attached stream, the normal non-response-header part of the result for a step must provide the uuid of the stream set by that step. This allows the client to correlate the various streams with the steps that provided them.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-91) Review use of Locale in toLowerCase() calls
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-91?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFCORE-91:
-----------------------------------
Fix Version/s: (was: 3.0.0.Alpha7)
I'm unscheduling this to try and get the 3.0 task list down to bugs, EAP 7.1 features or stuff we know is coming. Let me know if it's likely to happen for 3.0 CR1.
> Review use of Locale in toLowerCase() calls
> -------------------------------------------
>
> Key: WFCORE-91
> URL: https://issues.jboss.org/browse/WFCORE-91
> Project: WildFly Core
> Issue Type: Task
> Components: CLI, Domain Management
> Reporter: Brian Stansberry
>
> There are places where we are converting strings to lower case without specifying Locale.ENGLISH. Some of these may be fine, but some are not and they should all be reviewed:
> {code}
> $ git grep "toLowerCase()"
> cli/src/main/java/org/jboss/as/cli/impl/CommandContextImpl.java: CommandHandler handler = cmdRegistry.getCommandHandler(cmdName.toLowerCase());
> cli/src/main/java/org/jboss/as/cli/impl/CommandContextImpl.java: CommandHandler handler = cmdRegistry.getCommandHandler(cmdName.toLowerCase());
> controller/src/main/java/org/jboss/as/controller/operations/global/ReadResourceDescriptionHandler.java: final AccessControl value = localName != null ? MAP.get(local
> core-model-test/tests/src/test/java/org/jboss/as/core/model/test/access/RoleMappingTestCase.java: return super.toString().toLowerCase();
> core-model-test/tests/src/test/java/org/jboss/as/core/model/test/access/RoleMappingTestCase.java: return super.toString().toLowerCase();
> core-model-test/tests/src/test/java/org/jboss/as/core/model/test/standalone/root/StandaloneRootResourceTestCase.java: String hostName = NetworkUtils.canonize(InetAddress
> domain-management/src/main/java/org/jboss/as/domain/management/security/adduser/ConfirmationChoice.java: String temp = response.toLowerCase(); // We now need to matc
> domain-management/src/test/java/org/jboss/as/domain/management/security/auditlog/AbstractAuditLogHandlerTestCase.java: PathElement.pathElement(PROTOCOL, transpor
> host-controller/src/main/java/org/jboss/as/host/controller/DirectoryGrouping.java: final DirectoryGrouping directoryGrouping = localName != null ? MAP.get(localName.toLo
> host-controller/src/main/java/org/jboss/as/host/controller/HostControllerEnvironment.java: qualifiedHostName = qualifiedHostName.trim().toLowerCase();
> host-controller/src/main/java/org/jboss/as/host/controller/discovery/S3Util.java: String lk=hashKey.toLowerCase();
> server/src/main/java/org/jboss/as/server/ServerEnvironment.java: qualifiedHostName = qualifiedHostName.trim().toLowerCase();
> testsuite-core/domain/src/test/java/org/jboss/as/test/integration/domain/rbac/RbacSoakTest.java: super("TestClient-" + id + " (" + type.toString().toLowerCase() + "
> testsuite-core/domain/src/test/java/org/jboss/as/test/integration/domain/rbac/RbacSoakTest.java: this.description = "TestClient-" + id + " (" + type.toString().toLow
> testsuite-core/shared/src/main/java/org/jboss/as/test/integration/management/interfaces/JmxInterfaceStringUtils.java: return string.replaceAll(regex, replacement).toLowe
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-234) Inconsistent synchronization in ConfigurationFile
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-234?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-234:
------------------------------------
I'm unscheduling this to try and get the 3.0 task list down to bugs, EAP 7.1 features or stuff we know is coming. Let me know if it's likely to happen for 3.0 CR1.
> Inconsistent synchronization in ConfigurationFile
> -------------------------------------------------
>
> Key: WFCORE-234
> URL: https://issues.jboss.org/browse/WFCORE-234
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha11
> Reporter: Brian Stansberry
> Fix For: 3.0.0.Alpha7
>
>
> ConfigurationFile synchronizes on itself in some places and not in others. This may cause problems, particularly with the history dir.
> The one that comes to mind is successfulBoot is synchronized, but all the methods called by ConfigurationFilePersistenceResource are not. The latter is called with the controller lock held, but the former is not. So there's a possibility of two threads interacting with the files concurrently if an operation executes immediately after boot.
> The deployment scanner schedules such an op, so it's possible. Currently the schedule is for 200 ms after deployment-scanner add runs during boot.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-710) Make ServerOperationResolver handle deployment-overlays similarly to deployments
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-710?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-710:
------------------------------------
Fix Version/s: (was: 3.0.0.Alpha7)
I'm unscheduling this to try and get the 3.0 task list down to bugs, EAP 7.1 features or stuff we know is coming. Let me know if it's likely to happen for 3.0 Beta1.
Note also that this may be considered as an incompatible behavior change, so it needs vetting before work starts.
> Make ServerOperationResolver handle deployment-overlays similarly to deployments
> --------------------------------------------------------------------------------
>
> Key: WFCORE-710
> URL: https://issues.jboss.org/browse/WFCORE-710
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Affects Versions: 2.0.0.Alpha2
> Reporter: Kabir Khan
>
> Currently in domain mode a
> {code}
> /deployment-overlay=xxx:add(...)
> {code}
> results in a deployment overlay on ALL servers.
> However for deployments
> {code}
> /deployment=xxx:add(...)
> {code}
> does not get pushed to the servers. This happens when it is associated with a server group:
> {code}
> /server-group=zzz/deployment=xxx:add(...)
> {code}
> Similarly
> {code}
> /deployment-overlay=xxx:add(...)
> {code}
> should not get pushed to the servers, until we have a
> {code}
> /server-group=zzz/deployment=yyy:add(...)
> {code}
> which picks out the servers we want to have the overlay
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-406) Resource description for platform mbean properties that throw UnsupportedOperationException should say nillable="true"
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-406?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-406:
------------------------------------
Fix Version/s: (was: 3.0.0.Alpha7)
I'm unscheduling this to try and get the 3.0 task list down to bugs, EAP 7.1 features or stuff we know is coming. Let me know if it's likely to happen for 3.0 Beta1.
> Resource description for platform mbean properties that throw UnsupportedOperationException should say nillable="true"
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-406
> URL: https://issues.jboss.org/browse/WFCORE-406
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Environment: FreeBSD, OpenJDK 1.6
> Reporter: Brian Stansberry
> Priority: Minor
>
> Some platform mbean getters are documented to throw a UOE on some VMs. The read-resource handler will catch the UOE and leave the attribute undefined, but the description says it's not nillable.
> Specifically, PlatformMBeanDescriptions.getThreadingResource()'s THREAD_CPU_TIME_ENABLED attribute, although there may well be others.
> This leads to this unit test failure on jvms where the UOE is thrown:
> failure message="thread-cpu-time-enabled is undefined"
> type="junit.framework.AssertionFailedError">junit.fra mework.AssertionFailedError: thread-cpu-time-enabled is undefined
> at junit.framework.Assert.fail(Assert.java:50)
> at junit.framework.Assert.assertTrue(Assert.java:20)
> at
> org.jboss.as.platform.mbean.PlatformMBeanResourceUnitTestCase.validateResource(PlatformMBeanResourceUn
> itTestCase.java:595)
> at org.jboss.as.platform.mbean.PlatformMBeanResourceUnitTestCase.basicResourceTest(PlatformMBeanResourceUnitTestCase.java:563)
> at
> org.jboss.as.platform.mbean.PlatformMBeanResourceUnitTestCase.testThreadingMXBean(PlatformMBeanResourceUnitTestCase.java:340)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-887) "Deprecate" using an expression in model refs to interfaces
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-887?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-887:
------------------------------------
Fix Version/s: 3.0.0.Beta1
(was: 3.0.0.Alpha7)
> "Deprecate" using an expression in model refs to interfaces
> -----------------------------------------------------------
>
> Key: WFCORE-887
> URL: https://issues.jboss.org/browse/WFCORE-887
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 3.0.0.Beta1
>
>
> SocketBindingGroupResourceDefinition and OutboundSocketBindingResourceDefinition both have attributes that represent model refs to interface resources, but which also allow expressions.
> Model references should not allow expressions. These were "grandfathered in" when the large scale expression support roll out happened for AS 7.2 / EAP 6.1.
> There's no metadata facility to record that expression support is deprecated, but the add handler for these should log a WARN if they encounter an expression. Hopefully in EAP 8 we can then remove expression support.
> We should look for other cases like this too, although those changes should be separate JIRAs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[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 updated WFCORE-952:
------------------------------------
Fix Version/s: (was: 3.0.0.Alpha7)
I'm unscheduling this to try and get the 3.0 task list down to bugs, EAP 7.1 features or stuff we know is coming. Let me know if it's likely to happen for 3.0 Beta1.
> 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
> Priority: Minor
>
> 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
[JBoss JIRA] (WFCORE-909) Allow tests to turn on boot-time enforcement of capability resolution in an --admin-only process
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-909?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-909:
------------------------------------
Fix Version/s: (was: 3.0.0.Alpha7)
I'm unscheduling this to try and get the 3.0 task list down to bugs, EAP 7.1 features or stuff we know is coming. Let me know if it's likely to happen for 3.0 Beta1.
> Allow tests to turn on boot-time enforcement of capability resolution in an --admin-only process
> ------------------------------------------------------------------------------------------------
>
> Key: WFCORE-909
> URL: https://issues.jboss.org/browse/WFCORE-909
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Priority: Minor
>
> The OperationContext current will not throw error during boot of an --admin-only process if required capabilities cannot all be resolved, instead simply logging an ERROR. This is to allow the process to boot and give the user an opportunity to fix the problem.
> Test suites often run admin-only processes though to test management of the model without needing to be concerned about runtime services. For these tests, failing on boot if required capabilities are not present may be desired. In particular, it's desirable for WF full's ParseAndMarshalModelsTestCase. So this task is to use a "jboss.unsupported.validate.boot.capabilities" system property to turn on capability resolution enforcement.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1054) Better subsystem test coverage
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1054?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1054:
-------------------------------------
Fix Version/s: (was: 3.0.0.Alpha7)
I'm unscheduling this to try and get the 3.0 task list down to bugs, EAP 7.1 features or stuff we know is coming. Let me know if it's likely to happen for 3.0 Beta1.
> Better subsystem test coverage
> ------------------------------
>
> Key: WFCORE-1054
> URL: https://issues.jboss.org/browse/WFCORE-1054
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Kabir Khan
> Assignee: Kabir Khan
>
> The subsystem and core-model tests should be expanded to test FULL models. In many(?) cases these tests do not use a full xml. We should generate a full xml file for testing, possibly by using the schema. Or by inspecting the resource registrations a bit similar to the ExpressionSupportTestCase.
> We might need something to deal with the case where e.g. a parent expects only one of two children to be set (i.e. there is a choice) and not both. In those cases it would be good to be able to test all possible permutations. This testing should be at least the parsing and marshalling of the main model. It is uncertain whether it will be possible to do do transformers, although perhaps we could do something like the DomainAdjusters from the mixed domain tests.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1053) Model compatibility tests
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1053?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1053:
-------------------------------------
Fix Version/s: (was: 3.0.0.Alpha7)
I'm unscheduling this to try and get the 3.0 task list down to bugs, EAP 7.1 features or stuff we know is coming. Let me know if it's likely to happen for 3.0 Beta1.
> Model compatibility tests
> -------------------------
>
> Key: WFCORE-1053
> URL: https://issues.jboss.org/browse/WFCORE-1053
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Kabir Khan
> Assignee: Kabir Khan
>
> Once the infrastructure is in place, we will need to test all subsystems here and in WildFly.
> The basic idea is some variety of CompareModelVersionsUtil and compare the current resource registrations against a stored snapshot of the resource registrations
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1128) Improve the subsystem test schema test coverage
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1128?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1128:
-------------------------------------
Fix Version/s: (was: 3.0.0.Alpha7)
I'm unscheduling this to try and get the 3.0 task list down to bugs, EAP 7.1 features or stuff we know is coming. Let me know if it's likely to happen for 3.0 Beta1.
> Improve the subsystem test schema test coverage
> -----------------------------------------------
>
> Key: WFCORE-1128
> URL: https://issues.jboss.org/browse/WFCORE-1128
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.1.Final
> Reporter: Kabir Khan
> Assignee: Kabir Khan
>
> Currently the way to enable the AbstractSubsystemBaseTest testSchema() and testSchemaOfSubsystemTemplates() tests is to override getSubsystemXsdPath() and getSubsystemTemplatePaths().
> Rather than making it explicit to turn on, it should be explicit to turn off.
> Also the current way of doing this uses Assume.assumeTrue() to check if a test has provided a schema file, which provides a lot of ignored test noise in the test output. If the xsd should not be tested, methods should instead override testSchema() or testSchemaOfSubsystemTemplates() and provide an empty implementation with a comment saying why it is not important.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1154) Deprecate permgen attributes in host and server config level jvm settings
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1154?page=com.atlassian.jira.plugi... ]
Brian Stansberry resolved WFCORE-1154.
--------------------------------------
Fix Version/s: 3.0.0.Alpha2
(was: 3.0.0.Alpha7)
Resolution: Done
> Deprecate permgen attributes in host and server config level jvm settings
> -------------------------------------------------------------------------
>
> Key: WFCORE-1154
> URL: https://issues.jboss.org/browse/WFCORE-1154
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 3.0.0.Alpha2
>
>
> The permgen size attributes no longer do anything in a core 2.0 or later server, as we require JDK 8 and our code ignores these if JDK 8 or later is running. So we should deprecate the config elements and log a message if they are used, and add deprecation text in the xsd.
> I considered only deprecating these attributes if they appear in the host=* tree, and not doing the ones for domain-wide resources, since those could be used for legacy slaves running JDK < 8. But I think the distinction isn't worth the effort. First, these things are deprecated in all cases in the sense that they may go away in some future release. And second, all that happens is an INFO message is logged, and the chances that message may help some JDK 8 user offsets the chance that a JDK < 8 user would be annoyed by some spurious INFO logging.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1220) Try closing the channel if java.lang.Error prevents sending error responses to the client
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1220?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1220:
-------------------------------------
Fix Version/s: 3.0.0.CR1
(was: 3.0.0.Alpha7)
> Try closing the channel if java.lang.Error prevents sending error responses to the client
> -----------------------------------------------------------------------------------------
>
> Key: WFCORE-1220
> URL: https://issues.jboss.org/browse/WFCORE-1220
> Project: WildFly Core
> Issue Type: Sub-task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> Beyond the basic work on WFCORE-1134, look into further reaction when Errors occur and the server or HC cannot even send an error response to the caller. If we get to this point, the task has already failed to handle a problem and now we can't notify the remote side either. Most likely this is an OOME situation, although any Error here means a major issue.
> Options:
> 1) Try and close the channel to disconnect this process from the remote end so it doesn't disrupt the remote end. If this is an intra-HC or HC-server connection a successful close will remove this process from normal domain control. If this is a server the HC still has some control over the server via the ProcessController, e.g. to handle a 'kill' or 'destroy' management op. If this is a slave HC, the slave is disconnected from the domain. Either a server or a slave HC may try to reconnect, although it's likely better if that fails and the user just restarts the process.
> If the remote side is an end user client (e.g. CLI) then a successful close will be noticed by the client. The user can reconnect or take action to terminate this process.
> 2) Commit suicide via SystemExiter.exit. But I'm not certain complete termination of the process is how we want to deal with problems with management requests. Probably some sort of configurable policy would be better.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1220) Try closing the channel if java.lang.Error prevents sending error responses to the client
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1220?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1220:
-------------------------------------
Fix Version/s: (was: 3.0.0.CR1)
> Try closing the channel if java.lang.Error prevents sending error responses to the client
> -----------------------------------------------------------------------------------------
>
> Key: WFCORE-1220
> URL: https://issues.jboss.org/browse/WFCORE-1220
> Project: WildFly Core
> Issue Type: Sub-task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> Beyond the basic work on WFCORE-1134, look into further reaction when Errors occur and the server or HC cannot even send an error response to the caller. If we get to this point, the task has already failed to handle a problem and now we can't notify the remote side either. Most likely this is an OOME situation, although any Error here means a major issue.
> Options:
> 1) Try and close the channel to disconnect this process from the remote end so it doesn't disrupt the remote end. If this is an intra-HC or HC-server connection a successful close will remove this process from normal domain control. If this is a server the HC still has some control over the server via the ProcessController, e.g. to handle a 'kill' or 'destroy' management op. If this is a slave HC, the slave is disconnected from the domain. Either a server or a slave HC may try to reconnect, although it's likely better if that fails and the user just restarts the process.
> If the remote side is an end user client (e.g. CLI) then a successful close will be noticed by the client. The user can reconnect or take action to terminate this process.
> 2) Commit suicide via SystemExiter.exit. But I'm not certain complete termination of the process is how we want to deal with problems with management requests. Probably some sort of configurable policy would be better.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1758) WFLYCC0034: Closing leaked controller client
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1758?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-1758:
---------------------------------------
Moved back to WFCORE. While we won't fix this immediately I'm leaving the priority as Major as it is an issue. It will take some thought to not affect some other subclasses of the {{AbstractModelControllerClient}}. I've not seen or heard of issues other than misbehaving consumers of the client.
> WFLYCC0034: Closing leaked controller client
> --------------------------------------------
>
> Key: WFCORE-1758
> URL: https://issues.jboss.org/browse/WFCORE-1758
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Martin Choma
> Assignee: James Perkins
> Attachments: server.log
>
>
> We are intermittently getting "WFLYCC0034: Closing leaked controller client" from RemotingModelControllerClient#finalize method.
> I wonder, isn't implementation of RemotingModelControllerClient#finalize() method [1] example of dangerous "safety net" implementation discussed in presentation "JVM finalize pitfalls" [2] ?
> *Reproducer:*
> 1. using ibm java 1.8
> 2. setting <startup-timeout>1</startup-timeout>
> [1] https://github.com/wildfly/wildfly-core/blob/master/controller-client/src...
> [2] https://www.youtube.com/watch?v=UrGP6pfb0H8
> [3]
> {noformat}
> 05:54:10 Aug 16, 2016 5:54:10 AM org.jboss.as.controller.client.impl.RemotingModelControllerClient finalize
> 05:54:10 WARN: WFLYCC0034: Closing leaked controller client
> 05:54:10 WFLYCC0030: Allocation stack trace:
> 05:54:10 at java.lang.Thread.getStackTrace(Thread.java:1552)
> 05:54:10 at org.jboss.as.controller.client.impl.RemotingModelControllerClient.<init>(RemotingModelControllerClient.java:74)
> 05:54:10 at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:567)
> 05:54:10 at org.wildfly.plugin.common.ManagementClient.<init>(ManagementClient.java:37)
> 05:54:10 at org.wildfly.plugin.common.AbstractServerConnection.createClient(AbstractServerConnection.java:126)
> 05:54:10 at org.wildfly.plugin.server.StartMojo.execute(StartMojo.java:269)
> 05:54:10 at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> 05:54:10 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 05:54:10 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 05:54:10 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 05:54:10 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> 05:54:10 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> 05:54:10 at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> 05:54:10 at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> 05:54:10 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
> 05:54:10 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> 05:54:10 at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> 05:54:10 at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
> 05:54:10 at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
> 05:54:10 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 05:54:10 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 05:54:10 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 05:54:10 at java.lang.reflect.Method.invoke(Method.java:498)
> 05:54:10 at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> 05:54:10 at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> 05:54:10 at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> 05:54:10 at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1758) WFLYCC0034: Closing leaked controller client
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1758?page=com.atlassian.jira.plugi... ]
James Perkins moved WFMP-61 to WFCORE-1758:
-------------------------------------------
Project: WildFly Core (was: WildFly Maven Plugin)
Key: WFCORE-1758 (was: WFMP-61)
> WFLYCC0034: Closing leaked controller client
> --------------------------------------------
>
> Key: WFCORE-1758
> URL: https://issues.jboss.org/browse/WFCORE-1758
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Martin Choma
> Assignee: James Perkins
> Attachments: server.log
>
>
> We are intermittently getting "WFLYCC0034: Closing leaked controller client" from RemotingModelControllerClient#finalize method.
> I wonder, isn't implementation of RemotingModelControllerClient#finalize() method [1] example of dangerous "safety net" implementation discussed in presentation "JVM finalize pitfalls" [2] ?
> *Reproducer:*
> 1. using ibm java 1.8
> 2. setting <startup-timeout>1</startup-timeout>
> [1] https://github.com/wildfly/wildfly-core/blob/master/controller-client/src...
> [2] https://www.youtube.com/watch?v=UrGP6pfb0H8
> [3]
> {noformat}
> 05:54:10 Aug 16, 2016 5:54:10 AM org.jboss.as.controller.client.impl.RemotingModelControllerClient finalize
> 05:54:10 WARN: WFLYCC0034: Closing leaked controller client
> 05:54:10 WFLYCC0030: Allocation stack trace:
> 05:54:10 at java.lang.Thread.getStackTrace(Thread.java:1552)
> 05:54:10 at org.jboss.as.controller.client.impl.RemotingModelControllerClient.<init>(RemotingModelControllerClient.java:74)
> 05:54:10 at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:567)
> 05:54:10 at org.wildfly.plugin.common.ManagementClient.<init>(ManagementClient.java:37)
> 05:54:10 at org.wildfly.plugin.common.AbstractServerConnection.createClient(AbstractServerConnection.java:126)
> 05:54:10 at org.wildfly.plugin.server.StartMojo.execute(StartMojo.java:269)
> 05:54:10 at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> 05:54:10 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 05:54:10 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 05:54:10 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 05:54:10 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> 05:54:10 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> 05:54:10 at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> 05:54:10 at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> 05:54:10 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
> 05:54:10 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> 05:54:10 at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> 05:54:10 at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
> 05:54:10 at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
> 05:54:10 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 05:54:10 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 05:54:10 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 05:54:10 at java.lang.reflect.Method.invoke(Method.java:498)
> 05:54:10 at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> 05:54:10 at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> 05:54:10 at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> 05:54:10 at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6596) WrongClassException when using infinispan as remote-store for hibernate entity cache
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6596?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-6596:
------------------------------------
Could the WrongClassException be an application problem?
{quote}
Caused by: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
{quote}
> WrongClassException when using infinispan as remote-store for hibernate entity cache
> ------------------------------------------------------------------------------------
>
> Key: WFLY-6596
> URL: https://issues.jboss.org/browse/WFLY-6596
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Java version: 1.8.0_45, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_45\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos"
> Infifnspan 8.1.2 or 8.2.0
> Reporter: Gunther v. Wolffersdorff
> Assignee: Scott Marlow
> Labels: inifinispan-commons, org.hibernate.WrongClassException, remote-store
> Attachments: clustered.sample.xml, infinispan.zip, sample-10.1.0.Final.zip, sample.zip, standalone.sample.ha-10.1.0.Final.xml, standalone.sample.ha.xml
>
>
> Starting an application and then requesting a list of cachable JPA entitties ( configured cachable using a hibernate entity invalidation-cache with a remote-server as remote-store ) causes:
> {code}
> 13:00:52,541 MESZ ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /sample-web/rest/members/listAll: org.jboss.resteasy.spi.UnhandledException: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
> Caused by: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:492) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.criteria.compile.CriteriaQueryTypeQueryAdapter.getResultList(CriteriaQueryTypeQueryAdapter.java:50) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.jboss.as.jpa.container.TypedQueryNonTxInvocationDetacher.getResultList(TypedQueryNonTxInvocationDetacher.java:58) [wildfly-jpa-10.1.0.Final.jar:10.1.0.Final]
> at de.alvara.ticket.sample.data.MemberRepository.findAllOrderedByName(MemberRepository.java:58) [sample-ejb.jar:]
> at de.alvara.ticket.sample.data.MemberRepository$Proxy$_$$_WeldClientProxy.findAllOrderedByName(Unknown Source) [sample-ejb.jar:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService.listAllMembers(MemberResourceRESTService.java:75) [classes:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService$Proxy$_$$_WeldClientProxy.listAllMembers(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_66]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_66]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_66]
> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_66]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> ... 43 more
> Caused by: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.event.internal.DefaultLoadEventListener.processCachedEntry(DefaultLoadEventListener.java:631) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:602) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:462) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.internalLoad(SessionImpl.java:1022) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:632) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolve(EntityType.java:424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:154) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:128) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1133) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.processResultSet(Loader.java:992) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQuery(Loader.java:930) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:336) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2617) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2600) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2429) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.list(Loader.java:2424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:501) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:371) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1326) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> ... 58 more
> {code}
> Entity cache is configured like this:
> {code:xml}
> ...
> <invalidation-cache name="entity" mode="SYNC">
> <eviction strategy="LRU" max-entries="1000"/>
> <expiration lifespan="45000" max-idle="30000"/>
> <remote-store cache="hibernateDistributed" socket-timeout="60000" tcp-no-delay="true" remote-servers="local-cache-server" fetch-state="false" passivation="false" preload="false" purge="true" shared="true"/>
> </invalidation-cache>
> ...
> <outbound-socket-binding name="local-cache-server">
> <remote-destination host="${jboss.bind.address:127.0.0.1}" port="11322"/>
> </outbound-socket-binding>
> ...
> {code}
> see standalone.sample.ha-10.1.0.Final.xml .
> *This constellation works fine using Wildfly 8.2.0 and Infinispan 7.2.5 .*
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-7031) Redirect Port Fails to Redirect to 3rd Party HTTP Port
by Joe Carder (JIRA)
Joe Carder created WFLY-7031:
--------------------------------
Summary: Redirect Port Fails to Redirect to 3rd Party HTTP Port
Key: WFLY-7031
URL: https://issues.jboss.org/browse/WFLY-7031
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 10.0.0.CR1
Reporter: Joe Carder
Assignee: Stuart Douglas
Priority: Minor
When setting a redirect socket to port not opened by Wildfly (IE: a port opened by Apache HTTPD or IIS), Wildfly throws the following exception:
ERROR [io.undertow.request] (default task-2) UT005001: An exception occurred processing the request: java.lang.IllegalStateException: UT010053: No confidential port is available to redirect the current request.
With the redirect socket to a port opened by JBoss, it works as expected. I'm not 100% sure this is a bug, or functional decision made for Wildfly 10 and is working as expected. However, in Previous Widlfly version (Widlfly 8) it was possible to set the redirect port to a third party service without out issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-4376) Incorrect callback handler used during authentication (SASL)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4376?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-4376:
-----------------------------------------------
Enrique Gonzalez Martinez <egonzale(a)redhat.com> changed the Status of [bug 901248|https://bugzilla.redhat.com/show_bug.cgi?id=901248] from ASSIGNED to POST
> Incorrect callback handler used during authentication (SASL)
> -------------------------------------------------------------
>
> Key: WFLY-4376
> URL: https://issues.jboss.org/browse/WFLY-4376
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Reporter: Enrique González Martínez
> Assignee: Enrique González Martínez
> Fix For: 10.0.0.CR5
>
>
> Cluster topology messages are not using the proper callbackhandler when the connection is being established.
> {code}
> 06:59:44,609 ERROR [org.jboss.remoting.remote.connection] (Remoting "config-based-ejb-client-endpoint" read-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> 06:59:44,611 INFO [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager] (ejb-client-cluster-node-connection-creation-2-thread-2) Could not create a connection for cluster node ClusterNode{clusterName='ejb', nodeName='perf18', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='10.16.90.54', destinationPort=4447}], resolvedDestination=[Destination address=10.16.90.54, destination port=4447]} in cluster ejb
> java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
> at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:89)
> at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:406)
> at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:380)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:382)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:225)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
> at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
> at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
> at org.xnio.nio.NioHandle.run(NioHandle.java:90)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:187)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:386)
> at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:151)
> at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:132)
> at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:87)
> ... 7 more
> {code}
> Before that, this log is produced:
> {code}
> DEBUG: Client authentication failed for mechanism DIGEST-MD5: javax.security.sasl.SaslException: DIGEST-MD5: Cannot perform callback to acquire realm, authentication ID or password [Caused by javax.security.auth.callback.UnsupportedCallbackException]
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-7030) WildFly don't include the license file
by gil cattaneo (JIRA)
[ https://issues.jboss.org/browse/WFLY-7030?page=com.atlassian.jira.plugin.... ]
gil cattaneo edited comment on WFLY-7030 at 9/1/16 8:08 AM:
------------------------------------------------------------
Found @
testsuite/shared/src/main/java/org/jboss/as/test/integration/security/common/LICENSE-2.0.txt
servlet-feature-pack/src/main/resources/content/copyright.txt
servlet-feature-pack/src/main/resources/content/LICENSE.txt
Sorry for the noise
Regards
was (Author: puntogil):
Found @
testsuite/shared/src/main/java/org/jboss/as/test/integration/security/common/LICENSE-2.0.txt
servlet-feature-pack/src/main/resources/content/copyright.txt
servlet-feature-pack/src/main/resources/content/LICENSE.txt
servlet-feature-pack/src/main/resources/content/README.txt
Sorry for the noise
Regards
> WildFly don't include the license file
> ---------------------------------------
>
> Key: WFLY-7030
> URL: https://issues.jboss.org/browse/WFLY-7030
> Project: WildFly
> Issue Type: Feature Request
> Reporter: gil cattaneo
> Assignee: Jason Greene
>
> Hi
> Not available LICENSE file in source directory structure
> Please. Added license and copyright notice.
> the fedora pakaging guideline is very strictly precise about this problem
> https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging...
> Thanks in advance
> Regards
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1127) SocketBindingManagerImpl$UnnamedRegistryImpl is overly picky about unbound sockets
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1127?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1127:
-------------------------------------------------
Enrique Gonzalez Martinez <egonzale(a)redhat.com> changed the Status of [bug 1282532|https://bugzilla.redhat.com/show_bug.cgi?id=1282532] from ASSIGNED to NEW
> 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, 11 months
[JBoss JIRA] (WFCORE-1726) CLI support for response attachments
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1726?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise updated WFCORE-1726:
-----------------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1763
> CLI support for response attachments
> ------------------------------------
>
> Key: WFCORE-1726
> URL: https://issues.jboss.org/browse/WFCORE-1726
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> CLI doesn't support the streams attached to a response. Incremental deployment support offers today the ability to read the content of a deployment. It would be interesting to operate it from the CLI. Some resource (such as the log file) expose some attributes as stream.
> The following operations are returning streams:
> /subsystem=logging/log-file=server.log:read-attribute(name=stream)
> /subsystem=logging/log-file=server.log:read-resource(include-runtime)
> /deployment=toto:read-content(path=index.html)
> As we can see, streams can be located in attributes, as operation response, inside a resource.
> The CLI offers 2 way to approach the problem:
> 1) Extend the Low level operation support with a way to save/display attached streams. This would require some XML configuration and possibly UI workflow to prompt user for the right action. Making from stream to file path would be not ideal and far from being user friendly. The good side is tha tit would work in any case (batch, non batch). The XML configuration can be a bit complex and prompting user is not an ideal workflow.
> 2) Define a new high level command that would cope with any operation.
> Such command would look like:
> attachment save --operation=/subsystem=logging/log-file=server.log:read-attribute(name=stream) --file=/my/local/path/to/file
> attachment display --operation=/subsystem=logging/log-file=server.log:read-attribute(name=stream)
> - No risk to impact existing scripts. This is a new feature, so people would have to update their scripts to add the command.
> - The challenge is located in mapping a Stream to a file name. The user provides the name he wants. Furthermore, in interactive mode, the user can use completion to complete this target file.
> - No more prompting, the user knows ahead of time what he wants to do.
> - Problem is that batch mode doesn't re-dispatch each step response to each input command. So some logic should be needed to properly handle streams in batch.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1351) FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugi... ]
David Lloyd commented on WFCORE-1351:
-------------------------------------
Are there updated stack traces? I think at this point the remaining problems will be in the application server code rather than in the libraries.
> FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager
> ------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1351
> URL: https://issues.jboss.org/browse/WFCORE-1351
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting, Security
> Reporter: Ondrej Kotek
> Assignee: David Lloyd
> Priority: Critical
> Fix For: 3.0.0.Alpha7
>
>
> # Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like
> {noformat}
> ./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager
> {noformat}
> results in exception:
> {noformat}
> java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found
> {noformat}
> To make it work, permissions like following need to be added to _permissions.xml_ of _ejb.ear_:
> {noformat}
> new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"),
> new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"),
> new RemotingPermission("createEndpoint"),
> new RuntimePermission("createXnioWorker"),
> new RemotingPermission("addConnectionProvider"),
> new RuntimePermission("modifyThread"),
> new RuntimePermission("accessDeclaredMembers"),
> new ReflectPermission("suppressAccessChecks")
> {noformat}
> which is very confusing.
> Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-700) jboss deployment structure error when two deployments share the same dependency
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-700?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-700:
------------------------------------------------
Enrique Gonzalez Martinez <egonzale(a)redhat.com> changed the Status of [bug 1120628|https://bugzilla.redhat.com/show_bug.cgi?id=1120628] from ASSIGNED to CLOSED
> jboss deployment structure error when two deployments share the same dependency
> -------------------------------------------------------------------------------
>
> Key: WFCORE-700
> URL: https://issues.jboss.org/browse/WFCORE-700
> Project: WildFly Core
> Issue Type: Bug
> Affects Versions: 2.0.0.Alpha2
> Reporter: Enrique González Martínez
> Assignee: Enrique González Martínez
>
> When two deployments depend on the same library it could throw and IOException.
> The problem is located in {code} org.jboss.as.server.deployment.module.descriptor.JBossDeploymentStructureParser12 {code}
> * When it is executed in sequence
> *# The first time is called with the argument "path", VFS is using RootFileSystem and it is considered a file.
> *# Once it is called the second time, VFS is using JavaZipFileSystem (is mounted during the first call) and this time is not considered a file.
> * When is executed in parallel
> *# both of them are using RootFileSystem. The second time VirtualFile.isFile is called throws an exception (Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6596) WrongClassException when using infinispan as remote-store for hibernate entity cache
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6596?page=com.atlassian.jira.plugin.... ]
Radoslav Husar reassigned WFLY-6596:
------------------------------------
Component/s: (was: Server)
Assignee: Scott Marlow
> WrongClassException when using infinispan as remote-store for hibernate entity cache
> ------------------------------------------------------------------------------------
>
> Key: WFLY-6596
> URL: https://issues.jboss.org/browse/WFLY-6596
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Java version: 1.8.0_45, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_45\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos"
> Infifnspan 8.1.2 or 8.2.0
> Reporter: Gunther v. Wolffersdorff
> Assignee: Scott Marlow
> Labels: inifinispan-commons, org.hibernate.WrongClassException, remote-store
> Attachments: clustered.sample.xml, infinispan.zip, sample-10.1.0.Final.zip, sample.zip, standalone.sample.ha-10.1.0.Final.xml, standalone.sample.ha.xml
>
>
> Starting an application and then requesting a list of cachable JPA entitties ( configured cachable using a hibernate entity invalidation-cache with a remote-server as remote-store ) causes:
> {code}
> 13:00:52,541 MESZ ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /sample-web/rest/members/listAll: org.jboss.resteasy.spi.UnhandledException: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
> Caused by: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:492) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.criteria.compile.CriteriaQueryTypeQueryAdapter.getResultList(CriteriaQueryTypeQueryAdapter.java:50) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.jboss.as.jpa.container.TypedQueryNonTxInvocationDetacher.getResultList(TypedQueryNonTxInvocationDetacher.java:58) [wildfly-jpa-10.1.0.Final.jar:10.1.0.Final]
> at de.alvara.ticket.sample.data.MemberRepository.findAllOrderedByName(MemberRepository.java:58) [sample-ejb.jar:]
> at de.alvara.ticket.sample.data.MemberRepository$Proxy$_$$_WeldClientProxy.findAllOrderedByName(Unknown Source) [sample-ejb.jar:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService.listAllMembers(MemberResourceRESTService.java:75) [classes:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService$Proxy$_$$_WeldClientProxy.listAllMembers(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_66]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_66]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_66]
> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_66]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> ... 43 more
> Caused by: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.event.internal.DefaultLoadEventListener.processCachedEntry(DefaultLoadEventListener.java:631) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:602) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:462) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.internalLoad(SessionImpl.java:1022) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:632) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolve(EntityType.java:424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:154) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:128) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1133) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.processResultSet(Loader.java:992) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQuery(Loader.java:930) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:336) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2617) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2600) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2429) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.list(Loader.java:2424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:501) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:371) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1326) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> ... 58 more
> {code}
> Entity cache is configured like this:
> {code:xml}
> ...
> <invalidation-cache name="entity" mode="SYNC">
> <eviction strategy="LRU" max-entries="1000"/>
> <expiration lifespan="45000" max-idle="30000"/>
> <remote-store cache="hibernateDistributed" socket-timeout="60000" tcp-no-delay="true" remote-servers="local-cache-server" fetch-state="false" passivation="false" preload="false" purge="true" shared="true"/>
> </invalidation-cache>
> ...
> <outbound-socket-binding name="local-cache-server">
> <remote-destination host="${jboss.bind.address:127.0.0.1}" port="11322"/>
> </outbound-socket-binding>
> ...
> {code}
> see standalone.sample.ha-10.1.0.Final.xml .
> *This constellation works fine using Wildfly 8.2.0 and Infinispan 7.2.5 .*
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1266) OOPath use with primitives does not return any match
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1266?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1266:
-------------------------------------
Fix cherry-picked to 6.5.x branch with https://github.com/droolsjbpm/drools/commit/245376eeb
> OOPath use with primitives does not return any match
> ----------------------------------------------------
>
> Key: DROOLS-1266
> URL: https://issues.jboss.org/browse/DROOLS-1266
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
>
> Consider the following reproducer:
> {code:java}
> @Test
> public void testPrimitives() {
> String drl =
> "import org.drools.compiler.xpath.*;\n" +
> "global java.util.List list\n" +
> "\n" +
> "rule R when\n" +
> " Adult( $x: /children.age )\n" +
> "then\n" +
> " list.add( $x );\n" +
> "end\n";
>
> System.out.println(drl);
> KieSession ksession = new KieHelper().addContent( drl, ResourceType.DRL )
> .build()
> .newKieSession();
> List<String> list = new ArrayList<String>();
> ksession.setGlobal( "list", list );
> Man bob = new Man( "Bob", 40 );
> bob.addChild( new Child( "Charles", 12 ) );
> bob.addChild( new Child( "Debbie", 8 ) );
> ksession.insert( bob );
> ksession.fireAllRules();
>
> assertEquals(2, list.size());
> }
> {code}
> these reproducer/test fails. Does not provide any match of the primitive type returned by {{age}}.
> Please note if the rule was instead:
> {code:java}
> rule R when
> Adult( $x: /children.name )
> then
> ...
> {code}
> the test would pass.
> Hence appears OOPath is not matching on the primitive types?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-3915) Dynamic configuration of outbound SSL connections
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-3915?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-3915:
----------------------------------------
This is not on the short term roadmap but this is actually something we are planning to add support for with the move to WildFly Elytron. Similar to the description here we want to register a global / default SSLContext that when used can apply some rules to identify an SSLContext instance that should be used for the outbound connection.
> Dynamic configuration of outbound SSL connections
> -------------------------------------------------
>
> Key: WFLY-3915
> URL: https://issues.jboss.org/browse/WFLY-3915
> Project: WildFly
> Issue Type: Feature Request
> Components: Security
> Reporter: James Livingston
> Assignee: Darran Lofthouse
>
> WebSphere has a feature called "Dynamic outbound SSL configuration" (http://www-01.ibm.com/support/knowledgecenter/SSCKBL_8.5.5/com.ibm.websph...), which allows the configuration of SSL parameters for connections which are not opened directly by the container.
> That can be useful for configuring the SSL usage of components such as resource adapters, JDBC drivers, and application-packaged web service libraries. For example the truststore/keystore could be configured different for all requests to the database host, so that the global javax.net.ssl settings to not need to be modified if the driver does not itself provide a way to configure it.
> I believe that it is implemented by using javax.net.ssl.SSLContext.setDefault() to replace the standard socket factory. The socket factory could then look at the passed hostname/port, and potentially the calling application to configure the SSL socket appropriately before returning it to the caller.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-3915) Dynamic configuration of outbound SSL connections
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-3915?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-3915:
--------------------------------------
Assignee: Darran Lofthouse (was: Jason Greene)
> Dynamic configuration of outbound SSL connections
> -------------------------------------------------
>
> Key: WFLY-3915
> URL: https://issues.jboss.org/browse/WFLY-3915
> Project: WildFly
> Issue Type: Feature Request
> Reporter: James Livingston
> Assignee: Darran Lofthouse
>
> WebSphere has a feature called "Dynamic outbound SSL configuration" (http://www-01.ibm.com/support/knowledgecenter/SSCKBL_8.5.5/com.ibm.websph...), which allows the configuration of SSL parameters for connections which are not opened directly by the container.
> That can be useful for configuring the SSL usage of components such as resource adapters, JDBC drivers, and application-packaged web service libraries. For example the truststore/keystore could be configured different for all requests to the database host, so that the global javax.net.ssl settings to not need to be modified if the driver does not itself provide a way to configure it.
> I believe that it is implemented by using javax.net.ssl.SSLContext.setDefault() to replace the standard socket factory. The socket factory could then look at the passed hostname/port, and potentially the calling application to configure the SSL socket appropriately before returning it to the caller.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-3915) Dynamic configuration of outbound SSL connections
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-3915?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-3915:
-----------------------------------
Component/s: Security
> Dynamic configuration of outbound SSL connections
> -------------------------------------------------
>
> Key: WFLY-3915
> URL: https://issues.jboss.org/browse/WFLY-3915
> Project: WildFly
> Issue Type: Feature Request
> Components: Security
> Reporter: James Livingston
> Assignee: Darran Lofthouse
>
> WebSphere has a feature called "Dynamic outbound SSL configuration" (http://www-01.ibm.com/support/knowledgecenter/SSCKBL_8.5.5/com.ibm.websph...), which allows the configuration of SSL parameters for connections which are not opened directly by the container.
> That can be useful for configuring the SSL usage of components such as resource adapters, JDBC drivers, and application-packaged web service libraries. For example the truststore/keystore could be configured different for all requests to the database host, so that the global javax.net.ssl settings to not need to be modified if the driver does not itself provide a way to configure it.
> I believe that it is implemented by using javax.net.ssl.SSLContext.setDefault() to replace the standard socket factory. The socket factory could then look at the passed hostname/port, and potentially the calling application to configure the SSL socket appropriately before returning it to the caller.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JGRP-2080) New Address which contains IP address and port
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2080?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2080.
----------------------------
Resolution: Done
Added new flag use_ip_addr (default: false) in the transport
> New Address which contains IP address and port
> ----------------------------------------------
>
> Key: JGRP-2080
> URL: https://issues.jboss.org/browse/JGRP-2080
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Currently, UUIDs are mapped to IpAddresses (InetAddress and port). The mappings are maintained in logical_address_cache in TP and populated via the discovery protocol.
> If we encoded the IP address and port (6 bytes in IPv4, 18 bytes in IPv6) directly into the UUID, we would not have to maintain this cache anymore. At least not for IpAddresses, but still for UUID/logical_name mappings.
> An {{IPv4UUID}} (credits to Neal Dillman) would look like this:
> * 4 bytes: IPv4 address
> * 2 bytes: port
> * 12 bytes: random data (rest of the UUID)
> When joining a cluster, the joiner would only need to discover the address of the coordinator and send a JOIN-REQ to it. The JOIN-RSP would contain the view, which contains all members, so the joiner has all addresses. Plus, the coord would also send a VIEW-CHANGE to all existing members, so they have the address of the new member, too.
> When sending a unicast, the transport could simply extract the IpAddress from the first 6 bytes of the IPv4UUID to know the destination address. For multicasts, UDP is not an issue, and TCP would simply iterate over the current view and send the message to each member separately.
> An IPv6UUID would need more than 16 bytes as it already needs 18 bytes for the address and the port. We might add another 6 bytes for uniqueness, to have a nice padding at 24 bytes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months