[JBoss JIRA] (WFLY-13444) Observing High CPU in EPollArrayWrapper.epollCtl default I/O thread
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-13444?page=com.atlassian.jira.plugi... ]
Paul Ferraro reassigned WFLY-13444:
-----------------------------------
Assignee: Flavia Rainone (was: Paul Ferraro)
> Observing High CPU in EPollArrayWrapper.epollCtl default I/O thread
> -------------------------------------------------------------------
>
> Key: WFLY-13444
> URL: https://issues.redhat.com/browse/WFLY-13444
> Project: WildFly
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 10.1.0.Final
> Reporter: Srinivas ev
> Assignee: Flavia Rainone
> Priority: Blocker
> Attachments: IO thread memory.PNG, IO thread.PNG, Thread consuming high CPU.PNG, ThreadDump1set.zip, ThreadDump2set.zip, default IO thread 73.PNG, stack trace from snapshot.PNG, stack trace in thread dump.PNG, top command output.PNG
>
>
> Facing high CPU by one of the default I/O thread In Wildfly 10.1.0 Final. Looks none of our application component thread is consuming.
> Can somebody check what is triggering this issue? I attached the thread stack to this Jira. This is blocking our releases. When the CPU cores are high in number, multiple default I/O threads will kick in consuming the CPU in 90~100% range continuously.
> Wildfly 10.1.0 Final
> Java -
> openjdk version "1.8.0_232"
> OpenJDK Runtime Environment (build 1.8.0_232-b09)
> OpenJDK 64-Bit Server VM (build 25.232-b09, mixed mode
> ---------------------------------------------------------------------------------------------------
> at java.lang.Throwable.fillInStackTrace(Native Method)
> at java.lang.Throwable.fillInStackTrace(Throwable.java:784)
> at java.lang.Throwable.<init>(Throwable.java:251)
> at java.lang.Exception.<init>(Exception.java:54)
> at java.io.IOException.<init>(IOException.java:47)
> at java.nio.channels.ClosedChannelException.<init>(ClosedChannelException.java:52)
> at org.xnio.ssl.JsseStreamConduit.write(JsseStreamConduit.java:1022)
> at org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:385)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:372)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
> at org.xnio.ssl.JsseStreamConduit.run(JsseStreamConduit.java:393)
> at org.xnio.ssl.JsseStreamConduit.readReady(JsseStreamConduit.java:547)
> at org.xnio.ssl.JsseStreamConduit$2.readReady(JsseStreamConduit.java:319)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:567)
> -------------------------------------------------------------------------------------------
> at sun.nio.ch.EPollArrayWrapper.epollCtl(Native Method)
> at sun.nio.ch.EPollArrayWrapper.updateRegistrations(EPollArrayWrapper.java:299)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:268)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:515)
> -----------------------------------------------------------------------------------
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13444) Observing High CPU in EPollArrayWrapper.epollCtl default I/O thread
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-13444?page=com.atlassian.jira.plugi... ]
Paul Ferraro updated WFLY-13444:
--------------------------------
Component/s: Remoting
(was: Clustering)
(was: IO)
> Observing High CPU in EPollArrayWrapper.epollCtl default I/O thread
> -------------------------------------------------------------------
>
> Key: WFLY-13444
> URL: https://issues.redhat.com/browse/WFLY-13444
> Project: WildFly
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 10.1.0.Final
> Reporter: Srinivas ev
> Assignee: Paul Ferraro
> Priority: Blocker
> Attachments: IO thread memory.PNG, IO thread.PNG, Thread consuming high CPU.PNG, ThreadDump1set.zip, ThreadDump2set.zip, default IO thread 73.PNG, stack trace from snapshot.PNG, stack trace in thread dump.PNG, top command output.PNG
>
>
> Facing high CPU by one of the default I/O thread In Wildfly 10.1.0 Final. Looks none of our application component thread is consuming.
> Can somebody check what is triggering this issue? I attached the thread stack to this Jira. This is blocking our releases. When the CPU cores are high in number, multiple default I/O threads will kick in consuming the CPU in 90~100% range continuously.
> Wildfly 10.1.0 Final
> Java -
> openjdk version "1.8.0_232"
> OpenJDK Runtime Environment (build 1.8.0_232-b09)
> OpenJDK 64-Bit Server VM (build 25.232-b09, mixed mode
> ---------------------------------------------------------------------------------------------------
> at java.lang.Throwable.fillInStackTrace(Native Method)
> at java.lang.Throwable.fillInStackTrace(Throwable.java:784)
> at java.lang.Throwable.<init>(Throwable.java:251)
> at java.lang.Exception.<init>(Exception.java:54)
> at java.io.IOException.<init>(IOException.java:47)
> at java.nio.channels.ClosedChannelException.<init>(ClosedChannelException.java:52)
> at org.xnio.ssl.JsseStreamConduit.write(JsseStreamConduit.java:1022)
> at org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:385)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:372)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
> at org.xnio.ssl.JsseStreamConduit.run(JsseStreamConduit.java:393)
> at org.xnio.ssl.JsseStreamConduit.readReady(JsseStreamConduit.java:547)
> at org.xnio.ssl.JsseStreamConduit$2.readReady(JsseStreamConduit.java:319)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:567)
> -------------------------------------------------------------------------------------------
> at sun.nio.ch.EPollArrayWrapper.epollCtl(Native Method)
> at sun.nio.ch.EPollArrayWrapper.updateRegistrations(EPollArrayWrapper.java:299)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:268)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:515)
> -----------------------------------------------------------------------------------
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13456) Readme for microprofile-openapi QS is WildFly specific and does not work for EAP
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-13456?page=com.atlassian.jira.plugi... ]
Paul Ferraro commented on WFLY-13456:
-------------------------------------
[~emmartins] There are no references to "WildFly" in the MicroProfile OpenAPI README.adoc.
> Readme for microprofile-openapi QS is WildFly specific and does not work for EAP
> --------------------------------------------------------------------------------
>
> Key: WFLY-13456
> URL: https://issues.redhat.com/browse/WFLY-13456
> Project: WildFly
> Issue Type: Bug
> Components: Quickstarts
> Affects Versions: 19.1.0.Final
> Reporter: Eduardo Martins
> Assignee: Paul Ferraro
> Priority: Blocker
>
> The QS is included in EAP XP Quickstarts ZIP, but its instructions are WildFly specific.
> (1) Use of WildFly instead of EAP on several places, e.g. title "Using MicroProfile OpenAPI in WildFly", introduction "This guide demonstrate how to use the MicroProfile OpenAPI functionality in WildFly" etc.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13459) Remote Naming bind / rebind / unbind / rename / createSubcontext / destroySubcontext does not throw exception back to client
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13459?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFLY-13459:
-----------------------------------------
Note that if you use HTTP...
{code}
props.put(Context.PROVIDER_URL, String.format("%s://%s:%d/wildfly-services", "http", host, port));
{code}
... then you do get a NamingException on client side:
{code}
Exception in thread "main" javax.naming.NamingException [Root exception is java.io.IOException: WFHTTP000005: Invalid response code 500 (full response ClientResponse{responseHeaders={content-type=[text/html], content-length=[2480], date=[Tue, 12 May 2020 20:55:10 GMT]}, responseCode=500, status='', protocol=HTTP/2.0})]
at org.wildfly.httpclient.naming.HttpRootContext.performOperation(HttpRootContext.java:442)
at org.wildfly.httpclient.naming.HttpRootContext.lambda$processInvocation$4(HttpRootContext.java:383)
at org.wildfly.httpclient.naming.HttpRootContext.performWithRetry(HttpRootContext.java:182)
at org.wildfly.httpclient.naming.HttpRootContext.processInvocation(HttpRootContext.java:364)
at org.wildfly.httpclient.naming.HttpRootContext.rebindNative(HttpRootContext.java:146)
at org.wildfly.naming.client.AbstractContext.rebind(AbstractContext.java:154)
at org.wildfly.naming.client.AbstractContext.rebind(AbstractContext.java:152)
at org.wildfly.naming.client.WildFlyRootContext.rebind(WildFlyRootContext.java:195)
at java.naming/javax.naming.InitialContext.rebind(InitialContext.java:425)
at org.example.Test.main(Test.java:47)
Caused by: java.io.IOException: WFHTTP000005: Invalid response code 500 (full response ClientResponse{responseHeaders={content-type=[text/html], content-length=[2480], date=[Tue, 12 May 2020 20:55:10 GMT]}, responseCode=500, status='', protocol=HTTP/2.0})
at org.wildfly.httpclient.common.HttpTargetContext$1$1.lambda$completed$4(HttpTargetContext.java:234)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at java.base/java.lang.Thread.run(Thread.java:834)
{code}
It hides any information about the server side fault though.
> Remote Naming bind / rebind / unbind / rename / createSubcontext / destroySubcontext does not throw exception back to client
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13459
> URL: https://issues.redhat.com/browse/WFLY-13459
> Project: WildFly
> Issue Type: Bug
> Components: Naming
> Affects Versions: 19.1.0.Final
> Reporter: Brad Maxwell
> Assignee: Sudeshna Sur
> Priority: Minor
> Attachments: Client.java, server.log.gz
>
>
> The Remote Naming (JNDI) is Read-Only, remote clients cannot bind or rebind objects into it. Only applications running in the same JVM can bind values into JNDI.
> It looks like the server side logs the warning, but the client does not get an exception thrown back, bind and rebind should throw some javax.naming.NamingException since the bind/rebind operations are failing.
> {code}
> public static void main(String[] args) throws Exception {
> Context ctx = getInitialContext("localhost", 8080, "admin", "redhat1!");
> ctx.bind("java:/reproducer", "reproducer");
> ctx.rebind("java:/reproducer", "reproducer");
> }
> public static Context getInitialContext(String host, Integer port, String username, String password) throws NamingException {
> Properties props = new Properties();
> props.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
> props.put(Context.PROVIDER_URL, String.format("%s://%s:%d", "remote+http", host, port));
> if(username != null && password != null) {
> props.put(Context.SECURITY_PRINCIPAL, username);
> props.put(Context.SECURITY_CREDENTIALS, password);
> }
> return new InitialContext(props);
> }
> {code}
> {code}
> 13:20:22,804 WARN [org.wildfly.naming] (default task-2) WFNAM00036: Unexpected internal error: java.lang.UnsupportedOperationException: WFLYNAM0043: Naming context is read-only
> at org.jboss.as.naming.WritableServiceBasedNamingStore.requireOwner(WritableServiceBasedNamingStore.java:160)
> at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(WritableServiceBasedNamingStore.java:66)
> at org.jboss.as.naming.NamingContext.bind(NamingContext.java:262)
> at org.jboss.as.naming.NamingContext.bind(NamingContext.java:289)
> at org.wildfly.naming.client.remote.RemoteServerTransport.handleBind(RemoteServerTransport.java:238)
> at org.wildfly.naming.client.remote.RemoteServerTransport$1.handleMessage(RemoteServerTransport.java:126)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:991)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> 13:20:22,813 WARN [org.wildfly.naming] (default task-2) WFNAM00036: Unexpected internal error: java.lang.UnsupportedOperationException: WFLYNAM0043: Naming context is read-only
> at org.jboss.as.naming.WritableServiceBasedNamingStore.requireOwner(WritableServiceBasedNamingStore.java:160)
> at org.jboss.as.naming.WritableServiceBasedNamingStore.rebind(WritableServiceBasedNamingStore.java:108)
> at org.jboss.as.naming.NamingContext.rebind(NamingContext.java:301)
> at org.jboss.as.naming.NamingContext.rebind(NamingContext.java:309)
> at org.wildfly.naming.client.remote.RemoteServerTransport.handleBind(RemoteServerTransport.java:236)
> at org.wildfly.naming.client.remote.RemoteServerTransport$1.handleMessage(RemoteServerTransport.java:129)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:991)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13460) Skip mutability check for array attribute values
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-13460?page=com.atlassian.jira.plugi... ]
Paul Ferraro updated WFLY-13460:
--------------------------------
Description: Since arrays are inherently mutable if their length is > 0, and immutable when zero length, we can skip the bulk of the mutability test for these session attributes. (was: Since non-zero length arrays are inherently mutable, we can skip the bulk of the mutability test for these session attributes.)
> Skip mutability check for array attribute values
> ------------------------------------------------
>
> Key: WFLY-13460
> URL: https://issues.redhat.com/browse/WFLY-13460
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 19.1.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
>
> Since arrays are inherently mutable if their length is > 0, and immutable when zero length, we can skip the bulk of the mutability test for these session attributes.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13460) Skip mutability check for array attribute values
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-13460?page=com.atlassian.jira.plugi... ]
Paul Ferraro updated WFLY-13460:
--------------------------------
Description: Since non-zero length arrays are inherently mutable, we can skip the bulk of the mutability test for these session attributes. (was: Since arrays are inherently mutable, we can skip the bulk of the mutability test for these session attributes.)
> Skip mutability check for array attribute values
> ------------------------------------------------
>
> Key: WFLY-13460
> URL: https://issues.redhat.com/browse/WFLY-13460
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 19.1.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
>
> Since non-zero length arrays are inherently mutable, we can skip the bulk of the mutability test for these session attributes.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13459) Remote Naming bind / rebind / unbind / rename / createSubcontext / destroySubcontext does not throw exception back to client
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13459?page=com.atlassian.jira.plugi... ]
Cheng Fang commented on WFLY-13459:
-----------------------------------
This requirement is in EE Platform spec: EE.5.3.4 Java EE Product Provider’s Responsibilities
{quote}
The container must ensure that the application component instances have only read access to their naming context. The container must throw the javax.naming.OperationNotSupportedException from all the methods of the javax.naming.Context interface that modify the environment naming context and its subcontexts.
{quote}
> Remote Naming bind / rebind / unbind / rename / createSubcontext / destroySubcontext does not throw exception back to client
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13459
> URL: https://issues.redhat.com/browse/WFLY-13459
> Project: WildFly
> Issue Type: Bug
> Components: Naming
> Affects Versions: 19.1.0.Final
> Reporter: Brad Maxwell
> Assignee: Sudeshna Sur
> Priority: Minor
> Attachments: Client.java, server.log.gz
>
>
> The Remote Naming (JNDI) is Read-Only, remote clients cannot bind or rebind objects into it. Only applications running in the same JVM can bind values into JNDI.
> It looks like the server side logs the warning, but the client does not get an exception thrown back, bind and rebind should throw some javax.naming.NamingException since the bind/rebind operations are failing.
> {code}
> public static void main(String[] args) throws Exception {
> Context ctx = getInitialContext("localhost", 8080, "admin", "redhat1!");
> ctx.bind("java:/reproducer", "reproducer");
> ctx.rebind("java:/reproducer", "reproducer");
> }
> public static Context getInitialContext(String host, Integer port, String username, String password) throws NamingException {
> Properties props = new Properties();
> props.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
> props.put(Context.PROVIDER_URL, String.format("%s://%s:%d", "remote+http", host, port));
> if(username != null && password != null) {
> props.put(Context.SECURITY_PRINCIPAL, username);
> props.put(Context.SECURITY_CREDENTIALS, password);
> }
> return new InitialContext(props);
> }
> {code}
> {code}
> 13:20:22,804 WARN [org.wildfly.naming] (default task-2) WFNAM00036: Unexpected internal error: java.lang.UnsupportedOperationException: WFLYNAM0043: Naming context is read-only
> at org.jboss.as.naming.WritableServiceBasedNamingStore.requireOwner(WritableServiceBasedNamingStore.java:160)
> at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(WritableServiceBasedNamingStore.java:66)
> at org.jboss.as.naming.NamingContext.bind(NamingContext.java:262)
> at org.jboss.as.naming.NamingContext.bind(NamingContext.java:289)
> at org.wildfly.naming.client.remote.RemoteServerTransport.handleBind(RemoteServerTransport.java:238)
> at org.wildfly.naming.client.remote.RemoteServerTransport$1.handleMessage(RemoteServerTransport.java:126)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:991)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> 13:20:22,813 WARN [org.wildfly.naming] (default task-2) WFNAM00036: Unexpected internal error: java.lang.UnsupportedOperationException: WFLYNAM0043: Naming context is read-only
> at org.jboss.as.naming.WritableServiceBasedNamingStore.requireOwner(WritableServiceBasedNamingStore.java:160)
> at org.jboss.as.naming.WritableServiceBasedNamingStore.rebind(WritableServiceBasedNamingStore.java:108)
> at org.jboss.as.naming.NamingContext.rebind(NamingContext.java:301)
> at org.jboss.as.naming.NamingContext.rebind(NamingContext.java:309)
> at org.wildfly.naming.client.remote.RemoteServerTransport.handleBind(RemoteServerTransport.java:236)
> at org.wildfly.naming.client.remote.RemoteServerTransport$1.handleMessage(RemoteServerTransport.java:129)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:991)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13256) Upgrade bouncycastle to 1.65.0
by Ashley Abdel-Sayed (Jira)
[ https://issues.redhat.com/browse/WFLY-13256?page=com.atlassian.jira.plugi... ]
Ashley Abdel-Sayed commented on WFLY-13256:
-------------------------------------------
[~brian.stansberry] Yes, looks like the ws integration testsuite passes with both the order fixed and ignoring {{AuthenticationPolicyContextTestCase}}. Do you think that's enough to indicate that PicketLink is the problem and we can use that as a workaround so the tests pass on JDK13?
> Upgrade bouncycastle to 1.65.0
> ------------------------------
>
> Key: WFLY-13256
> URL: https://issues.redhat.com/browse/WFLY-13256
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Build System, Server
> Reporter: Bartosz Spyrko-Smietanko
> Assignee: Brian Stansberry
> Priority: Blocker
> Labels: downstream_dependency
> Fix For: 20.0.0.Beta1
>
> Attachments: handshake-error.log, handshake-success.log
>
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13460) Skip mutability check for array attribute values
by Paul Ferraro (Jira)
Paul Ferraro created WFLY-13460:
-----------------------------------
Summary: Skip mutability check for array attribute values
Key: WFLY-13460
URL: https://issues.redhat.com/browse/WFLY-13460
Project: WildFly
Issue Type: Enhancement
Components: Clustering
Affects Versions: 19.1.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Since arrays are inherently mutable, we can skip the bulk of the mutability test for these session attributes.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months