[jdev] architecture questions

[Peter Millard]

Joanne wrote:
> I have a few areas I'd appreciate thoughts/opinions on:
>
> (1) message queuing/processing
[SNIP]
As stpeter already mentioned, JEP-013 solves this initial message flood, but
isn't availble out of the box in either jabberd2 or jabberd 1.4.3. Once you send
presence, ALL offline messages will get sent to that client. If your "client"
application blocks + processes, thats fine, but it does mean that the server
will "assume" that the messages are delivered even if it takes a while for your
app to process them.

> (2) scalability & redundancy
> I would like to connect multiple jabber clients to the same jabber server.
> Also keep in mind that my clients will only be available within the internal
> network, so I'm exploiting the A2A (application 2 application) capability of
> jabber. Although each jabber client does the same thing, they would each
> need to have unique jids. But I also read that I could run multiple clients
> with the same jid but with different resource identifiers. Jabber would then
> decide which client to forward the message to based on the client's presence
> priority. Unfortunately, this doesn't do any load balancing, but it would
> allow me to take down one client without disrupting any message processing
> (since jabber would just forward messages to the next priority client). Is
> my thinking correct on this?

Yes, your assessments are correct. However, I would add that your "client"
applications could force jabberd to do more intelligent load balancing by
changing presence priority when the start processing a message. So an example
flow (from the client side) would be:
    1. Recv. a message to process.
    2. Change presence priority from 10 to 0 (for example).
    3. Write presence change to socket (sync).
    4. Process message (sync).
    5. Change presence priority from 0 back to 10.
    6. Write presence change to socket (sync).
    7. Wait for another packet.

So if you have 10 client apps hooked up at once, four of them may be at priorty
0, and the others may be at priority 10. The clients with the higher priority
would get packets first, and immediately change to 0 (moving them to the bottom
of the delivery list).

As you stated, this also has the advantage of automatic scalability (add more
client apps), and fail-over for each client. The only caveat here is that
whatever is sending the packets MUST always send packets to the bare jid (no
resource).

Regaurding the client vs. component argument... I don't necessarily agree with
stpeter :) He may be thinking that your talking about writing a client plugin or
something.. Using a client connection for this buys you a lot of routing and
queueing. You would loose this if you went the component route. No need to
re-invent the wheel.

pgm.