[JBoss JIRA] (WFLY-13104) Extract microprofile-config galleon layer from observability.
by Ingo Weiss (Jira)
Ingo Weiss created WFLY-13104:
---------------------------------
Summary: Extract microprofile-config galleon layer from observability.
Key: WFLY-13104
URL: https://issues.redhat.com/browse/WFLY-13104
Project: WildFly
Issue Type: Task
Components: Build System
Affects Versions: 18.0.0.Final
Reporter: Ingo Weiss
Assignee: Paul Ferraro
Fix For: 19.0.0.Beta1
Some microprofile extensions only depend on microprofile-config and not health or metrics. Splitting this into a separate layer will accommodate layers for other microprofile specs.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13065) Options for reverse-proxy max-request-time and connection-idle-timeout are specified as seconds
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13065?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFLY-13065:
-----------------------------------------
A management API change requires a management API bump. I see no reason not to bump the XSD at the same time and add a default.
> Options for reverse-proxy max-request-time and connection-idle-timeout are specified as seconds
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-13065
> URL: https://issues.redhat.com/browse/WFLY-13065
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 19.0.0.Beta1
> Reporter: Ricardo Martin Camarero
> Assignee: Ricardo Martin Camarero
> Priority: Minor
>
> In the reverse-proxy configuration the options {{max-request-time}} and {{connection-idle-timeout}} are specified and managed as seconds in CLI, when they are really milliseconds in undertow.
> {noformat}
> /subsystem=undertow/configuration=handler/reverse-proxy=LBProxy:read-resource-description
> ...
> "connection-idle-timeout" => {
> "type" => INT,
> "description" => "The amount of time a connection can be idle before it will be closed. Connections will not time out
> once the pool size is down to the configured minimum (as configured by cached-connections-per-thread)",
> "expressions-allowed" => true,
> "required" => false,
> "nillable" => true,
> "default" => 60L,
> "unit" => "SECONDS",
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> },
> ...
> "max-request-time" => {
> "type" => INT,
> "description" => "The maximum time that a proxy request can be active for, before being killed",
> "expressions-allowed" => true,
> "required" => false,
> "nillable" => true,
> "default" => -1,
> "unit" => "SECONDS",
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> },
> ...
> {noformat}
> The class [ReverseProxyHandler|https://github.com/wildfly/wildfly/blob/master/undert...] just passes the value (no modification) to undertow and it's clearly millis in undertow, for example the [max-request-time|https://github.com/undertow-io/undertow/blob/master/core...].
> I has suffered this confusion myself doing some tests, I set 60 as the max request time, and it was too short in my env (because they are millis instead of seconds).
> We need to change description to millis to respect current configurations.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (JGRP-2453) Change default TOS for UDP
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2453?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2453:
---------------------------
Fix Version/s: 5.0
4.2.0
> Change default TOS for UDP
> --------------------------
>
> Key: JGRP-2453
> URL: https://issues.redhat.com/browse/JGRP-2453
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 4.1.9, 4.0.22
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0, 4.2.0
>
>
> The Linux kernel has some fairly sophisticated queueing disciplines like {{fq_codel}}, but the default one is {{pfifo_fast}}.
> {quote}
> pfifo_fast is like three tc-pfifo(8) queues side by side,
> where packets can be enqueued in any of the three bands based on
> their Type of Service bits or assigned priority.
> Not all three bands are dequeued simultaneously - as long as lower
> bands have traffic, higher bands are never dequeued. This can be used
> to prioritize interactive traffic or penalize 'lowest cost' traffic.
> ??[http://man7.org/linux/man-pages/man8/tc-pfifo_fast.8.html#ALGORITHM]??
> {quote}
> These are some examples of band mappings:
> {quote}
> {noformat}
> TOS Bits Means Linux Priority Band
> ------------------------------------------------------------
> 0x0 0 Normal Service 0 Best Effort 1
> 0x8 4 Maximize Throughput 2 Bulk 2
> 0x10 8 Minimize Delay 6 Interactive 0
> 0x18 12 mt+md 4 Int. Bulk 1
> {noformat}
> ??[http://man7.org/linux/man-pages/man8/tc-prio.8.html#QDISC_PARAMETERS]??
> {quote}
> By default {{UDP.tos="8"}}, which makes all UDP traffic go into band 2, lowest priority (bulk).
> {{FD_ALL}} and {{FD_ALL2}} heartbeats are {{UDP}} traffic, and in some of our benchmarks there is enough
> client-server traffic in band 1 to delay the FD_ALL heartbeats for more than 10 seconds.
> We could either set the default TOS to {{0}} (best effort), or {{0x18}} (maximize throughput + minimize delay), the result is the same: band 1.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (JGRP-2453) Change default TOS for UDP
by Dan Berindei (Jira)
Dan Berindei created JGRP-2453:
----------------------------------
Summary: Change default TOS for UDP
Key: JGRP-2453
URL: https://issues.redhat.com/browse/JGRP-2453
Project: JGroups
Issue Type: Enhancement
Affects Versions: 4.0.22, 4.1.9
Reporter: Dan Berindei
Assignee: Bela Ban
The Linux kernel has some fairly sophisticated queueing disciplines like {{fq_codel}}, but the default one is {{pfifo_fast}}.
{quote}
pfifo_fast is like three tc-pfifo(8) queues side by side,
where packets can be enqueued in any of the three bands based on
their Type of Service bits or assigned priority.
Not all three bands are dequeued simultaneously - as long as lower
bands have traffic, higher bands are never dequeued. This can be used
to prioritize interactive traffic or penalize 'lowest cost' traffic.
??[http://man7.org/linux/man-pages/man8/tc-pfifo_fast.8.html#ALGORITHM]??
{quote}
These are some examples of band mappings:
{quote}
{noformat}
TOS Bits Means Linux Priority Band
------------------------------------------------------------
0x0 0 Normal Service 0 Best Effort 1
0x8 4 Maximize Throughput 2 Bulk 2
0x10 8 Minimize Delay 6 Interactive 0
0x18 12 mt+md 4 Int. Bulk 1
{noformat}
??[http://man7.org/linux/man-pages/man8/tc-prio.8.html#QDISC_PARAMETERS]??
{quote}
By default {{UDP.tos="8"}}, which makes all UDP traffic go into band 2, lowest priority (bulk).
{{FD_ALL}} and {{FD_ALL2}} heartbeats are {{UDP}} traffic, and in some of our benchmarks there is enough
client-server traffic in band 1 to delay the FD_ALL heartbeats for more than 10 seconds.
We could either set the default TOS to {{0}} (best effort), or {{0x18}} (maximize throughput + minimize delay), the result is the same: band 1.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (JGRP-2452) UFC_NB/MFC_NB: blocks
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2452?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2452:
--------------------------------
Add {{unblock()}} which is called by {{stop()}}
> UFC_NB/MFC_NB: blocks
> ---------------------
>
> Key: JGRP-2452
> URL: https://issues.redhat.com/browse/JGRP-2452
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0, 4.2.0
>
>
> Despite having full credits and {{queuing==false}}, we have a sender thread blocking (see below).
> This can happen when a thread is queueing; when we stop the member, or a new view is installed, {{queueing}} is never set to false and the thread is never unblocked!
> {noformat}
> "jgroups-830,ma267mlvjdg021" #1394 prio=5 os_prio=0 tid=0x0000000004442000 nid=0x307c waiting on condition [0x00007fbda44be000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000005f2189da0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at org.jgroups.util.SizeBoundedQueue.add(SizeBoundedQueue.java:51)
> at org.jgroups.util.NonBlockingCredit.addToQueue(NonBlockingCredit.java:98)
> at org.jgroups.util.NonBlockingCredit.decrementIfEnoughCredits(NonBlockingCredit.java:58)
> at org.jgroups.protocols.UFC_NB.handleDownMessage(UFC_NB.java:87)
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:315)
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:309)
> at org.jgroups.protocols.FRAG3.down(FRAG3.java:145)
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:914)
> at org.jgroups.JChannel.down(JChannel.java:677)
> at org.jgroups.JChannel.send(JChannel.java:516)
> at org.jgroups.protocols.relay.Route.send(Route.java:42)
> at org.jgroups.protocols.relay.RELAY2.route(RELAY2.java:572)
> at org.jgroups.protocols.relay.RELAY2.down(RELAY2.java:425)
> at org.jgroups.stack.Protocol.down(Protocol.java:317)
> at org.jgroups.fork.ForkProtocol.down(ForkProtocol.java:42)
> at org.jgroups.fork.ForkProtocolStack.down(ForkProtocolStack.java:62)
> at org.jgroups.fork.ForkChannel.send(ForkChannel.java:222)
> at org.jgroups.fork.ForkChannel.send(ForkChannel.java:21)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.send(JGroupsTransport.java:1041)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.sendCommand(JGroupsTransport.java:998)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.backupRemotely(JGroupsTransport.java:329)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeXSite(RpcManagerImpl.java:414)
> at org.infinispan.xsite.BackupSenderImpl.backupCommand(BackupSenderImpl.java:250)
> at org.infinispan.xsite.BackupSenderImpl.backupWrite(BackupSenderImpl.java:201)
> at org.infinispan.interceptors.xsite.NonTransactionalBackupInterceptor.handleSingleKeyWriteReturn(NonTransactionalBackupInterceptor.java:144)
> at org.infinispan.interceptors.xsite.NonTransactionalBackupInterceptor$$Lambda$655/1680487200.accept(Unknown Source)
> at org.infinispan.interceptors.InvocationSuccessAction.apply(InvocationSuccessAction.java:22)
> at org.infinispan.interceptors.impl.QueueAsyncInvocationStage.invokeQueuedHandlers(QueueAsyncInvocationStage.java:118)
> at org.infinispan.interceptors.impl.QueueAsyncInvocationStage.accept(QueueAsyncInvocationStage.java:81)
> at org.infinispan.interceptors.impl.QueueAsyncInvocationStage.accept(QueueAsyncInvocationStage.java:30)
> at java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:760)
> at java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:736)
> at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> at org.infinispan.remoting.transport.AbstractRequest.complete(AbstractRequest.java:67)
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onResponse(MultiTargetRequest.java:102)
> at org.infinispan.remoting.transport.impl.RequestRepository.addResponse(RequestRepository.java:52)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.processResponse(JGroupsTransport.java:1361)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.processMessage(JGroupsTransport.java:1264)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.access$300(JGroupsTransport.java:127)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport$ChannelCallbacks.up(JGroupsTransport.java:1425)
> at org.jgroups.JChannel.up(JChannel.java:816)
> at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:134)
> at org.jgroups.stack.Protocol.up(Protocol.java:339)
> at org.jgroups.protocols.FORK.up(FORK.java:142)
> at org.jgroups.protocols.relay.RELAY2.up(RELAY2.java:452)
> at org.jgroups.protocols.FRAG3.up(FRAG3.java:171)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:339)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:339)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:872)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:240)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1008)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:734)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:389)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:590)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:203)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:253)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:280)
> at org.jgroups.protocols.Discovery.up(Discovery.java:295)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1250)
> at org.jgroups.util.SubmitToThreadPool$SingleMessageHandler.run(SubmitToThreadPool.java:87)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13103) Upgrade Smallrye Opentracing to 1.3.4
by Emmanuel Hugonnet (Jira)
[ https://issues.redhat.com/browse/WFLY-13103?page=com.atlassian.jira.plugi... ]
Emmanuel Hugonnet commented on WFLY-13103:
------------------------------------------
upgrade also eclipse opentracing-api to 1.3.3 (just some changes with some unused librairies: Remove io.opentracing:opentracing-api:0.31.0 and com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider:2.9.0 from the WAR file.
> Upgrade Smallrye Opentracing to 1.3.4
> --------------------------------------
>
> Key: WFLY-13103
> URL: https://issues.redhat.com/browse/WFLY-13103
> Project: WildFly
> Issue Type: Component Upgrade
> Components: MP OpenTracing
> Affects Versions: 19.0.0.Beta2
> Reporter: Emmanuel Hugonnet
> Assignee: Emmanuel Hugonnet
> Priority: Major
>
> Upgrade smallrye opentracing to 1.3.4 to have dependencies versions in sync with MP 3.3
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13103) Upgrade Smallrye Opentracing to 1.3.4
by Emmanuel Hugonnet (Jira)
Emmanuel Hugonnet created WFLY-13103:
----------------------------------------
Summary: Upgrade Smallrye Opentracing to 1.3.4
Key: WFLY-13103
URL: https://issues.redhat.com/browse/WFLY-13103
Project: WildFly
Issue Type: Component Upgrade
Components: MP OpenTracing
Affects Versions: 19.0.0.Beta2
Reporter: Emmanuel Hugonnet
Assignee: Emmanuel Hugonnet
Upgrade smallrye opentracing to 1.3.4 to have dependencies versions in sync with MP 3.3
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (JGRP-2452) UFC_NB/MFC_NB: blocks
by Bela Ban (Jira)
Bela Ban created JGRP-2452:
------------------------------
Summary: UFC_NB/MFC_NB: blocks
Key: JGRP-2452
URL: https://issues.redhat.com/browse/JGRP-2452
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 5.0, 4.2.0
Despite having full credits and {{queuing==false}}, we have a sender thread blocking (see below).
This can happen when a thread is queueing; when we stop the member, or a new view is installed, {{queueing}} is never set to false and the thread is never unblocked!
{noformat}
"jgroups-830,ma267mlvjdg021" #1394 prio=5 os_prio=0 tid=0x0000000004442000 nid=0x307c waiting on condition [0x00007fbda44be000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000005f2189da0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at org.jgroups.util.SizeBoundedQueue.add(SizeBoundedQueue.java:51)
at org.jgroups.util.NonBlockingCredit.addToQueue(NonBlockingCredit.java:98)
at org.jgroups.util.NonBlockingCredit.decrementIfEnoughCredits(NonBlockingCredit.java:58)
at org.jgroups.protocols.UFC_NB.handleDownMessage(UFC_NB.java:87)
at org.jgroups.protocols.FlowControl.down(FlowControl.java:315)
at org.jgroups.protocols.FlowControl.down(FlowControl.java:309)
at org.jgroups.protocols.FRAG3.down(FRAG3.java:145)
at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:914)
at org.jgroups.JChannel.down(JChannel.java:677)
at org.jgroups.JChannel.send(JChannel.java:516)
at org.jgroups.protocols.relay.Route.send(Route.java:42)
at org.jgroups.protocols.relay.RELAY2.route(RELAY2.java:572)
at org.jgroups.protocols.relay.RELAY2.down(RELAY2.java:425)
at org.jgroups.stack.Protocol.down(Protocol.java:317)
at org.jgroups.fork.ForkProtocol.down(ForkProtocol.java:42)
at org.jgroups.fork.ForkProtocolStack.down(ForkProtocolStack.java:62)
at org.jgroups.fork.ForkChannel.send(ForkChannel.java:222)
at org.jgroups.fork.ForkChannel.send(ForkChannel.java:21)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.send(JGroupsTransport.java:1041)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.sendCommand(JGroupsTransport.java:998)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.backupRemotely(JGroupsTransport.java:329)
at org.infinispan.remoting.rpc.RpcManagerImpl.invokeXSite(RpcManagerImpl.java:414)
at org.infinispan.xsite.BackupSenderImpl.backupCommand(BackupSenderImpl.java:250)
at org.infinispan.xsite.BackupSenderImpl.backupWrite(BackupSenderImpl.java:201)
at org.infinispan.interceptors.xsite.NonTransactionalBackupInterceptor.handleSingleKeyWriteReturn(NonTransactionalBackupInterceptor.java:144)
at org.infinispan.interceptors.xsite.NonTransactionalBackupInterceptor$$Lambda$655/1680487200.accept(Unknown Source)
at org.infinispan.interceptors.InvocationSuccessAction.apply(InvocationSuccessAction.java:22)
at org.infinispan.interceptors.impl.QueueAsyncInvocationStage.invokeQueuedHandlers(QueueAsyncInvocationStage.java:118)
at org.infinispan.interceptors.impl.QueueAsyncInvocationStage.accept(QueueAsyncInvocationStage.java:81)
at org.infinispan.interceptors.impl.QueueAsyncInvocationStage.accept(QueueAsyncInvocationStage.java:30)
at java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:760)
at java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:736)
at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
at org.infinispan.remoting.transport.AbstractRequest.complete(AbstractRequest.java:67)
at org.infinispan.remoting.transport.impl.MultiTargetRequest.onResponse(MultiTargetRequest.java:102)
at org.infinispan.remoting.transport.impl.RequestRepository.addResponse(RequestRepository.java:52)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.processResponse(JGroupsTransport.java:1361)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.processMessage(JGroupsTransport.java:1264)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.access$300(JGroupsTransport.java:127)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport$ChannelCallbacks.up(JGroupsTransport.java:1425)
at org.jgroups.JChannel.up(JChannel.java:816)
at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:134)
at org.jgroups.stack.Protocol.up(Protocol.java:339)
at org.jgroups.protocols.FORK.up(FORK.java:142)
at org.jgroups.protocols.relay.RELAY2.up(RELAY2.java:452)
at org.jgroups.protocols.FRAG3.up(FRAG3.java:171)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:339)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:339)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:872)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:240)
at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1008)
at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:734)
at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:389)
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:590)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131)
at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:203)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:253)
at org.jgroups.protocols.MERGE3.up(MERGE3.java:280)
at org.jgroups.protocols.Discovery.up(Discovery.java:295)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1250)
at org.jgroups.util.SubmitToThreadPool$SingleMessageHandler.run(SubmitToThreadPool.java:87)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months