[JBoss JIRA] (WFLY-12016) Outbound channel count will become divergent from actually open channels when remote service is not yet registered
by Joachim Petrich (Jira)
Joachim Petrich created WFLY-12016:
--------------------------------------
Summary: Outbound channel count will become divergent from actually open channels when remote service is not yet registered
Key: WFLY-12016
URL: https://issues.jboss.org/browse/WFLY-12016
Project: WildFly
Issue Type: Bug
Components: Remoting
Affects Versions: 15.0.1.Final
Environment: Wildfly 15.0.1.Final
Windows 10
standalone_full_ha configuration
server nodes as Wildfly cluster with 2 nodes,
various client nodes
server and client nodes a running a standalone Wildfly
Reporter: Joachim Petrich
Assignee: Flavia Rainone
Requesting the opening of an outbound channel via org.jboss.remoting3.remote.RemoteConnectionHandler.open(String, Result<Channel>, OptionMap) for a service type that is not registered on the remote node results in a divergence between the number of channels actually opened and the internal counter.
In the worst case this will result in an unusable connection to the remote node that will never recover and can only be fixed by restarting the application server from which the outbound channel should have been opened.
In our case, the problem came up after restarting the remote application server, resulting in the following repeated exception:
org.jboss.ejb.client.RequestSendFailedException: org.jboss.remoting3.ProtocolException: Too many channels open@remote+http://172.30.15.150:8080
at org.jboss.ejb.protocol.remote.RemoteEJBReceiver$1.lambda$handleDone$0(RemoteEJBReceiver.java:83)
at org.xnio.AbstractIoFuture$NotifierRunnable.run(AbstractIoFuture.java:720)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Unknown Source)
Suppressed: org.jboss.ejb.client.RequestSendFailedException: org.jboss.remoting3.ProtocolException: Too many channels open@remote+http://172.30.15.150:8080
... 7 more
The following excerpt from checking the Service MBean to dump the channel status showed a maxed outbound channel counter but no open channels:
Connection LOCAL-NODE/172.30.15.151:59765 <-> /172.30.15.150:8080
Raw: org.xnio.ssl.JsseSslStreamConnection@31166dfc
* Flags: supports-message-close auth-cap
* 0 (max 40) inbound channels
* 40 (max 40) outbound channels
* Channels:
Connection LOCAL-NODE/172.30.15.151:57690 <-> /172.30.15.152:8080
Reproducing the problem with activated org.jboss.remoting traces showed, that the remote application server was refusing the channel open request (for the jboss.ejb service type):
14:00:26,672 TRACE [org.jboss.remoting.remote] (default I/O-4) Refusing service on channel 2d4e99c8: Unknown service name
Meanwhile, the local application server was trying to open channels until the maximum of 40 channels was reached.
The propes fix (as we did locally):
When handling a service error response in org.jboss.remoting3.remote.RemoteReadListener.handleEvent(ConduitStreamSourceChannel) properly decrement the internal counter by calling org.jboss.remoting3.remote.RemoteConnectionHandler.handleOutboundChannelClosed() to match the previously succeeded call to
org.jboss.remoting3.remote.RemoteConnectionHandler.handleOutboundChannelOpen() in org.jboss.remoting3.remote.RemoteConnectionHandler.open(String, Result<Channel>, OptionMap).
diff --git a/src/main/java/org/jboss/remoting3/remote/RemoteReadListener.java b/src/main/java/org/jboss/remoting3/remote/RemoteReadListener.java
index ceb0e32e..bccd046a 100644
--- a/src/main/java/org/jboss/remoting3/remote/RemoteReadListener.java
+++ b/src/main/java/org/jboss/remoting3/remote/RemoteReadListener.java
@@ -424,6 +424,9 @@ final class RemoteReadListener implements ChannelListener<ConduitStreamSourceCha
// invalid
break;
}
+ // match the handleOutboundChannelOpened() call in RemoteConnectionHandler.open(String, Result<Channel>, OptionMap)
+ handler.handleOutboundChannelClosed();
+ log.tracef("Properly decremented outbound channel counter after closing pending channel %08x.", channelId);
String reason = new String(Buffers.take(buffer), StandardCharsets.UTF_8);
pendingChannel.getResult().setException(new ServiceOpenException(reason));
break;
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (JGRP-2341) Optimize for native Quarkus image
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2341?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2341.
----------------------------
Resolution: Done
> Optimize for native Quarkus image
> ---------------------------------
>
> Key: JGRP-2341
> URL: https://issues.jboss.org/browse/JGRP-2341
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.0
>
>
> When compiling to a native image, look at the following things:
> * Size of the native executable
> ** ClassConfigurator loads _all_ classes defined in {{jg-protocol-ids.xml}} and {{jg-magic-map.xml}}. Investigate whether the required classes can be manually added to ClassConfigurator
> * Memory usage when running the native executable. Find out what component/protocol uses most memory
> ** Look at {{UNICAST3}} and {{NAKACK2}} and optimize the size of the retransmission table (e.g. interval for purging, size of columns, rows etc)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (LOGMGR-253) Allow files to be rotated based on a cron expression
by James Perkins (Jira)
James Perkins created LOGMGR-253:
------------------------------------
Summary: Allow files to be rotated based on a cron expression
Key: LOGMGR-253
URL: https://issues.jboss.org/browse/LOGMGR-253
Project: JBoss Log Manager
Issue Type: Feature Request
Reporter: James Perkins
Assignee: James Perkins
Currently logs are either rotated via the size of the file or a date expression which is appended to the suffix. It could be useful to allow for rotation based on a cron expression. This may result in a new {{FileHandler}} if the rotating handlers cannot keep compatibility while adding the functionality.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months