|
Mantis - Resin
|
|||||
| Viewing Issue Advanced Details | |||||
|
|
|||||
| ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
| 2829 | minor | always | 08-08-08 09:22 | 09-11-09 18:09 | |
|
|
|||||
| Reporter: | ferg | Platform: | |||
| Assigned To: | ferg | OS: | |||
| Priority: | normal | OS Version: | |||
| Status: | closed | Product Version: | 3.2.0 | ||
| Product Build: | Resolution: | fixed | |||
| Projection: | none | ||||
| ETA: | none | Fixed in Version: | 4.0.2 | ||
|
|
|||||
| Summary: | 0002829: BAM persistent topics | ||||
| Description: |
(rep by Chris Chen) don't have a fully concrete idea either but there are two sides to this subscription feature - client and server. The server side may be similar to how JMS EJB beans or Jabber Server side components work. The EJB side has a defined set of beans listening to a particular topic/queue. This is considered a subscription. As for persistent subscriptions, it can be similar to how JMS works as well. A client registers as a subscriber for a particular topic. Unless the client unsubscribes, the system will continue to store messages for this subscriber when the subscriber is offline. Of course, this comes with its own set of challenges. Fiorano MQ and ESB has a setting to periodically flush out any persistent messages. XMPP by nature has persistence message supported in some sense (ie. I get chat messages that were sent when I wasn't logged on). I wonder if a Jini-like persistence capability may be something to model after or even relevant in this case. Either way, persistent and subscription do go hand in hand. |
||||
| Steps To Reproduce: | |||||
| Additional Information: | |||||
| Relationships | |||||
| Attached Files: | |||||
| Notes | |||||
|
|
|||||
|
|
||||