Confirmed users
192
edits
Services/MessageQueuing: Difference between revisions
Jump to navigation
Jump to search
m
→Planning Questions
| Line 9: | Line 9: | ||
*Allow messages to go unacknowledged to allow a client to 'time-out' on handling it? | *Allow messages to go unacknowledged to allow a client to 'time-out' on handling it? | ||
*Message push (persistent MQ connection), reduces latency but increases complexity. Pub/Sub or load-balanced on multiple connected clients? | *Message push (persistent MQ connection), reduces latency but increases complexity. Pub/Sub or load-balanced on multiple connected clients? | ||
*Chat and 'live' apps using the MQ for comet? | |||
Trade-offs of implementation / back-ends | Trade-offs of implementation / back-ends | ||
| Line 31: | Line 32: | ||
*maybe [[Services/AppKeys|AppKeys]] would work, depending on if only the App could send messages... might need something else if end-user clients can directly push messages via Javascript | *maybe [[Services/AppKeys|AppKeys]] would work, depending on if only the App could send messages... might need something else if end-user clients can directly push messages via Javascript | ||
*If used for message passing between end-user's vs. a separate Service app, clients would need permission to be on the queue, likely based on whether they're 'logged in' to the App using the queue | |||
Message Handling | Message Handling | ||