[
https://issues.apache.org/jira/browse/ARTEMIS-4338?focusedWorklogId=868780&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-868780
]
ASF GitHub Bot logged work on ARTEMIS-4338:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 30/Jun/23 19:27
Start Date: 30/Jun/23 19:27
Worklog Time Spent: 10m
Work Description: tabish121 commented on code in PR #4530:
URL: https://github.com/apache/activemq-artemis/pull/4530#discussion_r1248216712
##########
artemis-server/src/main/java/org/apache/activemq/artemis/core/protocol/ProtocolHandler.java:
##########
@@ -243,6 +243,18 @@ protected void decode(ChannelHandlerContext ctx, ByteBuf
in, List<Object> out) t
ctx.flush();
}
+ @Override
+ public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) {
+ // We definitely want to log the failure
+
ActiveMQServerLogger.LOGGER.failureDuringProtocolHandshake(ctx.channel().remoteAddress().toString(),
cause);
+
+ // However, what else should be done here? I've laid out a few
options...
+ ctx.fireChannelInactive();
Review Comment:
You shouldn't need to do this directly unless there's something in there you
really need to run right now.
##########
artemis-server/src/main/java/org/apache/activemq/artemis/core/protocol/ProtocolHandler.java:
##########
@@ -243,6 +243,18 @@ protected void decode(ChannelHandlerContext ctx, ByteBuf
in, List<Object> out) t
ctx.flush();
}
+ @Override
+ public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) {
+ // We definitely want to log the failure
+
ActiveMQServerLogger.LOGGER.failureDuringProtocolHandshake(ctx.channel().remoteAddress().toString(),
cause);
+
+ // However, what else should be done here? I've laid out a few
options...
+ ctx.fireChannelInactive();
+ ctx.close(); // this is done frequently in other implementations of
exceptionCaught()
+ ctx.fireExceptionCaught(cause);
+ ctx.pipeline().remove(this); // this is done at the end of decode();
should we do this as well?
Review Comment:
If the outcome is terminal then you shouldn't need to remove this, depends
on the handler but in general the pipeline is going to get torn down if you
close the context.
##########
artemis-server/src/main/java/org/apache/activemq/artemis/core/protocol/ProtocolHandler.java:
##########
@@ -243,6 +243,18 @@ protected void decode(ChannelHandlerContext ctx, ByteBuf
in, List<Object> out) t
ctx.flush();
}
+ @Override
+ public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) {
+ // We definitely want to log the failure
+
ActiveMQServerLogger.LOGGER.failureDuringProtocolHandshake(ctx.channel().remoteAddress().toString(),
cause);
+
+ // However, what else should be done here? I've laid out a few
options...
+ ctx.fireChannelInactive();
+ ctx.close(); // this is done frequently in other implementations of
exceptionCaught()
+ ctx.fireExceptionCaught(cause);
Review Comment:
If you are fully handling the exception caught case you don't need to
forward this, but if there's another handler that is in the chain that you want
to see the event then you could forward it.
Issue Time Tracking
-------------------
Worklog Id: (was: 868780)
Time Spent: 0.5h (was: 20m)
> STOMP inoperable w/resource audit logging enabled
> -------------------------------------------------
>
> Key: ARTEMIS-4338
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4338
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: STOMP
> Affects Versions: 2.29.0
> Reporter: Otavio Rodolfo Piske
> Assignee: Justin Bertram
> Priority: Blocker
> Attachments: camel-stomp-test-debug-2.28.0.log,
> camel-stomp-test-debug-2.29.0.log
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Recently we tried upgrading to Artemis 2.29, but when doing so our
> integration tests started to fail. No code was changed as part of the upgrade.
> With 2.29, the connection seems to fail due to a connection timeout:
>
> {noformat}
> 2023-06-29 07:51:40,739 [Impl$6@b91d8c4)] WARN server
> - AMQ222067: Connection failure has been detected: AMQ229014: Did not
> receive data from /127.0.0.1:50934 within the 60000ms connection TTL. The
> connection will now be closed. [code=CONNECTION_TIMEDOUT]{noformat}
>
> I wasn't able to determine the problem, so I am attaching the debug logs for
> an execution with 2.28 and another with 2.29.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
