[JBoss JIRA] (WFLY-10736) Server in cluster hangs during start after previous kill
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10736?page=com.atlassian.jira.plugin... ]
Paul Ferraro commented on WFLY-10736:
-------------------------------------
[~tommaso-borgato] eap-7.2.0.CD14-20180815 is a week old. I was specifically asking about WF master, which contains clustering fixes not in that build.
> Server in cluster hangs during start after previous kill
> --------------------------------------------------------
>
> Key: WFLY-10736
> URL: https://issues.jboss.org/browse/WFLY-10736
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: Miroslav Novak
> Assignee: Paul Ferraro
> Priority: Blocker
> Labels: blocker-WF14
> Attachments: Lodh2TestCase.testRemoteJcaInboundOnly-traces.zip, Lodh2TestCase.testRemoteJcaInboundOnly.zip, clusterKilTest.zip, logs-with-workaround.zip, node-1-thread-dump-before-kill-shutdown-sequence.txt, server-with-mdb.log, standalone-full-ha-1.xml, standalone-full-ha-2.xml
>
>
> There is regression in JGroups or Infinispan in one of our tests for fault tolerance of JMS bridges. However work on JMS bridge appears to be unrelated. Issue was hit in WF weekly run.
> Test Scenario:
> * There are two servers. InQueue is deployed on Node 1,
> * OutQueue is deployed on Node 2. Both servers are started.
> * Large byte messages are sent to InQueue deployed on Node 1. Bridge between servers/queues transfers messages from node 1 to node 2.
> * Node 1 is killed and started again.
> * All messages are received from OutQueue deployed on Node 2.
> Result:
> Node 1 does not start after kill and hangs. There is following exception logged in node 2:
> {code}
> :26:17,894 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100000: Node node-1 joined the cluster
> 09:26:18,520 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN000094: Received new cluster view for channel ejb: [node-2|7] (2) [node-2, node-1]
> 09:26:18,521 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100001: Node node-1 left the cluster
> 09:26:18,521 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN000094: Received new cluster view for channel ejb: [node-2|7] (2) [node-2, node-1]
> 09:26:18,522 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100001: Node node-1 left the cluster
> 09:26:18,522 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN000094: Received new cluster view for channel ejb: [node-2|7] (2) [node-2, node-1]
> 09:26:18,522 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100001: Node node-1 left the cluster
> 09:26:18,522 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN000094: Received new cluster view for channel ejb: [node-2|7] (2) [node-2, node-1]
> 09:26:18,523 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100001: Node node-1 left the cluster
> 09:26:18,868 INFO [org.infinispan.CLUSTER] (remote-thread--p5-t2) ISPN000310: Starting cluster-wide rebalance for cache default, topology CacheTopology{id=17, phase=READ_OLD_WRITE_ALL, rebalanceId=6, currentCH=ReplicatedConsistentHash{ns = 256, owners = (2)[node-2: 122, node-1: 134]}, pendingCH=ReplicatedConsistentHash{ns = 256, owners = (3)[node-2: 84, node-1: 90, node-1: 82]}, unionCH=null, actualMembers=[node-2, node-1, node-1], persistentUUIDs=[12443bfb-e88a-46f3-919e-9213bf38ce19, 2873237f-d881-463f-8a5a-940bf1d764e5, a05ea8af-a83b-42a9-b937-dc2da1cae6d1]}
> 09:26:18,869 INFO [org.infinispan.CLUSTER] (remote-thread--p5-t2) [Context=default][Scope=node-2]ISPN100002: Started rebalance with topology id 17
> 09:26:18,870 INFO [org.infinispan.CLUSTER] (transport-thread--p14-t5) [Context=default][Scope=node-2]ISPN100003: Node node-2 finished rebalance phase with topology id 17
> 09:26:18,981 INFO [org.infinispan.CLUSTER] (remote-thread--p5-t2) [Context=default][Scope=node-1]ISPN100003: Node node-1 finished rebalance phase with topology id 17
> 09:27:18,530 WARN [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread--p15-t4) ISPN000197: Error updating cluster member list: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> Suppressed: java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357) [rt.jar:1.8.0_131]
> at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1915) [rt.jar:1.8.0_131]
> at org.infinispan.util.concurrent.CompletableFutures.await(CompletableFutures.java:82)
> at org.infinispan.remoting.transport.Transport.invokeRemotely(Transport.java:71)
> at org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:540)
> at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:523)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleClusterView(ClusterTopologyManagerImpl.java:334)
> at org.infinispan.topology.ClusterTopologyManagerImpl.access$500(ClusterTopologyManagerImpl.java:85)
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.lambda$handleViewChange$0(ClusterTopologyManagerImpl.java:745)
> at org.infinispan.executors.LimitedExecutor.runTasks(LimitedExecutor.java:144)
> at org.infinispan.executors.LimitedExecutor.access$100(LimitedExecutor.java:33)
> at org.infinispan.executors.LimitedExecutor$Runner.run(LimitedExecutor.java:174)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
> ... 1 more
> Caused by: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> ... 1 more
> [CIRCULAR REFERENCE:java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1]
> 09:27:18,530 WARN [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread--p16-t4) ISPN000197: Error updating cluster member list: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> Suppressed: java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357) [rt.jar:1.8.0_131]
> at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1915) [rt.jar:1.8.0_131]
> at org.infinispan.util.concurrent.CompletableFutures.await(CompletableFutures.java:82)
> at org.infinispan.remoting.transport.Transport.invokeRemotely(Transport.java:71)
> at org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:540)
> at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:523)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleClusterView(ClusterTopologyManagerImpl.java:334)
> at org.infinispan.topology.ClusterTopologyManagerImpl.access$500(ClusterTopologyManagerImpl.java:85)
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.lambda$handleViewChange$0(ClusterTopologyManagerImpl.java:745)
> at org.infinispan.executors.LimitedExecutor.runTasks(LimitedExecutor.java:144)
> at org.infinispan.executors.LimitedExecutor.access$100(LimitedExecutor.java:33)
> at org.infinispan.executors.LimitedExecutor$Runner.run(LimitedExecutor.java:174)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
> ... 1 more
> Caused by: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> ... 1 more
> [CIRCULAR REFERENCE:java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1]
> {code}
> There is default JGroups udp stack configured which is used by Infinispan. Both of the servers (jgroups udp) are bound to 127.0.0.1. Node 2 has port offset 1000.
> Attaching thread dump from node 1 when it hangs during start.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10904) Lower logging level of messages for OpenTracing
by Juraci Paixão Kröhling (JIRA)
[ https://issues.jboss.org/browse/WFLY-10904?page=com.atlassian.jira.plugin... ]
Juraci Paixão Kröhling commented on WFLY-10904:
-----------------------------------------------
The second message was greatly reduced by https://github.com/jaegertracing/jaeger-client-java/pull/528 . As part of WFLY-10877, I'm opening a PR to bump Jaeger to 0.30.5 (released a couple of minutes ago), which includes the mentioned PR. Do you think it would be enough? Otherwise, I think we may want to reduce them via the logging subsystem.
> Lower logging level of messages for OpenTracing
> -----------------------------------------------
>
> Key: WFLY-10904
> URL: https://issues.jboss.org/browse/WFLY-10904
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing
> Affects Versions: 14.0.0.Beta2
> Reporter: Jan Stourac
> Assignee: Juraci Paixão Kröhling
>
> Current logging for OpenTracing is quite verbose logging long messages in INFO level, e.g.:
> {code}
> 17:38:45,359 INFO [io.jaegertracing.internal.senders.SenderResolver] (ServerService Thread Pool -- 28) Using sender UdpSender(udpTransport=ThriftUdpTransport(socket=java.net.DatagramSocket@3e9a2205, receiveBuf=null, receiveOffSet=-1, receiveLength=0))
> 17:38:45,395 INFO [io.jaegertracing.Configuration] (ServerService Thread Pool -- 28) Initialized tracer=JaegerTracer(version=Java-0.30.4, serviceName=deployment.war, reporter=RemoteReporter(queueProcessor=RemoteReporter.QueueProcessor(open=true), sender=UdpSender(udpTransport=ThriftUdpTransport(socket=java.net.DatagramSocket@3e9a2205, receiveBuf=null, receiveOffSet=-1, receiveLength=0)), closeEnqueueTimeout=1000), sampler=RemoteControlledSampler(maxOperations=2000, serviceName=deployment.war, manager=HttpSamplingManager(gson={serializeNulls:false,factories:[Factory[typeHierarchy=com.google.gson.JsonElement,adapter=com.google.gson.internal.bind.TypeAdapters$29@5795d61d], com.google.gson.internal.bind.ObjectTypeAdapter$1@7286f924, com.google.gson.internal.Excluder@10bd7673, Factory[type=java.lang.String,adapter=com.google.gson.internal.bind.TypeAdapters$16@56577ab9], Factory[type=java.lang.Integer+int,adapter=com.google.gson.internal.bind.TypeAdapters$7@2f0b6b50], Factory[type=java.lang.Boolean+boolean,adapter=com.google.gson.internal.bind.TypeAdapters$3@6a01f84c], Factory[type=java.lang.Byte+byte,adapter=com.google.gson.internal.bind.TypeAdapters$5@11f41591], Factory[type=java.lang.Short+short,adapter=com.google.gson.internal.bind.TypeAdapters$6@7c9b37a4], Factory[type=java.lang.Long+long,adapter=com.google.gson.internal.bind.TypeAdapters$11@8be828c], Factory[type=java.lang.Double+double,adapter=com.google.gson.Gson$1@6d18d84f], Factory[type=java.lang.Float+float,adapter=com.google.gson.Gson$2@5c7110e0], Factory[type=java.lang.Number,adapter=com.google.gson.internal.bind.TypeAdapters$14@79f22add], Factory[type=java.util.concurrent.atomic.AtomicInteger,adapter=com.google.gson.TypeAdapter$1@5a47d8d], Factory[type=java.util.concurrent.atomic.AtomicBoolean,adapter=com.google.gson.TypeAdapter$1@2ed507d6], Factory[type=java.util.concurrent.atomic.AtomicLong,adapter=com.google.gson.TypeAdapter$1@7af7f4fc], Factory[type=java.util.concurrent.atomic.AtomicLongArray,adapter=com.google.gson.TypeAdapter$1@123b9dbd], Factory[type=java.util.concurrent.atomic.AtomicIntegerArray,adapter=com.google.gson.TypeAdapter$1@3455c262], Factory[type=java.lang.Character+char,adapter=com.google.gson.internal.bind.TypeAdapters$15@32b89889], Factory[type=java.lang.StringBuilder,adapter=com.google.gson.internal.bind.TypeAdapters$19@772dda36], Factory[type=java.lang.StringBuffer,adapter=com.google.gson.internal.bind.TypeAdapters$20@3935671b], Factory[type=java.math.BigDecimal,adapter=com.google.gson.internal.bind.TypeAdapters$17@23e9f48d], Factory[type=java.math.BigInteger,adapter=com.google.gson.internal.bind.TypeAdapters$18@55634ca9], Factory[type=java.net.URL,adapter=com.google.gson.internal.bind.TypeAdapters$21@4c06d059], Factory[type=java.net.URI,adapter=com.google.gson.internal.bind.TypeAdapters$22@5e997b7d], Factory[type=java.util.UUID,adapter=com.google.gson.internal.bind.TypeAdapters$24@3238a1bf], Factory[type=java.util.Currency,adapter=com.google.gson.TypeAdapter$1@7d71b555], Factory[type=java.util.Locale,adapter=com.google.gson.internal.bind.TypeAdapters$28@70f36ba], Factory[typeHierarchy=java.net.InetAddress,adapter=com.google.gson.internal.bind.TypeAdapters$23@12d8e7b5], Factory[type=java.util.BitSet,adapter=com.google.gson.TypeAdapter$1@659a9908], com.google.gson.internal.bind.DateTypeAdapter$1@153143f3, Factory[type=java.util.Calendar+java.util.GregorianCalendar,adapter=com.google.gson.internal.bind.TypeAdapters$27@6bf50d09], com.google.gson.internal.bind.TimeTypeAdapter$1@3e45ba8d, com.google.gson.internal.bind.SqlDateTypeAdapter$1@f262694, com.google.gson.internal.bind.TypeAdapters$26@1017c258, com.google.gson.internal.bind.ArrayTypeAdapter$1@53c90816, Factory[type=java.lang.Class,adapter=com.google.gson.TypeAdapter$1@40cb5130], com.google.gson.internal.bind.CollectionTypeAdapterFactory@7e67cd3b, com.google.gson.internal.bind.MapTypeAdapterFactory@504cd5ad, com.google.gson.internal.bind.JsonAdapterAnnotationTypeAdapterFactory@4b5efe0a, com.google.gson.internal.bind.TypeAdapters$30@51066480, com.google.gson.internal.bind.ReflectiveTypeAdapterFactory@11c8758e],instanceCreators:{}}, hostPort=localhost:5778), metrics=io.jaegertracing.internal.metrics.Metrics@279f3ba7, sampler=ProbabilisticSampler(positiveSamplingBoundary=9223372036854776, negativeSamplingBoundary=-9223372036854776, samplingRate=0.001, tags={sampler.type=probabilistic, sampler.param=0.001})), ipv4=2130706433, tags={hostname=rhel7-large-74052, jaeger.version=Java-0.30.4, ip=127.0.0.1}, zipkinSharedRpcSpan=false, baggageSetter=io.jaegertracing.internal.baggage.BaggageSetter@1b8d3ff0, expandExceptionLogs=false)
> {code}
> I think these messages are not useful on INFO level and should be lowered to either DEBUG or TRACE level.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10904) Lower logging level of messages for OpenTracing
by Jan Stourac (JIRA)
Jan Stourac created WFLY-10904:
----------------------------------
Summary: Lower logging level of messages for OpenTracing
Key: WFLY-10904
URL: https://issues.jboss.org/browse/WFLY-10904
Project: WildFly
Issue Type: Bug
Components: MP OpenTracing
Affects Versions: 14.0.0.Beta2
Reporter: Jan Stourac
Assignee: Juraci Paixão Kröhling
Current logging for OpenTracing is quite verbose logging long messages in INFO level, e.g.:
{code}
17:38:45,359 INFO [io.jaegertracing.internal.senders.SenderResolver] (ServerService Thread Pool -- 28) Using sender UdpSender(udpTransport=ThriftUdpTransport(socket=java.net.DatagramSocket@3e9a2205, receiveBuf=null, receiveOffSet=-1, receiveLength=0))
17:38:45,395 INFO [io.jaegertracing.Configuration] (ServerService Thread Pool -- 28) Initialized tracer=JaegerTracer(version=Java-0.30.4, serviceName=deployment.war, reporter=RemoteReporter(queueProcessor=RemoteReporter.QueueProcessor(open=true), sender=UdpSender(udpTransport=ThriftUdpTransport(socket=java.net.DatagramSocket@3e9a2205, receiveBuf=null, receiveOffSet=-1, receiveLength=0)), closeEnqueueTimeout=1000), sampler=RemoteControlledSampler(maxOperations=2000, serviceName=deployment.war, manager=HttpSamplingManager(gson={serializeNulls:false,factories:[Factory[typeHierarchy=com.google.gson.JsonElement,adapter=com.google.gson.internal.bind.TypeAdapters$29@5795d61d], com.google.gson.internal.bind.ObjectTypeAdapter$1@7286f924, com.google.gson.internal.Excluder@10bd7673, Factory[type=java.lang.String,adapter=com.google.gson.internal.bind.TypeAdapters$16@56577ab9], Factory[type=java.lang.Integer+int,adapter=com.google.gson.internal.bind.TypeAdapters$7@2f0b6b50], Factory[type=java.lang.Boolean+boolean,adapter=com.google.gson.internal.bind.TypeAdapters$3@6a01f84c], Factory[type=java.lang.Byte+byte,adapter=com.google.gson.internal.bind.TypeAdapters$5@11f41591], Factory[type=java.lang.Short+short,adapter=com.google.gson.internal.bind.TypeAdapters$6@7c9b37a4], Factory[type=java.lang.Long+long,adapter=com.google.gson.internal.bind.TypeAdapters$11@8be828c], Factory[type=java.lang.Double+double,adapter=com.google.gson.Gson$1@6d18d84f], Factory[type=java.lang.Float+float,adapter=com.google.gson.Gson$2@5c7110e0], Factory[type=java.lang.Number,adapter=com.google.gson.internal.bind.TypeAdapters$14@79f22add], Factory[type=java.util.concurrent.atomic.AtomicInteger,adapter=com.google.gson.TypeAdapter$1@5a47d8d], Factory[type=java.util.concurrent.atomic.AtomicBoolean,adapter=com.google.gson.TypeAdapter$1@2ed507d6], Factory[type=java.util.concurrent.atomic.AtomicLong,adapter=com.google.gson.TypeAdapter$1@7af7f4fc], Factory[type=java.util.concurrent.atomic.AtomicLongArray,adapter=com.google.gson.TypeAdapter$1@123b9dbd], Factory[type=java.util.concurrent.atomic.AtomicIntegerArray,adapter=com.google.gson.TypeAdapter$1@3455c262], Factory[type=java.lang.Character+char,adapter=com.google.gson.internal.bind.TypeAdapters$15@32b89889], Factory[type=java.lang.StringBuilder,adapter=com.google.gson.internal.bind.TypeAdapters$19@772dda36], Factory[type=java.lang.StringBuffer,adapter=com.google.gson.internal.bind.TypeAdapters$20@3935671b], Factory[type=java.math.BigDecimal,adapter=com.google.gson.internal.bind.TypeAdapters$17@23e9f48d], Factory[type=java.math.BigInteger,adapter=com.google.gson.internal.bind.TypeAdapters$18@55634ca9], Factory[type=java.net.URL,adapter=com.google.gson.internal.bind.TypeAdapters$21@4c06d059], Factory[type=java.net.URI,adapter=com.google.gson.internal.bind.TypeAdapters$22@5e997b7d], Factory[type=java.util.UUID,adapter=com.google.gson.internal.bind.TypeAdapters$24@3238a1bf], Factory[type=java.util.Currency,adapter=com.google.gson.TypeAdapter$1@7d71b555], Factory[type=java.util.Locale,adapter=com.google.gson.internal.bind.TypeAdapters$28@70f36ba], Factory[typeHierarchy=java.net.InetAddress,adapter=com.google.gson.internal.bind.TypeAdapters$23@12d8e7b5], Factory[type=java.util.BitSet,adapter=com.google.gson.TypeAdapter$1@659a9908], com.google.gson.internal.bind.DateTypeAdapter$1@153143f3, Factory[type=java.util.Calendar+java.util.GregorianCalendar,adapter=com.google.gson.internal.bind.TypeAdapters$27@6bf50d09], com.google.gson.internal.bind.TimeTypeAdapter$1@3e45ba8d, com.google.gson.internal.bind.SqlDateTypeAdapter$1@f262694, com.google.gson.internal.bind.TypeAdapters$26@1017c258, com.google.gson.internal.bind.ArrayTypeAdapter$1@53c90816, Factory[type=java.lang.Class,adapter=com.google.gson.TypeAdapter$1@40cb5130], com.google.gson.internal.bind.CollectionTypeAdapterFactory@7e67cd3b, com.google.gson.internal.bind.MapTypeAdapterFactory@504cd5ad, com.google.gson.internal.bind.JsonAdapterAnnotationTypeAdapterFactory@4b5efe0a, com.google.gson.internal.bind.TypeAdapters$30@51066480, com.google.gson.internal.bind.ReflectiveTypeAdapterFactory@11c8758e],instanceCreators:{}}, hostPort=localhost:5778), metrics=io.jaegertracing.internal.metrics.Metrics@279f3ba7, sampler=ProbabilisticSampler(positiveSamplingBoundary=9223372036854776, negativeSamplingBoundary=-9223372036854776, samplingRate=0.001, tags={sampler.type=probabilistic, sampler.param=0.001})), ipv4=2130706433, tags={hostname=rhel7-large-74052, jaeger.version=Java-0.30.4, ip=127.0.0.1}, zipkinSharedRpcSpan=false, baggageSetter=io.jaegertracing.internal.baggage.BaggageSetter@1b8d3ff0, expandExceptionLogs=false)
{code}
I think these messages are not useful on INFO level and should be lowered to either DEBUG or TRACE level.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10812) JDK11 Some security tests fail on closed channel exception
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-10812?page=com.atlassian.jira.plugin... ]
Jan Kalina edited comment on WFLY-10812 at 8/22/18 8:34 AM:
------------------------------------------------------------
WSTrustTestCase:
* in GenerateWSKeyStores need to use CN=localhost and add alternative name 127.0.0.1
* following "SSLHandshakeException: Invalid ECDH ServerKeyExchange signature": it looks {{testPicketLink}} breaks following {{testHolderOfKey}} - but only when {{-Dhttps.protocols=TLSv1.2}} (default) is used - ok for {{-Dhttps.protocols=TLSv1.1}} - looks like JDK issue
{code}
JAVA_HOME=/opt/jdk-11/ PATH=$JAVA_HOME/bin/:$PATH mvn test -Dsurefire.runOrder=alphabetical -Dtest=WSTrustTestCase#testPicketLink+testHolderOfKey -Dhttps.protocols=TLSv1.2
{code}
was (Author: honza889):
WSTrustTestCase:
* in GenerateWSKeyStores need to use CN=localhost and add alternative name 127.0.0.1
* still investigating "SSLHandshakeException: Invalid ECDH ServerKeyExchange signature": it looks {{testPicketLink}} breaks {{testHolderOfKey}} - probably incorrect clean up
{code}
JAVA_HOME=/opt/jdk-11/ PATH=$JAVA_HOME/bin/:$PATH mvn test -Dsurefire.runOrder=alphabetical -Dtest=WSTrustTestCase#testPicketLink+testHolderOfKey
{code}
> JDK11 Some security tests fail on closed channel exception
> ----------------------------------------------------------
>
> Key: WFLY-10812
> URL: https://issues.jboss.org/browse/WFLY-10812
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Richard Opalka
> Assignee: Jan Kalina
> Priority: Blocker
> Fix For: 14.0.0.CR1
>
>
> With latest JDK11 (build 11-ea+25) the following tests fail due to closed channel exception: modified:
> * testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/security/loginmodules/LdapExtLikeAdvancedLdapLMTestCase.java
> * testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/security/loginmodules/LdapExtLoginModuleTestCase.java
> * testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/security/loginmodules/LdapLoginModuleTestCase.java
> * testsuite/integration/elytron/src/test/java/org/wildfly/test/integration/elytron/ssl/UndertowTwoWaySslNeedClientAuthTestCase.java
> * testsuite/integration/iiop/src/test/java/org/jboss/as/test/iiopssl/basic/IIOPSslInvocationTestCase.java
> * testsuite/integration/manualmode/src/test/java/org/jboss/as/test/manualmode/security/OutboundLdapConnectionClientCertTestCase.java
> * testsuite/integration/manualmode/src/test/java/org/jboss/as/test/manualmode/security/OutboundLdapConnectionTestCase.java
> * testsuite/integration/manualmode/src/test/java/org/jboss/as/test/manualmode/web/ssl/CertificateRolesLoginModuleTestCase.java
> * testsuite/integration/manualmode/src/test/java/org/jboss/as/test/manualmode/web/ssl/DatabaseCertLoginModuleTestCase.java
> * testsuite/integration/manualmode/src/test/java/org/jboss/as/test/manualmode/web/ssl/HTTPSWebConnectorTestCase.java
> * testsuite/integration/ws/src/test/java/org/jboss/as/test/integration/ws/wsse/trust/WSTrustTestCase.java
> Is there a known SSL issue in JDK11? Could somebody from our security team investigate this issue?
> When these tests will start passing WF test suite will be passing 100% of tests on JDK11.
> Potential investigator from our security team may want to include this PR:
> https://github.com/wildfly/wildfly/pull/11499
> to fix known JDK11 issues.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months