Not sure what's causing the blocking; I will say though that the recommended approach is to use SAN or JDBC in general. The pure master-slave replication approach is flawed in that AMQ doesn't have an elegant solution for resynchronizing the master's store when you restart it after failure.
If I use the option producerFlowControl=false on the queues used for the replication, this problem does not appear anymore.
By the way, if we cannot guarantee that the replication mechanism is stable enough
and that the messages produced are well acknowledged (at the producer site and at the consumer side when consumed) and the information is well synchronised like the sessions, transactions betweeb the two brokers, it make no sense to continue to investigate it and SAN/JDBC should become the recommended approach !
Is it possible in a configuration where we configure 2 brokers in a pipeline using networkConnector to push messages from the master to the slave even if no consumers are connected to the slave ?
yeah, producerFlowControl is not considered in the replication, it is a simple pipe between the two brokers, so memory limits on the slave can be reached (blocking replication) before flow control kicks in on the master which can lead to the problem you describe. Removing usage limits on the slave should help.
But as Ade indicates, from a failover/fault tolerance perspective, shared file system or shared jdbc gives a better recovery strategy as the state is externalized and shared.
A network of brokers implements store and forward, so a message is not replicated, it is moved. It is possible to configure a set of static destinations for a network connector that will be auto forwarded irrespective of demand, but the usecase is typically scalability rather than fault tolerance.
What are your fault tolerant requirements?