Jackrabbit Content Repository
  1. Jackrabbit Content Repository
  2. JCR-2696

Allow to use an other queue type then FIFO for requests

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      Sometimes it would be nice to be able to give reads a higher priority then writes ( because writes block the whole jcr tree). Thats not possible atm, all requests are handled in FIFO-fashion. I think it would make sense to allow to use other strategies.

        Issue Links

          Activity

          Hide
          Norman Maurer added a comment -

          Yeah I'm aware of the FineGrainedISMLocking but as far as I know (from what Jukka said) does it perform not very well on the not obsolate persistencemanagers

          Show
          Norman Maurer added a comment - Yeah I'm aware of the FineGrainedISMLocking but as far as I know (from what Jukka said) does it perform not very well on the not obsolate persistencemanagers
          Hide
          Marcel Reutegger added a comment -

          There are already two strategies to choose from for the locking in the SharedItemStateManager: DefaultISMLocking and FineGrainedISMLocking (see JCR-314). The first will lock the complete tree while a write is going one, while the latter will only block the set of items that are affected by the current commit. Commits are serialized (I guess that's what you mean with FIFO) in both cases. Please note that this only covers the locking inside the SharedItemStateManager and you might still end up having reads locked by writes in the persistence manager implementation, which is IIRC true for all implementations we currently have.

          Show
          Marcel Reutegger added a comment - There are already two strategies to choose from for the locking in the SharedItemStateManager: DefaultISMLocking and FineGrainedISMLocking (see JCR-314 ). The first will lock the complete tree while a write is going one, while the latter will only block the set of items that are affected by the current commit. Commits are serialized (I guess that's what you mean with FIFO) in both cases. Please note that this only covers the locking inside the SharedItemStateManager and you might still end up having reads locked by writes in the persistence manager implementation, which is IIRC true for all implementations we currently have.
          Hide
          Norman Maurer added a comment -

          Hi Alex,

          I should have be more specifc on this. Let me explain.

          We at JAMES builded a IMAP-Storage on top of Jackrabbit. Everything works just fine and it gives us cool options like accessing the mailbox via WebDav etc. But yesterday I came across a problem.

          When we deliver a lot of email (200 concurrent threads) then the IMAP users are mostly unable to access their Mailbox. So I talked to Jukka who told me that the whole JCR-tree is locked on write operations. This even effect parts of the tree which are not really childs of the to be changed node. So while this operations are waiting to get executed (only one at a time because of the locking) no read operations are possible too. Thats really bad for us. So my idea was to be able to replace the current Queue (for the operations), which is FIFO with something else. For example give reads a higher prio or something like that.

          Hope you get an idea about what I'm talkin

          Feel free to ask more questions if you have some..

          Show
          Norman Maurer added a comment - Hi Alex, I should have be more specifc on this. Let me explain. We at JAMES builded a IMAP-Storage on top of Jackrabbit. Everything works just fine and it gives us cool options like accessing the mailbox via WebDav etc. But yesterday I came across a problem. When we deliver a lot of email (200 concurrent threads) then the IMAP users are mostly unable to access their Mailbox. So I talked to Jukka who told me that the whole JCR-tree is locked on write operations. This even effect parts of the tree which are not really childs of the to be changed node. So while this operations are waiting to get executed (only one at a time because of the locking) no read operations are possible too. Thats really bad for us. So my idea was to be able to replace the current Queue (for the operations), which is FIFO with something else. For example give reads a higher prio or something like that. Hope you get an idea about what I'm talkin Feel free to ask more questions if you have some..
          Hide
          Alexander Klimetschek added a comment -

          Do you mean a specific binding on top of JCR, such as spi2dav (because of "request")?

          Show
          Alexander Klimetschek added a comment - Do you mean a specific binding on top of JCR, such as spi2dav (because of "request")?

            People

            • Assignee:
              Unassigned
              Reporter:
              Norman Maurer
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Development