Re: [jgroups-dev] Question on PRIO Protocol Enhancement

On 10/28/13 11:04 PM, Steven West wrote:
> Hey All- I work for a company that uses JGroups extensively for all
> communication within our primary display application.  I am presently
> working on addressing an issue we are having with JGroups that others
> may have also encountered, and I was hoping to get some feedback from
> the group on how best to implement my changes so they may be re-used
> in the future.
>
> The primary issue I am addressing is an Out-Of-Memory error. The
> primary source is the PRIO protocol (which a predecessor of mine
> initially developed)  along with the RATE-LIMITER protocol when a
> large number of messages are back-logged in the queue.


Note that both of these protocols are tagged as @Experimental... I've 
never really stress-tested RATE_LIMITER extensively.


> My basic plan
> to address this issue is to add functionality to the PRIO protocol so
> that it will temporarily store the contents of pending messages to
> disk instead of storing them in memory, keeping a minimal amount of
> data in memory when large files are being sent over a slow pipe.

Your up- and down queues are bounded; so won't you simply block the 
sender/receiver when the queue is full ?

> I have a preliminary pass at these changes made and working against an
> older version of the JGroups PRIO protocol (JGroups-3.0.2), but would
> like to submit them back to the group for use by others.
> This brought up my real question: What is the correct way to apply a
> change like the one above to the existing code base so it can be
> integrated back into JGroups? Should I modify the existing PRIO
> protocol to add this enhanced functionality, or create a new protocol
> (PRIO2?) which contains the existing PRIO protocol plus my
> enhancements?

I don't know of anyone else using PRIO, so you could modify PRIO. 
However, if this is completely new functionality, I suggest create a 
PRIO2. If you think that the new functionality should supercede PRIO, 
then modify PRIO.

> I couldn't find any guidelines for such a change in the immediate
> documentation I found. From reviewing the existing code it appears
> that the new protocol approach (PRIO2?) is the more common approach,
> but I wanted to get feedback from those of you actively developing
> for JGroups to get your feel.

I usually create a xxx-2 protocol if I expect the current protocol still 
to be used for some time. E.g. I created NAKACK2 because (a) it had a 
sufficiently new implementation, (b) a new wire protocol which wasn't 
backward-compatible with NAKACK and (c) wanted to use NAKACK as a 
fallback in case there were bugs in the new impl.

> I look forward to your feedback. Thanks! --
>
> Steve West


-- 
Bela Ban, JGroups lead (http://www.jgroups.org)

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Javagroups-development mailing list