[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xmlblaster] Message Queuing Question

I had sometime today and manage to hack up a quick and dirty solution for my usage. I had a look at AccessFilter like you recommended but found that extra work needs to be done which, I believe is not transparent to the publishers and subscribers. I prefer a more transparent way, without stating anything in the QoS. I made some changes to the MessageUnitHandler class (not more than 10 lines) and added in my own class which I named, MessageDelegate.

There are probably a lot of problems with this approach, but for the time being, it suits my needs. Problems are such as :
1. no runtime selection of behavior, you either use the default behavior or this message delegate behavior, but this can be fixed in due time.
2. probably lost of message due to a subscriber unsubscribe or go down. Don't know what to do here.

This is the first time I made any changes / additions to an open source software, so, I'm sorry if my question is naive or stupid. Should I send in the changes as is, or follow a certain standard / process or just forgetabout it??

Thanks for your time,


Marcel Ruff wrote:

Hamdi Mohs Yusof wrote:

Thanks for the reply. I'm just thinking of a simple round robin rule. If there are x number of subscribers, I need to keep track of the next subscriber to send to.

For example, say there are 5 subscribers (S1 until S5) and 8 new messages (M1 until M8). First round, all 5 subscribers will get 1 message (S1 gets M1, S2 gets M2 ... S5 gets M5). Second round, S1 gets M6 .... S3 gets M8. The next message that comes in will be sent to S4.

Is AccessFilter plugin the right way to go about this? I certainly don't mind digging deep into it if it is.

Yes, AccessFilter plugin is your solution.

S1 - S5 subscribe to the same message say

 <key oid='AccountWithdrawMoney' contentMime='text/finance'/>

which happens very frequently so that you need a round robin for performance

S1-S5 can send some filter rule in their subscribe QoS which your
plugin uses to decide who will get it.

Your plugin registers itself for mime='text/finance' to be
only consulted for messages of this type.