JMS Session recovery and unit testing.

[boneill42]

JMS Session recovery and unit testing.

[ptgoetz]

Awesome. Looks pretty good. I'm in the process of merging with the following changes:

• Internalize the "RecoveryTask" class (no need to expose it publicly)
• Defaulting "recoveryPeriod" to -1 (disabled)
• Raise hell (via log -- maybe even throw an exception) if (recoveryPeriod * 1000) < "topology.message.timeout.secs" -- if we call recover() too often, we'll potentially create a replay flood if ack times approach the timeout period.

[boneill42]

Excellent. Thanks Great catch on the tuple flood.

-brian

Brian O'Neill Lead Architect, Software Development Health Market Science | 2700 Horizon Drive | King of Prussia, PA 19406 p: 215.588.6024 www.healthmarketscience.com

On 4/26/12 10:49 PM, "P. Taylor Goetz" <reply+i-4311656-0f70ec4635ac65ab70ee73955a7b77251f2772b6-897229@reply.gith ub.com> wrote:

Awesome. Looks pretty good. I'm in the process of merging with the following changes:

• Internalize the "RecoveryTask" class (no need to expose it publicly)
• Defaulting "recoveryPeriod" to -1 (disabled)
• Raise hell (via log -- maybe even throw an exception) if (recoveryPeriod * 1000) < "topology.message.timeout.secs" -- if we call recover() too often, we'll potentially create a replay flood if ack times approach the timeout period.

---

Reply to this email directly or view it on GitHub: https://github.com/ptgoetz/storm-jms/pull/2#issuecomment-5372535