jBPM
  1. jBPM
  2. JBPM-3400

Conditional unmarshalling of processInstance (via MarshallingConfiguration) causes errors when unmarshalling

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved (View Workflow)
    • Priority: Major Major
    • Resolution: Done
    • Affects Version/s: jBPM 5.2
    • Fix Version/s: jBPM 5.2
    • Component/s: Runtime Engine
    • Security Level: Public (Everyone can see)
    • Labels:
      None
    • Similar Issues:
      Show 10 results 

      Description

      See this commit: https://github.com/droolsjbpm/drools/commit/e1e913de731b6011f1d2f4c290e327b60b388a63.

      What I'm seeing in my test results is that this change makes it complicated to unmarshall the process.

      The problem is that this makes marshalling of a processInstance dependent on booleans set at runtime (marshallProcessInstances and marshallWorkItems). But we can't know what those booleans were set to if we then try to unmarshall the process later... etc.

      The fix for this bug ensures that the anything written by the OutputMarshaller, is also read in by the InputMarshaller.

        Issue Links

          Activity

          Hide
          Marco Rietveld
          added a comment -

          It doesn't make sense to "conditionally" UNmarshall bytes: what are you going to do – "pretend" that the bytes are not there and ignore them (when they screw up the unmarshalling process)?

          Show
          Marco Rietveld
          added a comment - It doesn't make sense to "conditionally" UNmarshall bytes: what are you going to do – "pretend" that the bytes are not there and ignore them (when they screw up the unmarshalling process)?
          Show
          Marco Rietveld
          added a comment - See the following commits as well: https://github.com/droolsjbpm/drools/commit/12cfb9f22719a6122072460ae1e5da452ccc8411 https://github.com/droolsjbpm/drools/commit/0dc2ef742078138e8747b17093d6ae7163ce0e4a
          Hide
          Kris Verlaenen
          added a comment -

          Marco,

          The idea of making this configurable are two use cases:

          • persist all state into the session, this include processes and work items (think for example about a rule application with a few ruleflows)
          • persist all session state but soter process instances and work items separately (for scalability reasons etc.), think of this as the normal BPM engine approach (as we don't want to keep all instances in memory and only load on demand

          Which configuration you use is like a runtime configuration. It is true that you can only load state if you use the same configuration as was used when storing the session, but I don't think that is an issue.

          Not supporting the configuration of this would not allow us to support both use cases as described above, or am I missing something?

          Kris

          Show
          Kris Verlaenen
          added a comment - Marco, The idea of making this configurable are two use cases: persist all state into the session, this include processes and work items (think for example about a rule application with a few ruleflows) persist all session state but soter process instances and work items separately (for scalability reasons etc.), think of this as the normal BPM engine approach (as we don't want to keep all instances in memory and only load on demand Which configuration you use is like a runtime configuration. It is true that you can only load state if you use the same configuration as was used when storing the session, but I don't think that is an issue. Not supporting the configuration of this would not allow us to support both use cases as described above, or am I missing something? Kris

            People

            • Assignee:
              Marco Rietveld
              Reporter:
              Marco Rietveld
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: