>> 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
