We have a situation where the broker-pers file fills up very fast. We have defined our client groups to be of persistent storage type. I have seen two threads on this topic, but I am not clear of the resolution. If I make these client groups guarenteed, then I would be using double the space because of the two-phased commit ? What is the resolution when the when I use up all 512 MB. Is there a way of flushing the file. Since space is a constraint on that server, I understand making the client groups to have guarenteed storage would make the situation worse by doubling the space required.
a) Broker 5.0 (and greater) does not have this limitation.
b) The only way you can get over this problem for broker<5.0 is by having a architecture that involves multiple broker servers and an algorithm that helps in distributing the integrations on these servers. Please let me know if you need more details on this topic. This recommendation also suggests having a hub broker server sometimes. Brokers talk to each other using gateways and territories, the issue being that the guar file size increases when two brokers belonging to two different broker servers are brought into a territory. So, having multiple brokers, broker servers and territories in a elegant manner with the possibility of having a hub broker probably is your solution.
Thanks for the reply. Can you please send me more details about the distributed architecture you suggested or point me to some documentation.
How does the broker manage this file, broker-pers. Are old messages deleted. Currently, we are saving this file and then creating a new one whenever it fills up. But, we are losing some messages in case of a network failure and we delete the file before the broker tries to send them again.