Print manager issue after ENV upgrade

 6 Replies
 0 Subscribed to this topic
 27 Subscribed to this forum
Sort:
Author
Messages
George Graham
Veteran Member
Posts: 201
Veteran Member

    Basic in place upgrade of environment only from 9.0.0.3 to 9.0.1 4. After doing this about 10 users (at least that is how many have reported an issue) cannot get to their print manager. It is kicking back and unknown error into IOS from the printmanager servlet. Additionally if another user tries to open one of these user's print jobs it kicks out the error as well.

    We set up an identical user (roles, groups, everything) and it works fine. The user(s) in question operate with no issues in everything else.

    Almost every user has the same batch role so it does not appear to be a security issue - but when we turn security off this problem goes away. These are LS users only - no LAUA.

    Been working with Lawson but we have not come up with anything so far. Thought I would see if anyone has encountered this or had any thoughts.....

    MattD
    Veteran Member
    Posts: 94
    Veteran Member
      What is the exact error?

      If it works with security off it has to be a security issue.

      Have you put debug on and seen what shows in the logs?
      George Graham
      Veteran Member
      Posts: 201
      Veteran Member
        Invalid server response calling:
        /servlet/JobServer?_TYPE=printmanager&_USERNAME=ERP\xxxxx&_PAGESIZE=25&_ONCACHE+12863
        An unknown error occurred. Please contact your system admin.

        Yes - we've turned on debugging for security but there seems to be nothing kicking out that is defining the error. It also happens when you try to go to TYPE=joblist

        The only thing that shows up in lase that even looks like a problem is this:

        2010-10-04 18:49:49 com.lawson.lawsec.default.FINEST com.lawson.lawsec.server.SecurityEventHandler.run()
        SecurityEventHandler #21179 got exception.
        com.lawson.security.server.LawsonNetException: Got exception while reading from connection /10.10.10.162,5910.
        Stack Trace : com.lawson.security.server.LawsonNetException: Got exception while reading from connection /10.10.10.162,5910.
        at com.lawson.security.server.Connection.read(Connection.java:193)
        at com.lawson.lawsec.server.SecurityEventHandler.run(Unknown Source)
        Caused by: java.net.SocketException: Connection reset
        at java.net.SocketInputStream.read(SocketInputStream.java:168)
        at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
        at java.io.BufferedInputStream.read(BufferedInputStream.java:235)
        at java.io.DataInputStream.readInt(DataInputStream.java:353)
        at com.lawson.security.server.Connection.readMsg(Connection.java:450)
        at com.lawson.security.server.Connection.read(Connection.java:170)
        ... 1 more

        which 5910 is SERVER_PORT from LDAP.

        I agree it is security related - but it seems to be more related to the resource than the roles, etc... since we can create the same role setup with no problems -

        Lawson's been looking for two days now - trying to dig into the servlet call to see what component of security this might be tripping on. It does not appear to be the batch - and that would impact all users globally here.
        George Graham
        Veteran Member
        Posts: 201
        Veteran Member

          Also I know there is a related KB article related to joblist - we did run jobinteg and that did not correct the error....and, again, I also think this is security based somehow.

          MattD
          Veteran Member
          Posts: 94
          Veteran Member
            Do you know how many jobs the users in question have? Do they have a lot more then the general population of users?

            I have seen instances where it couldn't load due to size or timeout when attempting to load data.
            George Graham
            Veteran Member
            Posts: 201
            Veteran Member
              Resolution!

              There was a single custom attribute in security that was created a couple of years ago - and at that time it was called CompanyControl. So - as you may now guess - the newer LDAP schema delivers a standard attribute called by the same name! After some tweaking everything works.

              Moral to the story: Never customize! But if you have to, use UNIQUE naming conventions!!!
              mark.cook
              Veteran Member
              Posts: 444
              Veteran Member
                We had a similar issue after installing the latet ESP. KB article 5410538 pointed to orphan USERGRPDTL records that caused errors after service pack was installed. We had two records that were fixed in our environment that caused.