Details

    • Type: Bug Fix
    • Status: Open
    • Priority: 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:
    • 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...

        Attachments

          Issue Links

            Activity

            Hide
            tschneeb 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
            tschneeb 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
            jkeller 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
            jkeller 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:
                jkeller Jonathan Keller
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated: