ServiceMix
  1. ServiceMix
  2. SM-1694

serviceassembly deployment is blocked/delayed by already loaded serviceassemblies

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 3.3
    • Fix Version/s: None
    • Component/s: servicemix-assembly
    • Labels:
      None
    • Patch Info:
      Patch Available

      Description

      We notice an issue with servicemix 3.3 where serviceassemblies that start processing after start up, block other serviceassemblies from deploying/starting up. The issue occurs when the serviceassembly that is deployed does not immediately return from a serviceunit in its route. Fix SM-1171 introduced a lock during routing causing service units that take a longer time processing data to block other serviceassemblies from starting up. Attaching modification to SM-1171 patch reducing the scope of the lock so it doesn't interfere with other assembly startups.

        Issue Links

          Activity

          GShenoy created issue -
          GShenoy made changes -
          Field Original Value New Value
          Attachment sm-1694.diff [ 17297 ]
          GShenoy made changes -
          Description We notice an issue with servicemix 3.3 where serviceassemblies that start processing after start up, block other serviceassemblies from deploying/starting up. The issue occurs when the serviceassembly that is deployed does not immediately return from a serviceunit in its route. Fix SM-1171 introduced a lock during routing causing service units that take a longer time processing data to block other serviceassemblies from starting up. Adding a patch that should fix SM-1171 while reducing the scope of the lock so it doesnt interfere with assembly startup. We notice an issue with servicemix 3.3 where serviceassemblies that start processing after start up, block other serviceassemblies from deploying/starting up. The issue occurs when the serviceassembly that is deployed does not immediately return from a serviceunit in its route. Fix SM-1171 introduced a lock during routing causing service units that take a longer time processing data to block other serviceassemblies from starting up. Attaching modification to SM-1171 patch reducing the scope of the lock so it doesn't interfere with other assembly startups.
          GShenoy made changes -
          Link This issue is related to SM-1171 [ SM-1171 ]
          Hide
          Guillaume Nodet added a comment -

          Your patch just make the lock useless and will re-enable SM-1171 i think.
          We plan to improve the SA startup as part of SM-1607. I think this would need to acquire the write lock before starting all SAs and releasing it once they have all been started. This should solve your problem too I think.

          Show
          Guillaume Nodet added a comment - Your patch just make the lock useless and will re-enable SM-1171 i think. We plan to improve the SA startup as part of SM-1607 . I think this would need to acquire the write lock before starting all SAs and releasing it once they have all been started. This should solve your problem too I think.
          Guillaume Nodet made changes -
          Link This issue depends upon SM-1607 [ SM-1607 ]
          Hide
          GShenoy added a comment -

          My understanding is that the lock as it existed in patch for SM-1171 was only to prevent reads before the assembly startup has commenced when autodeployment holds a write lock. The modified patch provided allows for that here. Hence i feel it covers SM-1171. I definitely support SM-1607 since that would remove this extra redundant step of readlocking everytime we route. But until then the issue of serviceassemblies being blocked will exist.

          Show
          GShenoy added a comment - My understanding is that the lock as it existed in patch for SM-1171 was only to prevent reads before the assembly startup has commenced when autodeployment holds a write lock. The modified patch provided allows for that here. Hence i feel it covers SM-1171 . I definitely support SM-1607 since that would remove this extra redundant step of readlocking everytime we route. But until then the issue of serviceassemblies being blocked will exist.
          Jeff Turner made changes -
          Project Import Sat Nov 27 00:46:19 EST 2010 [ 1290836779991 ]
          Jeff Turner made changes -
          Link This issue jira_subtask_outward SMXCOMP-344 [ SMXCOMP-344 ]
          Hide
          Gert Vanthienen added a comment -

          Bulk-closing older issues for Apache ServiceMix 3.x since we're no longer actively working on these at the moment.

          Show
          Gert Vanthienen added a comment - Bulk-closing older issues for Apache ServiceMix 3.x since we're no longer actively working on these at the moment.
          Gert Vanthienen made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Resolution Won't Fix [ 2 ]

            People

            • Assignee:
              Unassigned
              Reporter:
              GShenoy
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development