[JBoss JIRA] (JGRP-2485) UDP is not working after upgarde to 3_6_19 from jgroups-3.4.0.Alpha2
by Janardhan Naidu (Jira)
[ https://issues.redhat.com/browse/JGRP-2485?page=com.atlassian.jira.plugin... ]
Janardhan Naidu commented on JGRP-2485:
---------------------------------------
Hi [~belaban]
Can you please provide some inputs on this. as we are unable to upgrade groups to 3.6.19 due as UDP is not working!.
Thanks
Janardhan
> UDP is not working after upgarde to 3_6_19 from jgroups-3.4.0.Alpha2
> --------------------------------------------------------------------
>
> Key: JGRP-2485
> URL: https://issues.redhat.com/browse/JGRP-2485
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.19
> Reporter: Janardhan Naidu
> Assignee: Bela Ban
> Priority: Major
> Attachments: noapp.log.D20200619.T053202_NODE1
>
>
> Hi Team,
>
> we just upgraded from jgroups-3.4.0.Alpha2 to 3_6_19. post the UDP cluster communication is not working.
> after upgrade, we were hitting some warning as below and we solved those by changing property_string of UDP.
> *Warnings:*
> *WARNING: JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead*
> [2020-06-17 14:05:49.271] ALL 000000000000 GLOBAL_SCOPE Jun 17, 2020 2:05:49 PM org.jgroups.stack.Configurator resolveAndAssignField
> *WARNING: JGRP000014: Discovery.num_initial_members has been deprecated: will be ignored*
> [2020-06-17 14:05:49.396] ALL 000000000000 GLOBAL_SCOPE Jun 17, 2020 2:05:49 PM org.jgroups.protocols.pbcast.NAKACK init
> *WARNING: use_mcast_xmit should not be used because the transport (TCP) does not support IP multicasting; setting use_mcast_xmit to false*
>
> To solve above warnings, we went through tcp.xml which was shipped using in 3_6_19 jar:
> and now our properties looks like:
> *property_string=UDP*(bind_addr=*hostIP*;bind_port=39061;mcast_addr=239.255.166.17;mcast_port=39060;ip_ttl=32;mcast_send_buf_size=150000;mcast_recv_buf_size=80000):PING:MERGE2(min_interval=5000;max_interval=10000):FD_ALL(interval=5000;timeout=20000):VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(use_mcast_xmit=true;retransmit_timeout=300,600,1200,2400,4800;discard_delivered_msgs=true):UNICAST:pbcast.STABLE(desired_avg_gossip=20000):FRAG(frag_size=8096):pbcast.GMS(join_timeout=5000;print_local_addr=true)
>
> *distribution_property_string=TCP*(bind_port=39060;thread_pool_rejection_policy=run):TCPPING(async_discovery=true;initial_hosts=*hostIP*[39060];port_range=0;):MERGE2(min_interval=3000;max_interval=5000):FD_SOCK:FD(timeout=5000;max_tries=48):VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(use_mcast_xmit=false;discard_delivered_msgs=true;):pbcast.STABLE(stability_delay=1000;desired_avg_gossip=20000;max_bytes=0):pbcast.GMS(join_timeout=5000;print_local_addr=true)
>
> *lock.protocolStack=UDP*(bind_addr=*hostIP*;bind_port=39062;mcast_addr=239.255.166.17;mcast_port=39069;ip_ttl=32;mcast_send_buf_size=150000;mcast_recv_buf_size=80000):PING:MERGE2(min_interval=5000;max_interval=10000):FD_ALL(interval=5000;timeout=20000):VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(use_mcast_xmit=true;retransmit_timeout=300,600,1200,2400,4800):UNICAST:pbcast.STABLE(desired_avg_gossip=20000):FRAG(frag_size=8096):pbcast.GMS(join_timeout=5000;print_local_addr=true):CENTRAL_LOCK(num_backups=2)
>
>
> With above properties, we are not seeing any warning or error. But still cluster communication is not working with UDP.
> Please help me in resolving the same
>
> Thank
> Janardhan
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFCORE-5015) Create 'core-specific' variants of Galleon feature groups and packages that are 'overridden' in full WildFly
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFCORE-5015?page=com.atlassian.jira.plug... ]
Brian Stansberry updated WFCORE-5015:
-------------------------------------
Description:
See [https://lists.jboss.org/pipermail/wildfly-dev/2020-June/007342.html... background.
For the wildfly-core galleon pack feature groups and packages that are 'overridden' in full WildFly, create a differently named variant in the galleon-common module that can be referenced in full WF. This eliminates the 'overriding/subclassing' and in a GAL-319 type future setup will allow the 'core' source item to be directly incorporated in the target FP in full without conflicting with an item with the same name in that target FP.
Feature groups:
domain-host-excludes
domain-interfaces
domain-profile
host-master
host-slave
host
standalone-profile
Packages:
bin.common
bin.vaulttools
docs.licenses.merge
misc.common
misc.domain
misc.standalone
was:
See [https://lists.jboss.org/pipermail/wildfly-dev/2020-June/007342.html... background.
For the wildfly-core galleon pack feature groups and packages that are 'overridden' in full WildFly, create a differently named variant in the galleon-common module that can be referenced in full WF. This eliminates the 'overriding/subclassing' and in a GAL-319 type future setup will allow the 'core' source item to be directly incorporated in the target FP in full without conflicting with an item with the same name in that target FP.
> Create 'core-specific' variants of Galleon feature groups and packages that are 'overridden' in full WildFly
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-5015
> URL: https://issues.redhat.com/browse/WFCORE-5015
> Project: WildFly Core
> Issue Type: Task
> Components: Build System
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Major
>
> See [https://lists.jboss.org/pipermail/wildfly-dev/2020-June/007342.html... background.
> For the wildfly-core galleon pack feature groups and packages that are 'overridden' in full WildFly, create a differently named variant in the galleon-common module that can be referenced in full WF. This eliminates the 'overriding/subclassing' and in a GAL-319 type future setup will allow the 'core' source item to be directly incorporated in the target FP in full without conflicting with an item with the same name in that target FP.
>
> Feature groups:
>
> domain-host-excludes
> domain-interfaces
> domain-profile
> host-master
> host-slave
> host
> standalone-profile
>
> Packages:
> bin.common
> bin.vaulttools
> docs.licenses.merge
> misc.common
> misc.domain
> misc.standalone
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFCORE-5016) Have the feature pack 'source modules' produce zip artifacts
by Brian Stansberry (Jira)
Brian Stansberry created WFCORE-5016:
----------------------------------------
Summary: Have the feature pack 'source modules' produce zip artifacts
Key: WFCORE-5016
URL: https://issues.redhat.com/browse/WFCORE-5016
Project: WildFly Core
Issue Type: Task
Components: Build System
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 13.0.0.Beta1
Follow-up to WFCORE-4993. Have the new core-feature-pack/common and core-feature-pack/ee-8-api maven modules produce zip artifacts in addition to poms. Convert the core-feature-pack/galleon-common directory into a module that produces a zip as well.
Having these available from a core beta release will allow dev work in full WF to consume them in the WF feature packs, instead of having to depend on the wildfly-core feature pack itself.
See [https://lists.jboss.org/pipermail/wildfly-dev/2020-June/007342.html]... background.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13607) "SSL read loop detected" during remote EJB call; remote call blocks forever
by Kyle MacLeod (Jira)
Kyle MacLeod created WFLY-13607:
-----------------------------------
Summary: "SSL read loop detected" during remote EJB call; remote call blocks forever
Key: WFLY-13607
URL: https://issues.redhat.com/browse/WFLY-13607
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 19.1.0.Final
Reporter: Kyle MacLeod
Assignee: Flavia Rainone
Summary: "SSL read loop detected" during remote EJB call; remote call blocks forever
h3. Problem Description
We are transferring data over an EJB request. The data returned from the EJB call ranges from 1-4MB in size.
During one of these transfers, we are hitting some sort of race/timing condition which results in a "UT005076: SSL read loop detected" ERROR log.
After the read loop detected log, the remote call blocks forever. Something is broken with the cleanup.
Unfortunately, this is only happening on some of our servers. It's difficult to reproduce - and I don't have a test case for it.
Other notes:
* The issue is seen on the client side. The client is a java standalone client. All are running in docker containers. The issue is seen both running under docker-compose and under kubernetes.
* The issue is seen with the 19.0.1.Final wildfly-client-all jar. It is NOT seen when we revert back to 18.0.0.Final wildfly-client-all jar.* It looks to me like an issue in either SslConduit or WildflyClientInputStream. There were commits post-18.0.0.Final which hit code in this area.
h3. Logs
What we see in the log file is these two back-to-back errors from the same thread:
{code:language=|borderStyle=solid|theme=RDark|linenumbers=true|collapse=false}
2020-06-09 15:04:30,378 ERROR [io.undertow.request] [AgentServerModelRegistrationStateChangeNotification-pool-21-thread-1] UT005076: SSL read loop detected. This should not happen, please report this to the Undertow developers. Current state SslConduit{state=4, outstandingTasks=0, wrappedData=null, dataToUnwrap=null, unwrappedData=null}
2020-06-09 15:04:30,552 ERROR [io.undertow.request] [AgentServerModelRegistrationStateChangeNotification-pool-21-thread-1] UT005076: SSL read loop detected. This should not happen, please report this to the Undertow developers. Current state SslConduit{state=30692, outstandingTasks=0, wrappedData=null, dataToUnwrap=null, unwrappedData=null}
{code}
And then that same thread gets blocked forever, stuck waiting for the lock at org.wildfly.httpclient.common.WildflyClientInputStream.read(WildflyClientInputStream.java:147)
{code:language=|borderStyle=solid|theme=RDark|linenumbers=true|collapse=true}
"AgentServerModelRegistrationStateChangeNotification-pool-21-thread-1" #40 prio=5 os_prio=0 tid=0x00007f5cac9f8000 nid=0x47 in Object.wait() [0x00007f5c8b1d5000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at org.wildfly.httpclient.common.WildflyClientInputStream.read(WildflyClientInputStream.java:147)
- locked <0x00000000ed9475a8> (a java.lang.Object)
at java.io.FilterInputStream.read(FilterInputStream.java:133)
at org.jboss.marshalling.SimpleDataInput.readFully(SimpleDataInput.java:175)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadByteArray(RiverUnmarshaller.java:1622)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadArray(RiverUnmarshaller.java:1690)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:355)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:231)
at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1864)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1778)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1406)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:283)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:216)
at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
at org.wildfly.httpclient.ejb.HttpEJBReceiver$2.getResult(HttpEJBReceiver.java:207)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:613)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:544)
at org.jboss.ejb.protocol.remote.RemotingEJBClientInterceptor.handleInvocationResult(RemotingEJBClientInterceptor.java:57)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:615)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:544)
at org.jboss.ejb.client.TransactionPostDiscoveryInterceptor.handleInvocationResult(TransactionPostDiscoveryInterceptor.java:148)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:615)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:544)
at org.jboss.ejb.client.DiscoveryEJBClientInterceptor.handleInvocationResult(DiscoveryEJBClientInterceptor.java:137)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:615)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:544)
at org.jboss.ejb.client.NamingEJBClientInterceptor.handleInvocationResult(NamingEJBClientInterceptor.java:87)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:615)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:544)
at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:212)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:615)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:544)
at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:986)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:191)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:125)
at com.sun.proxy.$Proxy24.getAdapterArchive(Unknown Source)
at com.nakina.agent.application.adaptermanager.internal.dataservice.AgentRemoteAdapterArchiveRepositoryImpl$FakeRemoteIterator.next(AgentRemoteAdapterArchiveRepositoryImpl.java:226)
at com.nakina.agent.application.adaptermanager.internal.dataservice.AgentRemoteAdapterArchiveRepositoryImpl$FakeRemoteIterator.next(AgentRemoteAdapterArchiveRepositoryImpl.java:189)
at com.nakina.adaptermanager.AdapterManagerImpl.addToLocalRepository(AdapterManagerImpl.java:506)
at com.nakina.adaptermanager.AdapterManagerImpl.synchronizeLocalRepository(AdapterManagerImpl.java:617)
at com.nakina.adaptermanager.AdapterManagerImpl.initialize(AdapterManagerImpl.java:373)
at com.nakina.agent.application.adaptermanager.internal.dataservice.AdapterManagerFactoryImpl.getAdapterManager(AdapterManagerFactoryImpl.java:66)
- locked <0x00000000c07fa748> (a java.lang.Object)
at com.nakina.agent.application.adaptermanager.internal.action.StartAdapterManagerAction.execute(StartAdapterManagerAction.java:54)
at com.nakina.oss.server.af.app.action.DefaultActionManager.executeRequest(DefaultActionManager.java:176)
...
at com.nakina.oss.server.af.app.message.DefaultMessageReceiver.execute(DefaultMessageReceiver.java:65)
at com.nakina.oss.server.af.app.action.DefaultActionManager.executeRequest(DefaultActionManager.java:176)
at com.nakina.oss.server.af.app.message.DefaultMessageReceiver.onMessage(DefaultMessageReceiver.java:154)
at com.nakina.oss.server.af.app.impl.LocalMessageSenderImpl$SenderRunnable.run(LocalMessageSenderImpl.java:189)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}
h3. Other information:
Java version:
{code:language=|borderStyle=solid|theme=RDark|linenumbers=true|collapse=false}
$ java -version
openjdk version "1.8.0_252"
OpenJDK Runtime Environment (build 1.8.0_252-b09)
OpenJDK 64-Bit Server VM (build 25.252-b09, mixed mode)
{code}
Wildfly server version:
{code:language=|borderStyle=solid|theme=RDark|linenumbers=true|collapse=false}
WFLYSRV0049: WildFly Full 19.1.0.Final (WildFly Core 11.1.1.Final) starting
{code}
wildfly-client-all version:
* 19.0.1.Final wildfly-client-all jar.
* NOT seen when we revert back to 18.0.0.Final wildfly-client-all jar
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years