Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-3692

Eliminate unnecessary deserialization of ServiceDefinition objects

    Details

    • Similar issues:
      KULRICE-3709Eliminate unnecessary creation of document type DTO objects
      KULRICE-11625Convert KRMS groovy business objects back to Java
      KULRICE-325eliminate dependency of univeral user reference object refresh on request processing order
      KULRICE-4740Eliminate redundant configuration
      KULRICE-3943Test if Hibernate proxies serialize correctly
      KULRICE-11559superuseractions.tag slows down all pages
      KULRICE-9187Maintenance framework needs a hook that gets executed prior to serialization to XML
      KULRICE-4506Identity the service components in Rice today which are being remoted through KSB object remoting
      KULRICE-2208Consider eliminating the KEN email deliverer since it's redundant
      KULRICE-3395Eliminate duplicate Lockable interfaces
    • Rice Module:
      KSB
    • Application Requirement:
      KFS, Rice

      Description

      The RoutingTableDiffCalculator currently needs to deserialize the ServiceDefinition object to perform the "isSame()" check. Find a way to prevent this deserialization when not necessary. (Perhaps via a CRC/MD5 check of the still-serialized byte stream.) If that fails, then the object would still need to be deserialized for a full check, but it should eliminate most of it.

      1. KULRICE-3692-patch.txt
        38 kB
        Chad Hagstrom
      2. KULRICE-3692-sql.txt
        0.5 kB
        Chad Hagstrom
      3. MessageFetcherTestProblem.txt
        5 kB
        Chad Hagstrom

        Issue Links

          Activity

          Hide
          Chad Hagstrom added a comment -

          I am nearing completion with this issue, but I am having difficulty with getting the serialized-ServiceDefinition checksums generated properly in my database upgrade scripts. Presently, if I start up Rice 1.0.1 to populate the new services into the table (then shut it down), then execute my database upgrade script (which creates the new table, migrates the CLOBs, and generates the checksums on the database side), and then start up Rice 1.0.1.1, the checksums generated on the Java side do not match up with those on the database side, which does not crash the system but does result in all those pre-deployed services being overwritten. Part of the problem is that the serialized ServiceDefinition instances are stored in the database as Base64-encoded strings, which would result in a different checksum value than when computing the checksum on the unencoded serialized ServiceDefinition byte array. However, even if I Base64-encode the serialized ServiceDefinition byte array on the Java side prior to computing the checksum, I am still unable to get the Java-side and database-side checksums to match up, at least when using Oracle (though I suspect I may have similar problems on the MySQL side). If the checksum generation is still needed, then the only other solution I can think of would be to compute the checksums on Base64-decoded versions of the serialized ServiceDefinition CLOBs; such a solution (if it indeed worked) should not be too difficult to implement for Oracle since it does provide Base64-encoding/decoding functions, but it would be more difficult to do this on the MySQL side because I do not believe it currently has any built-in Base64-encoding/decoding functions. Any thoughts on this solution or on a better way to compute the Java-side checksums on Base64-encoded data? Or are the checksums not absolutely necessary for the database upgrade scripts?

          Show
          Chad Hagstrom added a comment - I am nearing completion with this issue, but I am having difficulty with getting the serialized-ServiceDefinition checksums generated properly in my database upgrade scripts. Presently, if I start up Rice 1.0.1 to populate the new services into the table (then shut it down), then execute my database upgrade script (which creates the new table, migrates the CLOBs, and generates the checksums on the database side), and then start up Rice 1.0.1.1, the checksums generated on the Java side do not match up with those on the database side, which does not crash the system but does result in all those pre-deployed services being overwritten. Part of the problem is that the serialized ServiceDefinition instances are stored in the database as Base64-encoded strings, which would result in a different checksum value than when computing the checksum on the unencoded serialized ServiceDefinition byte array. However, even if I Base64-encode the serialized ServiceDefinition byte array on the Java side prior to computing the checksum, I am still unable to get the Java-side and database-side checksums to match up, at least when using Oracle (though I suspect I may have similar problems on the MySQL side). If the checksum generation is still needed, then the only other solution I can think of would be to compute the checksums on Base64-decoded versions of the serialized ServiceDefinition CLOBs; such a solution (if it indeed worked) should not be too difficult to implement for Oracle since it does provide Base64-encoding/decoding functions, but it would be more difficult to do this on the MySQL side because I do not believe it currently has any built-in Base64-encoding/decoding functions. Any thoughts on this solution or on a better way to compute the Java-side checksums on Base64-encoded data? Or are the checksums not absolutely necessary for the database upgrade scripts?
          Hide
          Jonathan Keller added a comment -

          So - more of a question to those that know the KSB:

          Doesn't the service definition table populate itself based on servers that connect to the registry datasource? In that case, could we not, as part of the upgrade script, just empty the table and state that all servers connected to the KSB must be shut down during the upgrade?

          As each came back up, it should install itself back into the table with the new checksum attribute, right?

          Show
          Jonathan Keller added a comment - So - more of a question to those that know the KSB: Doesn't the service definition table populate itself based on servers that connect to the registry datasource? In that case, could we not, as part of the upgrade script, just empty the table and state that all servers connected to the KSB must be shut down during the upgrade? As each came back up, it should install itself back into the table with the new checksum attribute, right?
          Hide
          Eric Westfall added a comment -

          I talked to Garey about your comment Jonathan. As long as we document in the release notes that this is required, I'm fine with that. Chad, please create a KRDOC issue to represent this so that we can make sure that we don't forget to include it.

          Show
          Eric Westfall added a comment - I talked to Garey about your comment Jonathan. As long as we document in the release notes that this is required, I'm fine with that. Chad, please create a KRDOC issue to represent this so that we can make sure that we don't forget to include it.
          Hide
          Chad Hagstrom added a comment -

          I'm almost ready to commit my fixes, but I'm running into problems with the MessageFetcherTest, which runs fine on its own but fails when executed with all of the other KSB unit tests. After discussing the problem with Garey, I attached a patch file and the update SQL on this issue so that he could attempt to reproduce the problem. I've also attached a copy of the test's failure messages for reference.

          Show
          Chad Hagstrom added a comment - I'm almost ready to commit my fixes, but I'm running into problems with the MessageFetcherTest, which runs fine on its own but fails when executed with all of the other KSB unit tests. After discussing the problem with Garey, I attached a patch file and the update SQL on this issue so that he could attempt to reproduce the problem. I've also attached a copy of the test's failure messages for reference.
          Hide
          Chad Hagstrom added a comment -

          Garey was unable to reproduce the unit test problem locally, so I've already committed the changes and Garey has already applied the necessary SQL to the master DBs.

          Show
          Chad Hagstrom added a comment - Garey was unable to reproduce the unit test problem locally, so I've already committed the changes and Garey has already applied the necessary SQL to the master DBs.

            People

            • Assignee:
              Chad Hagstrom
              Reporter:
              Jonathan Keller
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Structure Helper Panel