[jboss-jira] [JBoss JIRA] Updated: (JGRP-1352) STATE: queue requests during state transfer

[Bela Ban (JIRA)]

     [ https://issues.jboss.org/browse/JGRP-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1352:
---------------------------

    Description: 
STATE should queue requests to be delivered to the application while a state transfer is in progress.

Draft design:

* On STATE-REQ:
** If busy --> add request to queue, return
** Else --> processRequest
** Close MessageQueue and deliver all messages in it to the application
** Kick off a STABLE round, wait until it completes
** If MessageQueue is not empty --> processRequests()

* processRequest():
** Close BARRIER, suspend STABLE
** Get digest
** Open MessageQueue: all new messages will be queued now, rather than delivered to the application
*** (Only MSG, not VIEW !)
** Open BARRIER (leave STABLE suspended !)
** Transfer state to state requester
** Resume STABLE


Advantages:
  - The state provider is not blocked, e.g. to handle JOIN requests
  - Only the state *requester* is blocked, this is OK though
  - Between the state requests, the state provider gets a little breathing room to process
    queued-up messages, and to purge messages (through stability)

Misc:
 - Should the MessageQueue use the disk to handle large message sets ?
 - If modifications are idempotent, we *don't* need to queue messages (make this configurable !)
   (for example Infinispan ?)

  was:
STATE should queue requests to be delivered to the application while a state transfer is in progress.

Draft design:

- On STATE-REQ:
  - If busy --> add request to queue, return
  - Else --> processRequest
  - Close MessageQueue and deliver all messages in it to the application
  - Kick off a STABLE round, wait until it completes
  - If MessageQueue is not empty --> processRequests()

- processRequest():
  - Close BARRIER, suspend STABLE
  - Get digest
  - Open MessageQueue: all new messages will be queued now, rather than delivered to the application
    - (Only MSG, not VIEW !)
  - Open BARRIER (leave STABLE suspended !)
  - Transfer state to state requester
  - Resume STABLE


Advantages:
  - The state provider is not blocked, e.g. to handle JOIN requests
  - Only the state *requester* is blocked, this is OK though
  - Between the state requests, the state provider gets a little breathing room to process
    queued-up messages, and to purge messages (through stability)

Misc:
 - Should the MessageQueue use the disk to handle large message sets ?
 - If modifications are idempotent, we *don't* need to queue messages (make this configurable !)
   (for example Infinispan ?)



> STATE: queue requests during state transfer
> -------------------------------------------
>
>                 Key: JGRP-1352
>                 URL: https://issues.jboss.org/browse/JGRP-1352
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.1
>
>
> STATE should queue requests to be delivered to the application while a state transfer is in progress.
> Draft design:
> * On STATE-REQ:
> ** If busy --> add request to queue, return
> ** Else --> processRequest
> ** Close MessageQueue and deliver all messages in it to the application
> ** Kick off a STABLE round, wait until it completes
> ** If MessageQueue is not empty --> processRequests()
> * processRequest():
> ** Close BARRIER, suspend STABLE
> ** Get digest
> ** Open MessageQueue: all new messages will be queued now, rather than delivered to the application
> *** (Only MSG, not VIEW !)
> ** Open BARRIER (leave STABLE suspended !)
> ** Transfer state to state requester
> ** Resume STABLE
> Advantages:
>   - The state provider is not blocked, e.g. to handle JOIN requests
>   - Only the state *requester* is blocked, this is OK though
>   - Between the state requests, the state provider gets a little breathing room to process
>     queued-up messages, and to purge messages (through stability)
> Misc:
>  - Should the MessageQueue use the disk to handle large message sets ?
>  - If modifications are idempotent, we *don't* need to queue messages (make this configurable !)
>    (for example Infinispan ?)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira