Hi,
did you have time to investigate thread dump provided? Do you need any
additional information?
--
Vilius
>-----Original Message-----
>From: Vilius Šumskas via users <[email protected]>
>Sent: Friday, March 13, 2026 3:55 PM
>To: [email protected]
>Cc: Vilius Šumskas <[email protected]>
>Subject: RE: error indication when cluster shared storage is not available
>
>>> Now to the last test. It was performed with soft NFS mount option...
>>
>>A bug appears to exist here as the broker should have shut down at the
>>first IOException when attempting to access the lock file. I need to
>>see a thread-dump from the broker to investigate why it didn't shut down
>completely.
>
>Is the thread dump attached to previous message enough, or do you need thread
>dump just after first IOException is produced? I could try to make such a
>test, just
>not sure at what point I should capture the dump. Previous thread dump was
>captured waiting ~15 minutes after first IOException occurred.
>
>>> If NFS mount is not available, where does all the message and topology data
>>> go?
>>
>>For producers, the broker will attempt to write durable messages to
>>disk. If it cannot, it will return an error to the client so the client
>>knows the message needs to be sent again.
>>
>>For consumers, the broker will attempt to write acknowledgements for
>>durable messages to disk. If it cannot, it will return an error to the
>>client so the client knows the message needs to be consumed again.
>>
>>If the broker is killed during operations involving durable messages,
>>the client will receive an error, indicating that the operation it was
>>performing was likely unsuccessful. I say "likely" because the
>>operation might have succeeded, and the broker could have been killed
>>before responding to the client. Of course, there are ways to deal with this
>situation as well.
>>
>>Any operation involving non-durable messages occurs in memory unless
>>paging is involved. The guarantees for non-durable messages are, of
>>course, completely different from those for durable messages. They are, by
>definition, volatile.
>>
>>I'm not really sure what you mean by "topology data," but if you're
>>using "topology" to mean the runtime information about cluster nodes,
>>as the broker does, then all that data exists only in memory. Please
>>clarify if that's not what you mean.
>
>By topology I mean addresses, queues, users, passwords, roles and other data
>not
>directly related to the messages themselves. Due to business requirements, we
>manage some of these ourselves using "activemq.management" queue and
>operations likes "addSecuritySettings" or "createRole".
>
>I understand that all of the above describes how _messaging_ data is stored,
>however my main concern is about _topology_ which we manage manually. I'm
>not sure if creating addresses through "activemq.management" queue vs. Artemis
>Console works the same way, but how it is possible, that I was allowed to
>create an
>address, view it, and then delete it in the Console, even though journal was
>not
>available at that time? I didn't try to actually use the created address from
>any JMS
>client or create queues inside of it, but the fact that I saw the address in
>the
>console tells me that this happened completely in memory? If yes, what could
>have
>happened to such address if NFS storage never came back or if I killed the
>broker?
>Also, if yes, what other "topology" operations use memory and don't wait to be
>written to journal?
>
>--
> Vilius
