Uploaded image for project: 'Infinispan'
  1. Infinispan
  2. ISPN-12597

Disable JGroups error JGRP000006 stacktrace when configuring xsite on OCP and AWS LB

    XMLWordPrintable

Details

    • Undefined

    Description

      When configuring Cross-Site on OCP with operator and LoadBalancer on AWS (probably, will occurs on Azure and others cloud platforms) there are a large number of stack traces places inside Pod logs

       

      07:51:13,524 WARN (TcpServer.Acceptor[7900]-2,relay-global,_example-infinispan-1-11053:site1) [org.jgroups.protocols.TCP] JGRP000006: failed accepting connection from peer Socket[addr=/10.131.0.1,port=11781,localport=7900]: java.io.EOFException java.io.EOFException     at java.base/java.io.DataInputStream.readFully(DataInputStream.java:202)     at org.jgroups.blocks.cs.TcpConnection.readPeerAddress(TcpConnection.java:247)     at org.jgroups.blocks.cs.TcpConnection.<init>(TcpConnection.java:53)     at org.jgroups.blocks.cs.TcpServer$Acceptor.handleAccept(TcpServer.java:126)     at org.jgroups.blocks.cs.TcpServer$Acceptor.run(TcpServer.java:111)     at java.base/java.lang.Thread.run(Thread.java:834)

      The reason of this logs that's AWS/OCP pings LoadBalancer with probe each time with interval. No the same errors while internal (Service) cross-site configuration was made.

      It would be nice to have an option to disable this kind of traces probably for LB configuration only, as customers confusing this traces as a problem

       

      Attachments

        Issue Links

          is related to

          Enhancement - An enhancement to or refactoring of existing functionality that is not configurable by an end user (typically a change made by an internal team that affects users) JGRP-2540 Disable logging when accept connection fails

          • Minor - To be worked after urgent, high, and medium priorities are resolved. This term is chosen when the severity of the issue is low, or the complexity or effort to correct it may be higher, relatively speaking. For low priority issues, known workarounds exist or are not needed due to the trivial effort needed to address the issue.
          • Resolved

          Activity

            People

              pruivo@redhat.com Pedro Ruivo
              dvolodin@redhat.com Dmitry Volodin (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated: