[JBoss JIRA] (WFWIP-160) Fix throughput and response time differences between TLS 1.2 and TLS 1.3
by Jan Stourac (Jira)
[ https://issues.jboss.org/browse/WFWIP-160?page=com.atlassian.jira.plugin.... ]
Jan Stourac commented on WFWIP-160:
-----------------------------------
[~flavia.rainone], [~fjuma], any new information regarding to this one? Note that EAP7-1022 is currently planned for {{JBoss EAP 7.3.0.CD17}}.
> Fix throughput and response time differences between TLS 1.2 and TLS 1.3
> ------------------------------------------------------------------------
>
> Key: WFWIP-160
> URL: https://issues.jboss.org/browse/WFWIP-160
> Project: WildFly WIP
> Issue Type: Task
> Reporter: Farah Juma
> Assignee: Flavia Rainone
> Priority: Blocker
>
> Performance with TLS 1.3 on WildFly appears to be worse than with TLS 1.2. In particular, throughput is much lower (roughly three times lower) and response time is much higher (roughly three times higher), which is not supposed to be the case. The underlying issue seems to be in Undertow or XNIO, that is the code that actually gets invoked during the TLS handshake process. Looking at CPU time, there is significantly more time being spent in [io.undertow.protocols.ssl.SslConduit$5.run()|https://github.com/undertow-...] with TLS 1.3 than with TLS 1.2.
> Steps to reproduce (taken from EAP7-1022):
> 1. Build WildFly using the following feature branches or download a QE build of WildFly [here|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/undertow-...]:
> https://github.com/fjuma/wildfly-elytron/tree/ELY-1706
> https://github.com/fjuma/wildfly-core/tree/WFCORE-4172 (Update the Elytron version in the pom.xml file to use the version built in the previous step)
> https://github.com/fjuma/wildfly/tree/WFCORE-4172 (Update the Core version in the pom.xml file to use the version built in the previous step)
> 2. Download and unzip JMeter from https://jmeter.apache.org/download_jmeter.cgi
> 3. Download attached test plan [TLSv1.3.jmx|https://issues.jboss.org/secure/attachment/12449098/12449098_...]
> 4. Configure and start server with TLSv1.3 and JDK 11:
> {code}
> connect
> /subsystem=elytron/key-store=tls13:add(path=keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
> /subsystem=elytron/key-store=tls13:generate-key-pair(alias=localhost,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=localhost")
> /subsystem=elytron/key-store=tls13:store()
> /subsystem=elytron/key-manager=tls13:add(key-store=tls13,credential-reference={clear-text=secret})
> /subsystem=elytron/server-ssl-context=tls13:add(key-manager=tls13,protocols=["TLSv1.3"])
> batch
> /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
> /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=tls13)
> run-batch
> reload
> {code}
> 5. Start jmeter with JDK 11 and downloaded test plan
> {code}
> export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv13.log -o results-tlsv13
> {code}
> 6. Set server to use TLSv1.2
> {code}
> /subsystem=elytron/server-ssl-context=tls13:write-attribute(name=protocols,value=["TLSv1.2"])
> reload
> {code}
> 7. Repeat same for TLSv1.2
> {code}
> export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv12.log -o results-tlsv12
> {code}
> 8. Compare results (there will be an index.html file in the results-tlsv12 and results-tlsv13 directories)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (WFLY-11956) @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method
by Guillaume Smet (Jira)
[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ]
Guillaume Smet edited comment on WFLY-11956 at 4/25/19 3:35 AM:
----------------------------------------------------------------
[~ron_sigal] My understanding is that it's not the getter validation that is triggered. The field and getter form a unique validated entity called a property in HV.
When validating the bean in {{JaxrsInjectionTarget}}, you validate the bean itself and thus all its properties - so all the fields and getters. It is not method validation but property validation. That's why your configuration in the XML file is useless. Getters are already not validated methods by default. But... they are validated when you validate the properties of a bean.
I'm not sure I'm seeing an easy way to disable this behavior as doing it globally with a configuration knob seems a bit dangerous as it would also disable it for the domain objects.
We could probably imagine an entry point specific to {{JaxrsInjectionTarget}} to avoid validating the getters too but I'm not sure how dirty it would be and we would also probably need to keep the HV metadata generated by this entry point separate.
[~gunnar.morling] any thoughts on that? I'm surprised it only surfaces now tbh as it seems a potentially very common issue.
was (Author: guillaume.smet):
[~ron_sigal] My understanding is that it's not the getter validation that is triggered. The field and getter form a unique validated entity called a property in HV.
When validating the constructor of a bean, you validate the bean itself as the return value of the constructor and thus all its properties - so all the fields and getters. It is not method validation but property validation. That's why your configuration in the XML file is useless. Getters are already not validated methods by default. But... they are validated when you validate the properties of a bean.
I'm not sure I'm seeing an easy way to disable this behavior as doing it globally with a configuration knob seems a bit dangerous as it would also disable it for the domain objects.
We could probably imagine an entry point specific to CDI to avoid validating the getters too but I'm not sure how dirty it would be and we would also probably need to keep the HV metadata generated by this entry point separate.
[~gunnar.morling] any thoughts on that? I'm surprised it only surfaces now tbh as it seems a potentially very common issue.
> @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method
> ----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11956
> URL: https://issues.jboss.org/browse/WFLY-11956
> Project: WildFly
> Issue Type: Bug
> Components: Bean Validation, REST
> Affects Versions: 16.0.0.Final
> Reporter: Joerg Baesner
> Assignee: Ronald Sigal
> Priority: Major
> Attachments: logging.txt, playground.zip
>
>
> Having a bean class with {{@ApplicationScoped}}, which has a {{@PostConstruct}} and is implementing the following _Interface_:
> {code}
> @Path("/validated")
> public interface ValidatedJaxRsInterface {
>
> @GET
> @Valid
> @Produces(MediaType.APPLICATION_JSON)
> GreetingModel getHelloGreeting();
> }
> {code}
> will result in calling the {{getHelloGreeting}} method of the implementation class twice *_before_* the {{@PostConstruct}} is getting executed.
> This can be reproduced with the attached reproducer application...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (WFLY-11116) Wildfly 12.0.0 Final Delay in Getting the Value Attributes of the Session Variables (Result in Null Pointer Exception)
by ziad saade (Jira)
[ https://issues.jboss.org/browse/WFLY-11116?page=com.atlassian.jira.plugin... ]
ziad saade commented on WFLY-11116:
-----------------------------------
Dear Paul
Moreover on the above, I noticed from the console log of Wildfly that the operations are running in different threads:
1-Execute Method2() (*Task2*) (thread-1)
2-Execute Method3() (*Task2*) (thread-1)
3-Execute Stm1 (*Task2*) (thread-1)
4-Execute response.sendredirect("index.html"); (*Taks3*) (thread-2)
Best Regards
> Wildfly 12.0.0 Final Delay in Getting the Value Attributes of the Session Variables (Result in Null Pointer Exception)
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11116
> URL: https://issues.jboss.org/browse/WFLY-11116
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 14.0.1.Final, 12.0.0.Final, 13.0.0.Final, 15.0.0.Final
> Reporter: ziad saade
> Assignee: Paul Ferraro
> Priority: Critical
>
> I have two Servlets Book and BookPreview the attribute is set in Book Servlet as follow:
>
> Book.java
> TestBean testBean=null;
> if(session.getAttribute("testBean")!=null)
> testBean = (TestBean)session.getAttribute("testBean");
> else{
> testBean=new TestBean();
> session.setAttribute("testBean",testBean);
> }
> testBean.setAmount("10");
>
> response.sendRedirect("BookPreview");
>
>
> The session attribute can be retrieved and the page is loaded normally and the Amount value is displayed however when submitting the form (Post Action in BookPreview.java) Null Pointer exception is generated.
>
> BookPreview.java
>
> TestBean testBean = (TestBean)session.getAttribute("testBean");
> String amount = testBean.getAmount; //Null pointer exception when submitting the form
>
> <form method="Post" action="BookPreview">
>
> </form>
>
> TestBean.java
>
> public class TestBean implements java.io.Serializable {
>
> private static final long serialVersionUID = 1L;
> private String amount;
>
> public String getAmount() {
> return amount;
> }
>
> public void setAmount(String amount) {
> this.amount = amount;
> }
> }
>
> Kindly advice how to fix the problem at the level of the server configuration.
> PS: I am not getting the exception when deploying the same application under other J EE application servers (Tomcat....)
>
> Thanks and Best Regards
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (WFLY-11956) @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method
by Ronald Sigal (Jira)
[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ]
Ronald Sigal commented on WFLY-11956:
-------------------------------------
Thanks, [~guillaume.smet]. Yes, I see what I had wrong about getters. Hmm. Hmm.
Could we have a
{code}
<field-validation>
<do-not-validate>
<property class="ValidatedJaxRsInterface">helloGreeting</property>
</do-not-validate>
</field-validation>
{code}
in validation.xml that overrides the @Valid in
{code}
@GET
@Valid
@Produces(MediaType.APPLICATION_JSON)
GreetingModel getHelloGreeting();
{code}
Or, remember when we talked about fields and properties being the same? Maybe we could have something like
{code}
<property-validation>
<default-validated-property-types>
<property-type>FIELD</executable-type>
<property-type>GETTER</executable-type>
</default-validated-property-types>
</property-validation>
{code}
where we could leave out GETTER.
> @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method
> ----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11956
> URL: https://issues.jboss.org/browse/WFLY-11956
> Project: WildFly
> Issue Type: Bug
> Components: Bean Validation, REST
> Affects Versions: 16.0.0.Final
> Reporter: Joerg Baesner
> Assignee: Ronald Sigal
> Priority: Major
> Attachments: logging.txt, playground.zip
>
>
> Having a bean class with {{@ApplicationScoped}}, which has a {{@PostConstruct}} and is implementing the following _Interface_:
> {code}
> @Path("/validated")
> public interface ValidatedJaxRsInterface {
>
> @GET
> @Valid
> @Produces(MediaType.APPLICATION_JSON)
> GreetingModel getHelloGreeting();
> }
> {code}
> will result in calling the {{getHelloGreeting}} method of the implementation class twice *_before_* the {{@PostConstruct}} is getting executed.
> This can be reproduced with the attached reproducer application...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (WFLY-12014) Distributed session manager should not assume unmodifiable sets are immutable
by Paul Ferraro (Jira)
Paul Ferraro created WFLY-12014:
-----------------------------------
Summary: Distributed session manager should not assume unmodifiable sets are immutable
Key: WFLY-12014
URL: https://issues.jboss.org/browse/WFLY-12014
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 16.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
>From java.util.Set javadoc:
"Great care must be exercised if mutable objects are used as set elements. The behavior of a set is not specified if the value of an object is changed in a manner that affects equals comparisons while the object is an element in the set."
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (WFLY-11956) @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method
by Guillaume Smet (Jira)
[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ]
Guillaume Smet commented on WFLY-11956:
---------------------------------------
[~ron_sigal] My understanding is that it's not the getter validation that is triggered. The field and getter form a unique validated entity called a property in HV.
When validating the constructor of a bean, you validate the bean itself as the return value of the constructor and thus all its properties - so all the fields and getters. It is not method validation but property validation. That's why your configuration in the XML file is useless. Getters are already not validated methods by default. But... they are validated when you validate the properties of a bean.
I'm not sure I'm seeing an easy way to disable this behavior as doing it globally with a configuration knob seems a bit dangerous as it would also disable it for the domain objects.
We could probably imagine an entry point specific to CDI to avoid validating the getters too but I'm not sure how dirty it would be and we would also probably need to keep the HV metadata generated by this entry point separate.
[~gunnar.morling] any thoughts on that? I'm surprised it only surfaces now tbh as it seems a potentially very common issue.
> @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method
> ----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11956
> URL: https://issues.jboss.org/browse/WFLY-11956
> Project: WildFly
> Issue Type: Bug
> Components: Bean Validation, REST
> Affects Versions: 16.0.0.Final
> Reporter: Joerg Baesner
> Assignee: Ronald Sigal
> Priority: Major
> Attachments: logging.txt, playground.zip
>
>
> Having a bean class with {{@ApplicationScoped}}, which has a {{@PostConstruct}} and is implementing the following _Interface_:
> {code}
> @Path("/validated")
> public interface ValidatedJaxRsInterface {
>
> @GET
> @Valid
> @Produces(MediaType.APPLICATION_JSON)
> GreetingModel getHelloGreeting();
> }
> {code}
> will result in calling the {{getHelloGreeting}} method of the implementation class twice *_before_* the {{@PostConstruct}} is getting executed.
> This can be reproduced with the attached reproducer application...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (WFLY-11720) Cannot invoke EJB over HTTP on JDK 11
by Cheng Fang (Jira)
[ https://issues.jboss.org/browse/WFLY-11720?page=com.atlassian.jira.plugin... ]
Cheng Fang updated WFLY-11720:
------------------------------
Fix Version/s: 17.0.0.Beta1
> Cannot invoke EJB over HTTP on JDK 11
> -------------------------------------
>
> Key: WFLY-11720
> URL: https://issues.jboss.org/browse/WFLY-11720
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Remoting
> Affects Versions: 16.0.0.Beta1
> Environment: JDK 11
> Reporter: Jan Kasik
> Assignee: Cheng Fang
> Priority: Critical
> Fix For: 17.0.0.Beta1
>
> Attachments: classes.zip, client-app.zip
>
>
> Run of client app calling EJB over HTTP fails on JDK 11 with following log:
> {noformat}
> Feb 14, 2019 12:49:30 PM org.wildfly.naming.client.Version <clinit>
> INFO: WildFly Naming version 1.0.6.Final
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.wildfly.security.manager.GetAccessibleDeclaredFieldAction (file:/home/hudson/hudson_workspace/mod_cluster/client/wildfly-elytron-1.1.3.Final.jar) to field java.security.AccessControlContext.context
> WARNING: Please consider reporting this to the maintainers of org.wildfly.security.manager.GetAccessibleDeclaredFieldAction
> WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> Feb 14, 2019 12:49:30 PM org.wildfly.security.Version <clinit>
> INFO: ELY00001: WildFly Elytron version 1.1.3.Final
> Feb 14, 2019 12:49:30 PM org.jboss.ejb.client.EJBClient <clinit>
> INFO: JBoss EJB Client version 4.0.2.Final
> Feb 14, 2019 12:49:30 PM org.xnio.Xnio <clinit>
> INFO: XNIO version 3.6.5.Final
> Feb 14, 2019 12:49:30 PM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.6.5.Final
> Feb 14, 2019 12:49:30 PM org.jboss.threads.Version <clinit>
> INFO: JBoss Threads version 2.3.0.Beta2
> Feb 14, 2019 12:49:30 PM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 5.0.0.Final
> Feb 14, 2019 12:49:30 PM org.jboss.threads.LoggingUncaughtExceptionHandler uncaughtException
> ERROR: Thread Thread[XNIO-1 task-1,5,main] threw an uncaught exception
> java.lang.ExceptionInInitializerError
> at org.jboss.marshalling.river.RiverMarshaller.<clinit>(RiverMarshaller.java:1335)
> at org.jboss.marshalling.river.RiverMarshallerFactory.createMarshaller(RiverMarshallerFactory.java:54)
> at org.wildfly.httpclient.common.HttpTargetContext.createMarshaller(HttpTargetContext.java:132)
> at org.wildfly.httpclient.ejb.HttpEJBReceiver.marshalEJBRequest(HttpEJBReceiver.java:367)
> at org.wildfly.httpclient.ejb.HttpEJBReceiver.lambda$processInvocation$1(HttpEJBReceiver.java:185)
> at org.wildfly.httpclient.common.HttpTargetContext$1.lambda$completed$0(HttpTargetContext.java:338)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1871)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1400)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.IllegalStateException: No standard field found for reverse order comparator!
> at org.jboss.marshalling.river.Protocol.<clinit>(Protocol.java:287)
> ... 9 more
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (WFLY-11906) Managed Executor Task Fails with CDI if created from Batchlet
by Cheng Fang (Jira)
[ https://issues.jboss.org/browse/WFLY-11906?page=com.atlassian.jira.plugin... ]
Cheng Fang updated WFLY-11906:
------------------------------
Fix Version/s: 17.0.0.Beta1
> Managed Executor Task Fails with CDI if created from Batchlet
> -------------------------------------------------------------
>
> Key: WFLY-11906
> URL: https://issues.jboss.org/browse/WFLY-11906
> Project: WildFly
> Issue Type: Bug
> Components: Batch, CDI / Weld, Concurrency Utilities
> Affects Versions: 16.0.0.Final
> Environment: Java 8
> Reporter: Cody Lerum
> Assignee: Cheng Fang
> Priority: Major
> Fix For: 17.0.0.Beta1
>
>
> This previously was working (verified in reproducer) on Wildfly 14.0.1
> Inside of a batchlet if a Managed Executor Task is executed and that Task uses CDI.current() an exception is thrown
> {code:java}
> 11:00:02,343 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) java.lang.IllegalStateException: WFLYWELD0039: Singleton not set for ModuleClassLoader for Module "org.jboss.as.ee" version 16.0.0.Final from local module loader @78e94dcf (finder: local module finder @233fe9b6 (roots: V:\opt\wildfly-16.0.0.Final\modules,V:\opt\wildfly-16.0.0.Final\modules\system\layers\base)). This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> 11:00:02,344 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:77)
> 11:00:02,344 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:134)
> 11:00:02,344 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.weld.Container.instance(Container.java:57)
> 11:00:02,344 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.as.weld.WeldProvider.getCDI(WeldProvider.java:69)
> 11:00:02,344 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at javax.enterprise.inject.spi.CDI.lambda$getCDIProvider$0(CDI.java:87)
> 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:174)
> 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.TreeMap$KeySpliterator.tryAdvance(TreeMap.java:2770)
> 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:126)
> 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:498)
> 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:485)
> 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.FindOps$FindOp.evaluateSequential(FindOps.java:152)
> 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.ReferencePipeline.findFirst(ReferencePipeline.java:464)
> 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at javax.enterprise.inject.spi.CDI.getCDIProvider(CDI.java:88)
> 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at javax.enterprise.inject.spi.CDI.current(CDI.java:64)
> 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at com.outjected.demo.DemoTask.run(DemoTask.java:27)
> 11:00:02,347 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.as.ee.concurrent.ControlPointUtils$ControlledRunnable.run(ControlPointUtils.java:105)
> 11:00:02,347 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 11:00:02,347 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:266)
> 11:00:02,347 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.concurrent.FutureTask.run(FutureTask.java)
> 11:00:02,348 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.glassfish.enterprise.concurrent.internal.ManagedFutureTask.run(ManagedFutureTask.java:141)
> 11:00:02,348 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 11:00:02,348 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 11:00:02,348 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.lang.Thread.run(Thread.java:748)
> 11:00:02,349 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250)
> 11:00:02,349 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.as.ee.concurrent.service.ElytronManagedThreadFactory$ElytronManagedThread.run(ElytronManagedThreadFactory.java:85)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months