[
https://issues.apache.org/jira/browse/AMQ-8606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17540117#comment-17540117
]
Justin Bertram commented on AMQ-8606:
-------------------------------------
bq. But I think it’s the broker’s responsibility to return error or some kind
of ack back to tell the client the connection is not valid.
Are you saying that while the broker is shutting down for a reboot it should
send an {{ERROR}} frame to the client letting them know that the connection is
no longer valid? That _might_ be valid, but I don't know of any STOMP server
which does that. In any case, the [STOMP
specification|https://stomp.github.io/stomp-specification-1.2.html#ERROR]
states, "The server *MAY* send {{ERROR}} frames if something goes wrong," which
means the client should be written to deal with servers that _don't_ send
{{ERROR}} frames when something goes wrong. This, of course, assumes that
rebooting the broker is even in the category of something that has "gone
wrong." The broker certainly wouldn't send any kind of frame at all if it
crashes for any reason. Again, the client would need to be written to deal with
this situation.
STOMP does support a {{DISCONNECT}} frame which the client is able to send to
the broker to inform it of a connection termination. However, a {{DISCONNECT}}
frame _can't_ be sent from a broker to a client as STOMP doesn't support that.
bq. Why does the client get ‘broken pipe’ message on the second message, not on
the first message after reboot?
I can't answer that question as I'm not familiar with the client implementation
you're using. Again, this behavior is up to the client not the broker.
Generally speaking, I would recommend you request a
[{{RECEIPT}}|https://stomp.github.io/stomp-specification-1.2.html#RECEIPT]
frame from the broker when you send a message. That way if the connection is no
longer valid you won't get a {{RECEIPT}} and you'll know you need to resend the
last frame.
> Cached connection does not return error after rebooting ActiveMQ and a
> message is lost
> --------------------------------------------------------------------------------------
>
> Key: AMQ-8606
> URL: https://issues.apache.org/jira/browse/AMQ-8606
> Project: ActiveMQ
> Issue Type: Bug
> Components: STOMP
> Affects Versions: 5.16.3
> Environment: NAME="Red Hat Enterprise Linux"
> VERSION="8.4 (Ootpa)"
> ID="rhel"
> ID_LIKE="fedora"
> VERSION_ID="8.4"
> PLATFORM_ID="platform:el8"
> PRETTY_NAME="Red Hat Enterprise Linux 8.4 (Ootpa)"
> ANSI_COLOR="0;31"
> CPE_NAME="cpe:/o:redhat:enterprise_linux:8.4:GA"
> HOME_URL="https://www.redhat.com/";
> DOCUMENTATION_URL="https://access.redhat.com/documentation/red_hat_enterprise_linux/8/";
> BUG_REPORT_URL="https://bugzilla.redhat.com/";
> REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 8"
> REDHAT_BUGZILLA_PRODUCT_VERSION=8.4
> REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
> REDHAT_SUPPORT_PRODUCT_VERSION="8.4"
> Reporter: Timothy Kim
> Priority: Major
>
> +*Background:*+
> I am using STOMP to publish messages to a topic in ActiveMQ. In my client
> program, written in lua, I keep a publishing connection in a variable and use
> it to publish all topic messages. If the connection times out, it catches
> error and get a new connection and continues .....
> +*Issue:*+
> When an ActiveMQ instance is rebooted for whatever the reason, my client
> program doesn't know that it was rebooted and continue to publishes a topic
> message with the connection that was obtained before the reboot. Strangely it
> doesn't get any error message when it publishes a topic message first time
> after reboot. It should fail because the connection is not valid any longer.
> When it tries to publish another message (second attempt), then the client
> program gets error message -"{color:#ff0000}broken pipe{color}". For this, I
> only get to retry the second message to recover by retrying it. The first
> message after the reboot is lost because a topic subscriber doesn't get the
> message.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
