[JBoss JIRA] (WFLY-7054) Memory leak when doing deploy/undeploy app using REST and JPA
by Stuart Douglas (JIRA)
Stuart Douglas created WFLY-7054:
------------------------------------
Summary: Memory leak when doing deploy/undeploy app using REST and JPA
Key: WFLY-7054
URL: https://issues.jboss.org/browse/WFLY-7054
Project: WildFly
Issue Type: Bug
Components: REST, XML Frameworks
Affects Versions: 10.1.0.Final
Reporter: Tomas Remes
Assignee: Stuart Douglas
Priority: Critical
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, 9 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:
--------------------------------------
[~smarlow], [~rvansa] - any thoughts on why this is leading to a "shared cache region" strategy, rather than Hibernate's default "cache region per-entity-hierarchy" strategy?
[~gvwolf3d] The thing to reference as a setting is {{org.hibernate.cache.internal.DefaultCacheKeysFactory#INSTANCE}}, not {{org.hibernate.cache.internal.DefaultCacheKeysFactory}} itself.
> 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, 9 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="NONE|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, 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
> 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="NONE|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, 9 months
[JBoss JIRA] (WFLY-7016) Wildfly 10.1 IllegalStateException when starting applications when getting a session in a listener
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-7016?page=com.atlassian.jira.plugin.... ]
Paul Ferraro closed WFLY-7016.
------------------------------
Resolution: Rejected
The web session cache is only intended for use with BATCH and NONE tx modes.
> Wildfly 10.1 IllegalStateException when starting applications when getting a session in a listener
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-7016
> URL: https://issues.jboss.org/browse/WFLY-7016
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.1.0.Final
> Reporter: Matthew Casperson
> Assignee: Paul Ferraro
>
> We have the following code in a ServletRequestListener:
> {code}
> final HttpSession httpSession = httpRequest.getSession(false);
> {code}
> This code is the line:
> {code}
> [Server:main-server] at au.com.agic.settings.listener.SessionInvalidatorListener.clearSession(SessionInvalidatorListener.java:94)
> {code}
> in the stack trace below.
> We have been running applications with this listener in WildFly 10 for months without any issues, but when we migrated to WildFly 10.1, Infinispan started throwing exceptions when opening the app for the first time. The exception doesn't always happen, but often enough to make WildFly 10.1 unusable.
> The configuration was copied directly from WildFly 10 to WildFly 10.1, so there are no configuration changes between the two versions.
> {code}
> [Server:main-server] 2016-08-26 15:03:10+1000 ERROR [[io.undertow.request]] [[default task-32]] UT005023: Exception handling request to /app/retrieve_quote.jsp: java.lang.IllegalStateException: Transaction TransactionImple < ac, BasicAction: 0:ffff0a1617d4:6cdfa442:57bfb3cd:31b status: ActionStatus.COMMITTED > is not in a valid state to be invoking cache operations on.
> [Server:main-server] at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:395)
> [Server:main-server] at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:351)
> [Server:main-server] at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:345)
> [Server:main-server] at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:331)
> [Server:main-server] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [Server:main-server] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [Server:main-server] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [Server:main-server] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [Server:main-server] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [Server:main-server] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [Server:main-server] at org.infinispan.statetransfer.StateTransferInterceptor.visitReadCommand(StateTransferInterceptor.java:177)
> [Server:main-server] at org.infinispan.statetransfer.StateTransferInterceptor.visitGetKeyValueCommand(StateTransferInterceptor.java:154)
> [Server:main-server] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [Server:main-server] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [Server:main-server] at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:114)
> [Server:main-server] at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:83)
> [Server:main-server] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [Server:main-server] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [Server:main-server] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [Server:main-server] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [Server:main-server] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [Server:main-server] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [Server:main-server] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:335)
> [Server:main-server] at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411)
> [Server:main-server] at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:403)
> [Server:main-server] at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
> [Server:main-server] at org.wildfly.clustering.server.registry.CacheRegistry.getEntry(CacheRegistry.java:128)
> [Server:main-server] at org.wildfly.clustering.web.infinispan.session.InfinispanRouteLocator.locate(InfinispanRouteLocator.java:58)
> [Server:main-server] at org.wildfly.clustering.web.undertow.session.DistributableSessionIdentifierCodec.encode(DistributableSessionIdentifierCodec.java:48)
> [Server:main-server] at org.wildfly.extension.undertow.session.CodecSessionConfig.findSessionId(CodecSessionConfig.java:60)
> [Server:main-server] at io.undertow.servlet.spec.ServletContextImpl$ServletContextSessionConfig.findSessionId(ServletContextImpl.java:1084)
> [Server:main-server] at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:778)
> [Server:main-server] at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:370)
> [Server:main-server] at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:375)
> [Server:main-server] at au.com.agic.settings.listener.SessionInvalidatorListener.clearSession(SessionInvalidatorListener.java:94)
> [Server:main-server] at au.com.agic.settings.listener.SessionInvalidatorListener.requestInitialized(SessionInvalidatorListener.java:52)
> [Server:main-server] at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:246)
> [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:291)
> [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> [Server:main-server] at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> [Server:main-server] at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> [Server:main-server] at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> [Server:main-server] at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> [Server:main-server] at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> [Server:main-server] at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> [Server:main-server] at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> [Server:main-server] at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> [Server:main-server] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> [Server:main-server] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:main-server] at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2069) UNICAST3: bypass or remove when running over TCP
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2069?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2069.
----------------------------
Resolution: Done
> UNICAST3: bypass or remove when running over TCP
> ------------------------------------------------
>
> Key: JGRP-2069
> URL: https://issues.jboss.org/browse/JGRP-2069
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.11, 4.0
>
>
> When running over TCP as transport, UNICAST3 is still required: while TCP/IP retransmits messages reliably and also provides sender-FIFO ordering, the receiver's thread pool might be exhausted and thus the message might get rejected.
> However, *if* the regular and OOB thread pools are disabled, we could actually bypass (or completely remove) UNICAST3. If messages get dropped by a protocol further up the stack, however, there will be no retransmission in this case.
> SOLUTION:
> * Document this behavior
> * Emit an INFO message (or automatically bypass UNICAST3) when run over a TCP transport and both OOB and regular pools are disabled
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1765) unclear NullPointerException if the deployment-scanner element is removed from the configuration
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1765?page=com.atlassian.jira.plugi... ]
Tomaz Cerar reassigned WFCORE-1765:
-----------------------------------
Assignee: ehsavoie Hugonnet (was: Jason Greene)
> unclear NullPointerException if the deployment-scanner element is removed from the configuration
> ------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1765
> URL: https://issues.jboss.org/browse/WFCORE-1765
> Project: WildFly Core
> Issue Type: Bug
> Components: Deployment Scanner
> Affects Versions: 2.0.10.Final
> Reporter: Wolf-Dieter Fink
> Assignee: ehsavoie Hugonnet
> Labels: deployment
>
> If the deployment scanner element is removed from the configuration of the standalone server a NullPointerException is logged which is unclear and difficult to find as the stack does not show any hint.
> Config:
> {xml}
> <subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0">
> <!-- deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-interval="5000" runtime-failure-causes-rollback="${jboss.deployment.scanner.rollback.on.failure:false}"/ -->
> </subsystem>
> {xml}
> Log message:
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 34) WFLYCTL0403: Unexpected failure during execution of the following operation(s): []: java.lang.NullPointerException
> at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1185)
> at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:767)
> at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:753)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:359)
> 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)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1765) unclear NullPointerException if the deployment-scanner element is removed from the configuration
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1765?page=com.atlassian.jira.plugi... ]
Tomaz Cerar moved WFLY-7052 to WFCORE-1765:
-------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-1765 (was: WFLY-7052)
Component/s: Deployment Scanner
(was: Server)
Affects Version/s: 2.0.10.Final
(was: 11.0.0.Alpha1)
> unclear NullPointerException if the deployment-scanner element is removed from the configuration
> ------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1765
> URL: https://issues.jboss.org/browse/WFCORE-1765
> Project: WildFly Core
> Issue Type: Bug
> Components: Deployment Scanner
> Affects Versions: 2.0.10.Final
> Reporter: Wolf-Dieter Fink
> Assignee: Jason Greene
> Labels: deployment
>
> If the deployment scanner element is removed from the configuration of the standalone server a NullPointerException is logged which is unclear and difficult to find as the stack does not show any hint.
> Config:
> {xml}
> <subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0">
> <!-- deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-interval="5000" runtime-failure-causes-rollback="${jboss.deployment.scanner.rollback.on.failure:false}"/ -->
> </subsystem>
> {xml}
> Log message:
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 34) WFLYCTL0403: Unexpected failure during execution of the following operation(s): []: java.lang.NullPointerException
> at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1185)
> at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:767)
> at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:753)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:359)
> 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)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2075) SYM/ASYM_ENCRYPT: don't use WeakHashMap for old ciphers
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2075?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2075.
----------------------------
Resolution: Done
> SYM/ASYM_ENCRYPT: don't use WeakHashMap for old ciphers
> -------------------------------------------------------
>
> Key: JGRP-2075
> URL: https://issues.jboss.org/browse/JGRP-2075
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.11, 4.0
>
>
> Currently we use WeakHashMap, but should not, reasons outlined below. We could replace it with a LazyRemovalCache. Andrew's email refers to SecretKeys but this probably also applies to Ciphers.
> Andrew Haley's email:
> {quote}
> TL/DR: Please don't use WeakReferences, SoftReferences, etc. to cache
> any data which might point to native memory. In particular, never do
> this with instances of java.security.Key. Instead, implement either
> some kind of ageing strategy or a fixed-size cache.
> ...
> This is a warning to anybody who might cache crypto keys.
> A customer has been having problems with the exhaustion of native
> memory before the Java heap is full. It was fun trying to track down
> the cause, but it's now happened several times to several customers,
> and it's a serious problem for real-world usage in app servers.
> PKCS#11 is a standard way to communicate between applications and
> crypto libraries. There is a Java crypto provider which supports
> PKCS#11. Some of our customers must use this provider in order to get
> FIPS certification.
> The problem is this:
> A crypto key is a buffer in memory, allocated by the PKCS#11 native
> library. It's accessed via a handle which is stored as an integer
> field in a Java object. This Java object is a PhantomReference, so
> when the garbage collector detects that a crypto key is no longer
> reachable it is closed and the associated native memory is freed.
> Modern garbage collectors don't much bother to process objects in the
> old generation because it's not usually worthwhile. Thus, crypto keys
> don't get recycled very quickly. They can pile up in the old
> generation. This isn't a problem for the Java heap because the
> objects containing the references to crypto keys are very small.
> Unfortunately, the native side of a crypto key is much bigger, maybe
> up to a thousand times bigger. So if we have 4000 stale crypto keys
> in the heap that's not a problem, a few kbytes. But the native memory
> may be a megabyte.
> This problem is made even worse by Tomcat because it uses
> SoftReferences to cache crypto keys. SoftReferences are processed
> lazily, and maybe not at all until the Java heap runs out of memory.
> Unfortunately it doesn't, but the machine runs out of native memory
> instead.
> We could solve this simply by making instances of PKCS#11 keys really
> big Java objects by padding with dummy fields. Then, the GC would
> collect them quickly. This does work but it seriously impacts
> performance. Also, we could tweak the garbage collectors to clear out
> stale references more enthusiastically, but this impacts performance
> even more. There are some controls with the G1 collector which
> process SoftReferences more aggressively and these help, but again at
> the cost of performance.
> Finally: the Shanandoah collector we're working on handles this
> problem much better than the older collectors, but it's some
> way off.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months