[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)
7 years, 10 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)
7 years, 10 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)
7 years, 10 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)
7 years, 10 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)
7 years, 10 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)
7 years, 10 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)
7 years, 10 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)
7 years, 10 months