Details

    • Type: Bug Fix Bug Fix
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.0.3.1
    • Fix Version/s: Backlog
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
    • Similar issues:
      KULRICE-4836Some KIM DTO objects (mostly labeled in KIM as 'Info' objects) do not properly serialize when the service returning them is consumed over the bus
      KULRICE-4496Speed Test: Soap vs java serialization for our remoted services
      KULRICE-9505Implement proper support for serialization of maintenance document data in the krad-data framework
      KULRICE-2873Lookup uses the LookupForm as BO?
      KULRICE-9141uif-navigation does not render properly on IE9
      KULRICE-8353Lookup controller does not check return of validation call
      KULRICE-8829UrlFactory.parameterizeUrl(..) does not properly encode & delimiter in URLs
      KULRICE-4138EditablePropertiesHistoryHolder causes session serialization exception on tomcat start/stop
      KULRICE-13316ActionRequestServiceImpl#doesPrincipalHaveRequest does not properly use QueryByCriteria API
      KULRICE-3784KEW Thin Client integration does not work properly
    • Rice Module:
      KNS
    • Application Requirement:
      KFS, Rice
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      Rice can not cluster properly because not all objects linked to the forms in the base are Serializable.

      I finally found the cause of this on my KFS sessions during implementation. (We have real-time session replication between Tomcat servers.)

      It turns out that LookupForm references a Lookupable, which contains a LookupableHelperService, whose base version has references to a number of services which are not Serializable.

      It seems that this ends up in the session when you do a lookup from within a lookup.

      I found that you could set this: -Dsun.io.serialization.extendedDebugInfo=true and Java will give information on the exact path to the object which caused the serialization exception.

      I added this code to the KualiAction.execute() method locally to find the problem without needing clustered servers:

              Enumeration attributes = request.getSession().getAttributeNames();
              while ( attributes.hasMoreElements() ) {
                  String name = (String) attributes.nextElement();
                  try {
                      System.out.println( "Testing Session Attribute: " + name );
                      ObjectOutputStream oos = new ObjectOutputStream( new ByteArrayOutputStream() );
                      oos.writeObject(request.getSession().getAttribute(name));
                      oos.close();
                  } catch ( NotSerializableException ex ) {
                      System.err.println( "Unable to serialize object in session: " + name + " -- of type: " + request.getSession().getAttribute(name).getClass() );
                      System.err.println( ex.getMessage() );
                  }
              }
      

      I'm going to set the Lookupable on LookupForm transient in my local copy of the class and see if that cleans things up. I don't know if that will cause problems if users are bounced between servers or not. I think the form will auto-create the lookupable if needed, but if it is maintaining any state...

        Issue Links

          Activity

          Hide
          Travis Schneeberger added a comment -

          I actually created a Servlet Filter when on the KC project to look for all session scoped attributes that are not serializable. I suggest we do the same for rice. We could enable it only at development time. If the filter finds a non-serializable object it could log a message, write something to the servlet response, or even take the user to an error page. In rice 2.0 this would go in the development-tools module.

          I think a Servlet Filter might be better solution moving forward as it would not rely on struts.

          There are other things we may consider for a filter like this like monitoring session size, response time, etc.

          Show
          Travis Schneeberger added a comment - I actually created a Servlet Filter when on the KC project to look for all session scoped attributes that are not serializable. I suggest we do the same for rice. We could enable it only at development time. If the filter finds a non-serializable object it could log a message, write something to the servlet response, or even take the user to an error page. In rice 2.0 this would go in the development-tools module. I think a Servlet Filter might be better solution moving forward as it would not rely on struts. There are other things we may consider for a filter like this like monitoring session size, response time, etc.
          Hide
          Jonathan Keller added a comment -

          I think a development-time monitoring filter is a great idea. I only hacked Struts to do my one-off testing for this. The more tools we have to prevent things from getting in in the first place, the better.

          Show
          Jonathan Keller added a comment - I think a development-time monitoring filter is a great idea. I only hacked Struts to do my one-off testing for this. The more tools we have to prevent things from getting in in the first place, the better.

            People

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

              Dates

              • Created:
                Updated:

                Structure Helper Panel