[JBoss JIRA] (WFLY-11026) Journal compacting doesn't work with JDK 11
by ehsavoie Hugonnet (Jira)
[ https://issues.jboss.org/browse/WFLY-11026?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet reassigned WFLY-11026:
----------------------------------------
Assignee: ehsavoie Hugonnet (was: Ingo Weiss)
> Journal compacting doesn't work with JDK 11
> -------------------------------------------
>
> Key: WFLY-11026
> URL: https://issues.jboss.org/browse/WFLY-11026
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 14.0.0.Final
> Environment: {noformat}
> java 11-ea 2018-09-25
> Java(TM) SE Runtime Environment 18.9 (build 11-ea+21)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11-ea+21, mixed mode)
> {noformat}
> Reporter: Martin Styk
> Assignee: ehsavoie Hugonnet
> Priority: Critical
> Labels: Java11, jdk10, jdk11
>
> Journal compacting doesn't work with Artemis 1.5 and JDK 11
> It fails with following stack trace:
> {noformat}
> 12:34:58,017 ERROR [org.apache.activemq.artemis.journal] (Thread-2 (ActiveMQ-IO-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$4@5483fda8)) AMQ144003: Error compacting: java.lang.reflect.InvocationTargetException
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at io.netty@4.1.25.Final//io.netty.util.internal.CleanerJava9.freeDirectBuffer(CleanerJava9.java:77)
> at io.netty@4.1.25.Final//io.netty.util.internal.PlatformDependent.freeDirectBuffer(PlatformDependent.java:388)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFileFactory.releaseBuffer(NIOSequentialFileFactory.java:175)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.doInternalWrite(NIOSequentialFile.java:312)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.internalWrite(NIOSequentialFile.java:282)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.writeDirect(NIOSequentialFile.java:255)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.AbstractJournalUpdateTask.flush(AbstractJournalUpdateTask.java:217)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.JournalImpl.compact(JournalImpl.java:1520)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.JournalImpl$14.run(JournalImpl.java:2060)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.IllegalArgumentException: duplicate or slice
> at jdk.unsupported/sun.misc.Unsafe.invokeCleaner(Unsafe.java:1238)
> {noformat}
> This causes issues also in scenario with journal replication.
> {noformat}
> 13:09:32,133 WARN [org.apache.activemq.artemis.core.server] (Thread-173) AMQ222013: Error when trying to start replication: java.lang.RuntimeException: Error during compact, look at the logs
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.JournalImpl.scheduleCompactAndBlock(JournalImpl.java:1428)
> at org.apache.activemq.artemis@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.startReplication(JournalStorageManager.java:540)
> at org.apache.activemq.artemis@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation$2.run(SharedNothingLiveActivation.java:166)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFLY-11026) Journal compacting doesn't work with JDK 11
by ehsavoie Hugonnet (Jira)
[ https://issues.jboss.org/browse/WFLY-11026?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet commented on WFLY-11026:
------------------------------------------
Should be part of the Artemis 2.7.0 component upgrade
> Journal compacting doesn't work with JDK 11
> -------------------------------------------
>
> Key: WFLY-11026
> URL: https://issues.jboss.org/browse/WFLY-11026
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 14.0.0.Final
> Environment: {noformat}
> java 11-ea 2018-09-25
> Java(TM) SE Runtime Environment 18.9 (build 11-ea+21)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11-ea+21, mixed mode)
> {noformat}
> Reporter: Martin Styk
> Assignee: ehsavoie Hugonnet
> Priority: Critical
> Labels: Java11, jdk10, jdk11
>
> Journal compacting doesn't work with Artemis 1.5 and JDK 11
> It fails with following stack trace:
> {noformat}
> 12:34:58,017 ERROR [org.apache.activemq.artemis.journal] (Thread-2 (ActiveMQ-IO-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$4@5483fda8)) AMQ144003: Error compacting: java.lang.reflect.InvocationTargetException
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at io.netty@4.1.25.Final//io.netty.util.internal.CleanerJava9.freeDirectBuffer(CleanerJava9.java:77)
> at io.netty@4.1.25.Final//io.netty.util.internal.PlatformDependent.freeDirectBuffer(PlatformDependent.java:388)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFileFactory.releaseBuffer(NIOSequentialFileFactory.java:175)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.doInternalWrite(NIOSequentialFile.java:312)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.internalWrite(NIOSequentialFile.java:282)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.writeDirect(NIOSequentialFile.java:255)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.AbstractJournalUpdateTask.flush(AbstractJournalUpdateTask.java:217)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.JournalImpl.compact(JournalImpl.java:1520)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.JournalImpl$14.run(JournalImpl.java:2060)
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.IllegalArgumentException: duplicate or slice
> at jdk.unsupported/sun.misc.Unsafe.invokeCleaner(Unsafe.java:1238)
> {noformat}
> This causes issues also in scenario with journal replication.
> {noformat}
> 13:09:32,133 WARN [org.apache.activemq.artemis.core.server] (Thread-173) AMQ222013: Error when trying to start replication: java.lang.RuntimeException: Error during compact, look at the logs
> at org.apache.activemq.artemis.journal@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.journal.impl.JournalImpl.scheduleCompactAndBlock(JournalImpl.java:1428)
> at org.apache.activemq.artemis@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.startReplication(JournalStorageManager.java:540)
> at org.apache.activemq.artemis@1.5.5.jbossorg-012//org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation$2.run(SharedNothingLiveActivation.java:166)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFLY-11843) CXF-7994 - NumberFormatException on JDK13 in org.apache.cxf.helpers.JavaUtils
by Richard Opalka (Jira)
[ https://issues.jboss.org/browse/WFLY-11843?page=com.atlassian.jira.plugin... ]
Richard Opalka updated WFLY-11843:
----------------------------------
Git Pull Request: https://github.com/apache/cxf/pull/522
> CXF-7994 - NumberFormatException on JDK13 in org.apache.cxf.helpers.JavaUtils
> -----------------------------------------------------------------------------
>
> Key: WFLY-11843
> URL: https://issues.jboss.org/browse/WFLY-11843
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 16.0.0.Final
> Reporter: Richard Opalka
> Assignee: Jim Ma
> Priority: Major
> Labels: jdk13
> Fix For: 17.0.0.Beta1
>
>
> We are getting the following exception when running CXF on top of JDK13:
> —
> Failed to start service jboss.deployment.unit."ws-endpoint-example.war".INSTALL: org.jboss.msc.service.StartExceptio
> <------>at org.jboss.as.server@8.0.1.CR1-SNAPSHOT//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:183)
> <------>at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1738)
> <------>at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1700)
> <------>at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558)
> <------>at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> <------>at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> <------>at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> <------>at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
> <------>at java.base/java.lang.Thread.run(Thread.java:835)
> Caused by: java.lang.ExceptionInInitializerError
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.WrapperClassGenerator.generateMessagePart(WrapperClassGenerator.java:335)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.WrapperClassGenerator.createWrapperClass(WrapperClassGenerator.java:224)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.WrapperClassGenerator.generate(WrapperClassGenerator.java:122)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:674)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.getExtraClass(JaxWsServiceFactoryBean.java:644)
> <------>at org.apache.cxf.impl//org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:464)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:695)
> <------>at org.apache.cxf.impl//org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:530)
> <------>at org.apache.cxf.impl//org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:263)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199)
> <------>at org.apache.cxf.impl//org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103)
> <------>at org.apache.cxf.impl//org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:168)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:211)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.EndpointImpl.getServer(EndpointImpl.java:460)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:338)
> <------>at org.jboss.ws.cxf.jbossws-cxf-server@5.2.4.Final//org.jboss.wsf.stack.cxf.deployment.EndpointImpl.doPublish(EndpointImpl.java:79)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:255)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:543)
> <------>at org.jboss.ws.cxf.jbossws-cxf-server@5.2.4.Final//org.jboss.wsf.stack.cxf.configuration.BusHolder.configure(BusHolder.java:235)
> <------>at org.jboss.ws.cxf.jbossws-cxf-server@5.2.4.Final//org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:97)
> <------>at org.jboss.ws.cxf.jbossws-cxf-server@5.2.4.Final//org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:59)
> <------>at org.jboss.as.webservices//org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:73)
> <------>at org.jboss.as.server@8.0.1.CR1-SNAPSHOT//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:176)
> <------>... 8 more
> Caused by: java.lang.NumberFormatException: For input string: "13-ea"
> <------>at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:68)
> <------>at java.base/java.lang.Integer.parseInt(Integer.java:658)
> <------>at java.base/java.lang.Integer.valueOf(Integer.java:989)
> <------>at org.apache.cxf(a)3.2.7//org.apache.cxf.helpers.JavaUtils.<clinit>(JavaUtils.java:65)
> <------>... 31 more
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFLY-11843) CXF-7994 - NumberFormatException on JDK13 in org.apache.cxf.helpers.JavaUtils
by Richard Opalka (Jira)
[ https://issues.jboss.org/browse/WFLY-11843?page=com.atlassian.jira.plugin... ]
Richard Opalka updated WFLY-11843:
----------------------------------
Labels: jdk13 (was: )
> CXF-7994 - NumberFormatException on JDK13 in org.apache.cxf.helpers.JavaUtils
> -----------------------------------------------------------------------------
>
> Key: WFLY-11843
> URL: https://issues.jboss.org/browse/WFLY-11843
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 16.0.0.Final
> Reporter: Richard Opalka
> Assignee: Jim Ma
> Priority: Major
> Labels: jdk13
> Fix For: 17.0.0.Beta1
>
>
> We are getting the following exception when running CXF on top of JDK13:
> —
> Failed to start service jboss.deployment.unit."ws-endpoint-example.war".INSTALL: org.jboss.msc.service.StartExceptio
> <------>at org.jboss.as.server@8.0.1.CR1-SNAPSHOT//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:183)
> <------>at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1738)
> <------>at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1700)
> <------>at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558)
> <------>at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> <------>at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> <------>at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> <------>at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
> <------>at java.base/java.lang.Thread.run(Thread.java:835)
> Caused by: java.lang.ExceptionInInitializerError
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.WrapperClassGenerator.generateMessagePart(WrapperClassGenerator.java:335)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.WrapperClassGenerator.createWrapperClass(WrapperClassGenerator.java:224)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.WrapperClassGenerator.generate(WrapperClassGenerator.java:122)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:674)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.getExtraClass(JaxWsServiceFactoryBean.java:644)
> <------>at org.apache.cxf.impl//org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:464)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:695)
> <------>at org.apache.cxf.impl//org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:530)
> <------>at org.apache.cxf.impl//org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:263)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199)
> <------>at org.apache.cxf.impl//org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103)
> <------>at org.apache.cxf.impl//org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:168)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:211)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.EndpointImpl.getServer(EndpointImpl.java:460)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:338)
> <------>at org.jboss.ws.cxf.jbossws-cxf-server@5.2.4.Final//org.jboss.wsf.stack.cxf.deployment.EndpointImpl.doPublish(EndpointImpl.java:79)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:255)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:543)
> <------>at org.jboss.ws.cxf.jbossws-cxf-server@5.2.4.Final//org.jboss.wsf.stack.cxf.configuration.BusHolder.configure(BusHolder.java:235)
> <------>at org.jboss.ws.cxf.jbossws-cxf-server@5.2.4.Final//org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:97)
> <------>at org.jboss.ws.cxf.jbossws-cxf-server@5.2.4.Final//org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:59)
> <------>at org.jboss.as.webservices//org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:73)
> <------>at org.jboss.as.server@8.0.1.CR1-SNAPSHOT//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:176)
> <------>... 8 more
> Caused by: java.lang.NumberFormatException: For input string: "13-ea"
> <------>at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:68)
> <------>at java.base/java.lang.Integer.parseInt(Integer.java:658)
> <------>at java.base/java.lang.Integer.valueOf(Integer.java:989)
> <------>at org.apache.cxf(a)3.2.7//org.apache.cxf.helpers.JavaUtils.<clinit>(JavaUtils.java:65)
> <------>... 31 more
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFLY-11843) CXF-7994 - NumberFormatException on JDK13 in org.apache.cxf.helpers.JavaUtils
by Richard Opalka (Jira)
Richard Opalka created WFLY-11843:
-------------------------------------
Summary: CXF-7994 - NumberFormatException on JDK13 in org.apache.cxf.helpers.JavaUtils
Key: WFLY-11843
URL: https://issues.jboss.org/browse/WFLY-11843
Project: WildFly
Issue Type: Bug
Components: Web Services
Affects Versions: 16.0.0.Final
Reporter: Richard Opalka
Assignee: Jim Ma
Fix For: 17.0.0.Beta1
We are getting the following exception when running CXF on top of JDK13:
—
Failed to start service jboss.deployment.unit."ws-endpoint-example.war".INSTALL: org.jboss.msc.service.StartExceptio
<------>at org.jboss.as.server@8.0.1.CR1-SNAPSHOT//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:183)
<------>at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1738)
<------>at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1700)
<------>at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558)
<------>at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
<------>at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
<------>at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
<------>at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
<------>at java.base/java.lang.Thread.run(Thread.java:835)
Caused by: java.lang.ExceptionInInitializerError
<------>at org.apache.cxf.impl//org.apache.cxf.jaxws.WrapperClassGenerator.generateMessagePart(WrapperClassGenerator.java:335)
<------>at org.apache.cxf.impl//org.apache.cxf.jaxws.WrapperClassGenerator.createWrapperClass(WrapperClassGenerator.java:224)
<------>at org.apache.cxf.impl//org.apache.cxf.jaxws.WrapperClassGenerator.generate(WrapperClassGenerator.java:122)
<------>at org.apache.cxf.impl//org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:674)
<------>at org.apache.cxf.impl//org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.getExtraClass(JaxWsServiceFactoryBean.java:644)
<------>at org.apache.cxf.impl//org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:464)
<------>at org.apache.cxf.impl//org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:695)
<------>at org.apache.cxf.impl//org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:530)
<------>at org.apache.cxf.impl//org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:263)
<------>at org.apache.cxf.impl//org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199)
<------>at org.apache.cxf.impl//org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103)
<------>at org.apache.cxf.impl//org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:168)
<------>at org.apache.cxf.impl//org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:211)
<------>at org.apache.cxf.impl//org.apache.cxf.jaxws.EndpointImpl.getServer(EndpointImpl.java:460)
<------>at org.apache.cxf.impl//org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:338)
<------>at org.jboss.ws.cxf.jbossws-cxf-server@5.2.4.Final//org.jboss.wsf.stack.cxf.deployment.EndpointImpl.doPublish(EndpointImpl.java:79)
<------>at org.apache.cxf.impl//org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:255)
<------>at org.apache.cxf.impl//org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:543)
<------>at org.jboss.ws.cxf.jbossws-cxf-server@5.2.4.Final//org.jboss.wsf.stack.cxf.configuration.BusHolder.configure(BusHolder.java:235)
<------>at org.jboss.ws.cxf.jbossws-cxf-server@5.2.4.Final//org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:97)
<------>at org.jboss.ws.cxf.jbossws-cxf-server@5.2.4.Final//org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:59)
<------>at org.jboss.as.webservices//org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:73)
<------>at org.jboss.as.server@8.0.1.CR1-SNAPSHOT//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:176)
<------>... 8 more
Caused by: java.lang.NumberFormatException: For input string: "13-ea"
<------>at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:68)
<------>at java.base/java.lang.Integer.parseInt(Integer.java:658)
<------>at java.base/java.lang.Integer.valueOf(Integer.java:989)
<------>at org.apache.cxf(a)3.2.7//org.apache.cxf.helpers.JavaUtils.<clinit>(JavaUtils.java:65)
<------>... 31 more
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFLY-11233) allow EntityManager caching in the JPA container
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-11233?page=com.atlassian.jira.plugin... ]
Scott Marlow updated WFLY-11233:
--------------------------------
Description:
The use case is to reduce the cost of Hibernate EntityManager creation/initialization, which could be more expensive for certain applications that use Hibernate extensions to perform additional processing at EntityManager creation time.
Details from JPA 2.2 specification:
{quote}
7.8 Requirements on the Container
7.8.1 Application-managed Persistence Contexts
When application-managed persistence contexts are used, the container must instantiate the entity manager factory and expose it to the application via JNDI. The container might use internal APIs to create the entity manager factory, or it might use the PersistenceProvider.createContainerEntityManagerFactory method. However, the container is required to support third-party persistence providers, and in this case the container must use the PersistenceProvider.createContainerEntityManagerFactory method to create the entity manager factory and the EntityManagerFactory.close method to destroy the entity manager factory prior to shutdown (if it has not been previously closed by the application).
7.8.2 Container Managed Persistence Contexts
The container is responsible for managing the lifecycle of container-managed persistence contexts, for injecting EntityManager references into web components and session bean and message-driven bean components, and for making EntityManager references available to direct lookups in JNDI. When operating with a third-party persistence provider, the container uses the contracts defined in section 7.9 to create and destroy container-managed persistence contexts. It is undefined whether a new entity manager instance is created for every persistence context, or whether entity manager instances are sometimes reused. Exactly how the container maintains the association between persistence context and JTA transaction is not defined. If a persistence context is already associated with a JTA transaction, the container uses that persistence context for subsequent invocations within the scope of that transaction, according to the semantics for persistence context propagation defined in section 7.6.4.
7.9 Runtime Contracts between the Container and Persistence Provider
This section describes contracts between the container and the persistence provider for the pluggability of third-party persistence providers. Containers are required to support these pluggability contracts. [87]
7.9.1 Container Responsibilities
For the management of a transaction-scoped persistence context, if there is no EntityManager already associated with the JTA transaction:
* The container creates a new entity manager by calling EntityManagerFactory.createEntityManager when the first invocation of an entity manager with PersistenceContextType.TRANSACTION occurs within the scope of a business method executing in the JTA transaction.
* After the JTA transaction has completed (either by transaction commit or rollback), the container closes the entity manager by calling EntityManager.close. [88] Note that the JTA transaction may rollback in a background thread (e.g., as a result of transaction timeout), in which case the container should arrange for the entity manager to be closed but the EntityManager.close method should not be concurrently invoked while the application is in an EntityManager invocation.
The container must throw the TransactionRequiredException if a transaction-scoped persistence context is used and the EntityManager persist, remove, merge, or refresh method is invoked when no transaction is active.
For stateful session beans with extended persistence contexts:
* The container creates an entity manager by calling EntityManagerFactory.createEntityManager when a stateful session bean is created that declares a dependency on an entity manager with PersistenceContextType.EXTENDED. (See section 7.6.3).
* The container closes the entity manager by calling EntityManager.close after the stateful session bean and all other stateful session beans that have inherited the same persistence context as the entity manager have been removed.
* When a business method of the stateful session bean is invoked, if the stateful session bean uses container managed transaction demarcation, and the entity manager is not already associated with the current JTA transaction, the container associates the entity manager with the current JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction. If there is a different persistence context already associated with the JTA transaction, the container throws the EJBException.
* When a business method of the stateful session bean is invoked, if the stateful session bean uses bean managed transaction demarcation and a UserTransaction is begun within the method, the container associates the persistence context with the JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction.
The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
[87] It is not required that these contracts be used when a third-party persistence provider is not used: the container might use these same APIs or its might use its own internal APIs.
[88] The container may choose to pool EntityManagers: it instead of creating and closing in each case, it may acquire one from its pool and call clear() on it.
{quote}
This jira will specifically address transaction-scoped persistence contexts referenced in JTA transactions, as there is a known point of when they are no longer referenced and can be returned to the EntityManager cache. EntityManagers that are SynchronizationType.UNSYNCHRONIZED, will not be cached.
Persistence unit hint "wildfly.jpa.emcache", may be:
* true, per EntityManagerFactory/persistence unit) cache that is shared between multiple threads.
* false (default), no caching is performed.
Persistence unit hint "wildfly.jpa.emcache.size", may be:
* 0 (default), the cache (if enabled) is unbounded. Performance may be better than bounded but will consume more memory.
* N, where N is the bounded cache max size of EntityManager instances. Bounded cache will consume less memory but may incur more performance overhead (e.g. likely to use a contended synchronization lock).
was:
It could be interesting to see if caching EntityManager instances (per EntityManagerFactory) could improve performance for applications, that could benefit from that.
The JPA 2.2 specification mentions the below, pay particular attention to the text "whether entity manager instances are sometimes reused" in section 7.8.2, also look at mention of [88]:
{quote}
7.8 Requirements on the Container
7.8.1 Application-managed Persistence Contexts
When application-managed persistence contexts are used, the container must instantiate the entity manager factory and expose it to the application via JNDI. The container might use internal APIs to create the entity manager factory, or it might use the PersistenceProvider.createContainerEntityManagerFactory method. However, the container is required to support third-party persistence providers, and in this case the container must use the PersistenceProvider.createContainerEntityManagerFactory method to create the entity manager factory and the EntityManagerFactory.close method to destroy the entity manager factory prior to shutdown (if it has not been previously closed by the application).
7.8.2 Container Managed Persistence Contexts
The container is responsible for managing the lifecycle of container-managed persistence contexts, for injecting EntityManager references into web components and session bean and message-driven bean components, and for making EntityManager references available to direct lookups in JNDI. When operating with a third-party persistence provider, the container uses the contracts defined in section 7.9 to create and destroy container-managed persistence contexts. It is undefined whether a new entity manager instance is created for every persistence context, or whether entity manager instances are sometimes reused. Exactly how the container maintains the association between persistence context and JTA transaction is not defined. If a persistence context is already associated with a JTA transaction, the container uses that persistence context for subsequent invocations within the scope of that transaction, according to the semantics for persistence context propagation defined in section 7.6.4.
7.9 Runtime Contracts between the Container and Persistence Provider
This section describes contracts between the container and the persistence provider for the pluggability of third-party persistence providers. Containers are required to support these pluggability contracts. [87]
7.9.1 Container Responsibilities
For the management of a transaction-scoped persistence context, if there is no EntityManager already associated with the JTA transaction:
* The container creates a new entity manager by calling EntityManagerFactory.createEntityManager when the first invocation of an entity manager with PersistenceContextType.TRANSACTION occurs within the scope of a business method executing in the JTA transaction.
* After the JTA transaction has completed (either by transaction commit or rollback), the container closes the entity manager by calling EntityManager.close. [88] Note that the JTA transaction may rollback in a background thread (e.g., as a result of transaction timeout), in which case the container should arrange for the entity manager to be closed but the EntityManager.close method should not be concurrently invoked while the application is in an EntityManager invocation.
The container must throw the TransactionRequiredException if a transaction-scoped persistence context is used and the EntityManager persist, remove, merge, or refresh method is invoked when no transaction is active.
For stateful session beans with extended persistence contexts:
* The container creates an entity manager by calling EntityManagerFactory.createEntityManager when a stateful session bean is created that declares a dependency on an entity manager with PersistenceContextType.EXTENDED. (See section 7.6.3).
* The container closes the entity manager by calling EntityManager.close after the stateful session bean and all other stateful session beans that have inherited the same persistence context as the entity manager have been removed.
* When a business method of the stateful session bean is invoked, if the stateful session bean uses container managed transaction demarcation, and the entity manager is not already associated with the current JTA transaction, the container associates the entity manager with the current JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction. If there is a different persistence context already associated with the JTA transaction, the container throws the EJBException.
* When a business method of the stateful session bean is invoked, if the stateful session bean uses bean managed transaction demarcation and a UserTransaction is begun within the method, the container associates the persistence context with the JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction.
The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
[87] It is not required that these contracts be used when a third-party persistence provider is not used: the container might use these same APIs or its might use its own internal APIs.
[88] The container may choose to pool EntityManagers: it instead of creating and closing in each case, it may acquire one from its pool and call clear() on it.
{quote}
One challenge with introducing an entity manager (per EntityManagerFactory) cache, is knowing when to close EntityManagers after certain errors have occurred on the EntityManager. To deal with this robustness issue, we will discard entity managers that are marked close when retrieving them from the cache. To ensure that we always put the cached EM back in cache, EntityManagerCache use is only done within JTA transactions, since we have control of the release (closing) of the EntityManager and only with SynchronizationType.SYNCHRONIZED (never with SynchronizationType.UNSYNCHRONIZED) persistence contexts.
For this jira, the EntityManagerCache keeps strong references to the (cleared) EntityManager's from the cache. If this causes users OOM errors, we could consider using SOFT references so that the EntityManager's could be GCd in low memory conditions. We also offer users a choice between an unbounded cache (size=0) and a bounded cache. Users that have problems with OOM errors, should switch to a bounded cache.
Persistence unit hint "wildfly.jpa.emcache", may be:
* true, per EntityManagerFactory/persistence unit) cache that is shared between multiple threads.
* false (default), no caching is performed.
Persistence unit hint "wildfly.jpa.emcache.size", may be:
* 0 (default), the cache (if enabled) is unbounded.
* N, where N is the max number of EntityManager instances that can be placed in the EntityManagerCache, in between application use.
> allow EntityManager caching in the JPA container
> ------------------------------------------------
>
> Key: WFLY-11233
> URL: https://issues.jboss.org/browse/WFLY-11233
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Priority: Major
>
> The use case is to reduce the cost of Hibernate EntityManager creation/initialization, which could be more expensive for certain applications that use Hibernate extensions to perform additional processing at EntityManager creation time.
> Details from JPA 2.2 specification:
> {quote}
> 7.8 Requirements on the Container
> 7.8.1 Application-managed Persistence Contexts
> When application-managed persistence contexts are used, the container must instantiate the entity manager factory and expose it to the application via JNDI. The container might use internal APIs to create the entity manager factory, or it might use the PersistenceProvider.createContainerEntityManagerFactory method. However, the container is required to support third-party persistence providers, and in this case the container must use the PersistenceProvider.createContainerEntityManagerFactory method to create the entity manager factory and the EntityManagerFactory.close method to destroy the entity manager factory prior to shutdown (if it has not been previously closed by the application).
> 7.8.2 Container Managed Persistence Contexts
> The container is responsible for managing the lifecycle of container-managed persistence contexts, for injecting EntityManager references into web components and session bean and message-driven bean components, and for making EntityManager references available to direct lookups in JNDI. When operating with a third-party persistence provider, the container uses the contracts defined in section 7.9 to create and destroy container-managed persistence contexts. It is undefined whether a new entity manager instance is created for every persistence context, or whether entity manager instances are sometimes reused. Exactly how the container maintains the association between persistence context and JTA transaction is not defined. If a persistence context is already associated with a JTA transaction, the container uses that persistence context for subsequent invocations within the scope of that transaction, according to the semantics for persistence context propagation defined in section 7.6.4.
> 7.9 Runtime Contracts between the Container and Persistence Provider
> This section describes contracts between the container and the persistence provider for the pluggability of third-party persistence providers. Containers are required to support these pluggability contracts. [87]
> 7.9.1 Container Responsibilities
> For the management of a transaction-scoped persistence context, if there is no EntityManager already associated with the JTA transaction:
> * The container creates a new entity manager by calling EntityManagerFactory.createEntityManager when the first invocation of an entity manager with PersistenceContextType.TRANSACTION occurs within the scope of a business method executing in the JTA transaction.
> * After the JTA transaction has completed (either by transaction commit or rollback), the container closes the entity manager by calling EntityManager.close. [88] Note that the JTA transaction may rollback in a background thread (e.g., as a result of transaction timeout), in which case the container should arrange for the entity manager to be closed but the EntityManager.close method should not be concurrently invoked while the application is in an EntityManager invocation.
> The container must throw the TransactionRequiredException if a transaction-scoped persistence context is used and the EntityManager persist, remove, merge, or refresh method is invoked when no transaction is active.
> For stateful session beans with extended persistence contexts:
> * The container creates an entity manager by calling EntityManagerFactory.createEntityManager when a stateful session bean is created that declares a dependency on an entity manager with PersistenceContextType.EXTENDED. (See section 7.6.3).
> * The container closes the entity manager by calling EntityManager.close after the stateful session bean and all other stateful session beans that have inherited the same persistence context as the entity manager have been removed.
> * When a business method of the stateful session bean is invoked, if the stateful session bean uses container managed transaction demarcation, and the entity manager is not already associated with the current JTA transaction, the container associates the entity manager with the current JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction. If there is a different persistence context already associated with the JTA transaction, the container throws the EJBException.
> * When a business method of the stateful session bean is invoked, if the stateful session bean uses bean managed transaction demarcation and a UserTransaction is begun within the method, the container associates the persistence context with the JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction.
> The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
> [87] It is not required that these contracts be used when a third-party persistence provider is not used: the container might use these same APIs or its might use its own internal APIs.
> [88] The container may choose to pool EntityManagers: it instead of creating and closing in each case, it may acquire one from its pool and call clear() on it.
> {quote}
> This jira will specifically address transaction-scoped persistence contexts referenced in JTA transactions, as there is a known point of when they are no longer referenced and can be returned to the EntityManager cache. EntityManagers that are SynchronizationType.UNSYNCHRONIZED, will not be cached.
> Persistence unit hint "wildfly.jpa.emcache", may be:
> * true, per EntityManagerFactory/persistence unit) cache that is shared between multiple threads.
> * false (default), no caching is performed.
> Persistence unit hint "wildfly.jpa.emcache.size", may be:
> * 0 (default), the cache (if enabled) is unbounded. Performance may be better than bounded but will consume more memory.
> * N, where N is the bounded cache max size of EntityManager instances. Bounded cache will consume less memory but may incur more performance overhead (e.g. likely to use a contended synchronization lock).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFLY-11233) allow EntityManager caching in the JPA container
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-11233?page=com.atlassian.jira.plugin... ]
Scott Marlow reopened WFLY-11233:
---------------------------------
Assignee: Scott Marlow
> allow EntityManager caching in the JPA container
> ------------------------------------------------
>
> Key: WFLY-11233
> URL: https://issues.jboss.org/browse/WFLY-11233
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Priority: Major
>
> It could be interesting to see if caching EntityManager instances (per EntityManagerFactory) could improve performance for applications, that could benefit from that.
> The JPA 2.2 specification mentions the below, pay particular attention to the text "whether entity manager instances are sometimes reused" in section 7.8.2, also look at mention of [88]:
> {quote}
> 7.8 Requirements on the Container
> 7.8.1 Application-managed Persistence Contexts
> When application-managed persistence contexts are used, the container must instantiate the entity manager factory and expose it to the application via JNDI. The container might use internal APIs to create the entity manager factory, or it might use the PersistenceProvider.createContainerEntityManagerFactory method. However, the container is required to support third-party persistence providers, and in this case the container must use the PersistenceProvider.createContainerEntityManagerFactory method to create the entity manager factory and the EntityManagerFactory.close method to destroy the entity manager factory prior to shutdown (if it has not been previously closed by the application).
> 7.8.2 Container Managed Persistence Contexts
> The container is responsible for managing the lifecycle of container-managed persistence contexts, for injecting EntityManager references into web components and session bean and message-driven bean components, and for making EntityManager references available to direct lookups in JNDI. When operating with a third-party persistence provider, the container uses the contracts defined in section 7.9 to create and destroy container-managed persistence contexts. It is undefined whether a new entity manager instance is created for every persistence context, or whether entity manager instances are sometimes reused. Exactly how the container maintains the association between persistence context and JTA transaction is not defined. If a persistence context is already associated with a JTA transaction, the container uses that persistence context for subsequent invocations within the scope of that transaction, according to the semantics for persistence context propagation defined in section 7.6.4.
> 7.9 Runtime Contracts between the Container and Persistence Provider
> This section describes contracts between the container and the persistence provider for the pluggability of third-party persistence providers. Containers are required to support these pluggability contracts. [87]
> 7.9.1 Container Responsibilities
> For the management of a transaction-scoped persistence context, if there is no EntityManager already associated with the JTA transaction:
> * The container creates a new entity manager by calling EntityManagerFactory.createEntityManager when the first invocation of an entity manager with PersistenceContextType.TRANSACTION occurs within the scope of a business method executing in the JTA transaction.
> * After the JTA transaction has completed (either by transaction commit or rollback), the container closes the entity manager by calling EntityManager.close. [88] Note that the JTA transaction may rollback in a background thread (e.g., as a result of transaction timeout), in which case the container should arrange for the entity manager to be closed but the EntityManager.close method should not be concurrently invoked while the application is in an EntityManager invocation.
> The container must throw the TransactionRequiredException if a transaction-scoped persistence context is used and the EntityManager persist, remove, merge, or refresh method is invoked when no transaction is active.
> For stateful session beans with extended persistence contexts:
> * The container creates an entity manager by calling EntityManagerFactory.createEntityManager when a stateful session bean is created that declares a dependency on an entity manager with PersistenceContextType.EXTENDED. (See section 7.6.3).
> * The container closes the entity manager by calling EntityManager.close after the stateful session bean and all other stateful session beans that have inherited the same persistence context as the entity manager have been removed.
> * When a business method of the stateful session bean is invoked, if the stateful session bean uses container managed transaction demarcation, and the entity manager is not already associated with the current JTA transaction, the container associates the entity manager with the current JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction. If there is a different persistence context already associated with the JTA transaction, the container throws the EJBException.
> * When a business method of the stateful session bean is invoked, if the stateful session bean uses bean managed transaction demarcation and a UserTransaction is begun within the method, the container associates the persistence context with the JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction.
> The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
> [87] It is not required that these contracts be used when a third-party persistence provider is not used: the container might use these same APIs or its might use its own internal APIs.
> [88] The container may choose to pool EntityManagers: it instead of creating and closing in each case, it may acquire one from its pool and call clear() on it.
> {quote}
> One challenge with introducing an entity manager (per EntityManagerFactory) cache, is knowing when to close EntityManagers after certain errors have occurred on the EntityManager. To deal with this robustness issue, we will discard entity managers that are marked close when retrieving them from the cache. To ensure that we always put the cached EM back in cache, EntityManagerCache use is only done within JTA transactions, since we have control of the release (closing) of the EntityManager and only with SynchronizationType.SYNCHRONIZED (never with SynchronizationType.UNSYNCHRONIZED) persistence contexts.
> For this jira, the EntityManagerCache keeps strong references to the (cleared) EntityManager's from the cache. If this causes users OOM errors, we could consider using SOFT references so that the EntityManager's could be GCd in low memory conditions. We also offer users a choice between an unbounded cache (size=0) and a bounded cache. Users that have problems with OOM errors, should switch to a bounded cache.
> Persistence unit hint "wildfly.jpa.emcache", may be:
> * true, per EntityManagerFactory/persistence unit) cache that is shared between multiple threads.
> * false (default), no caching is performed.
> Persistence unit hint "wildfly.jpa.emcache.size", may be:
> * 0 (default), the cache (if enabled) is unbounded.
> * N, where N is the max number of EntityManager instances that can be placed in the EntityManagerCache, in between application use.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months