Hi, *Some explanations:*
Memcached is a tickets storage which accepts only binary data, so the CAS tickets must be serialized into binary. This can be done with regular Java serialization or using the Kryo library (kryoTranscoder): faster and smaller data sizes. To (de)serialize data, Kryo first writes/reads an integer to know the (de)serialized class, either this integer is known because the class has been explicitly registered in Kryo or it is generated if the class has been registered on the fly by Kryo. This line says that unknown classes will be registered on the fly: https://github.com/Jasig/cas/blob/3.5.x/cas-server-integration-memcached/src/main/java/org/jasig/cas/ticket/registry/support/kryo/KryoTranscoder.java#L143 Previous lines define the explicitly registered classes. The registered classes between CAS server v3.5.x and v4.0.x ( https://github.com/Jasig/cas/blob/3.5.x/cas-server-integration-memcached/src/main/java/org/jasig/cas/ticket/registry/support/kryo/KryoTranscoder.java#L105 vs https://github.com/Jasig/cas/blob/4.0.x/cas-server-integration-memcached/src/main/java/org/jasig/cas/ticket/registry/support/kryo/KryoTranscoder.java#L95) have changed: thus explicit registered identifiers have changed. It's a breaking change which explains the error you get in production: "Encountered unregistered class ID". Although your users are not authenticated any more (because of this error), after they have logged in again, new CAS tickets (and Kryo serializations) will be created and the error should go away and everything should work properly. You could also restart all your Memcached servers to empty them. Moreover, classes can be automatically registered and handled by Kryo if they have a default constructor: otherwise, you need to explicitely define how to (de)serialize data (example: https://github.com/Jasig/cas/blob/3.5.x/cas-server-integration-memcached/src/main/java/org/jasig/cas/ticket/registry/support/kryo/KryoTranscoder.java#L111 ) In the CAS server 4.1, I upgraded Kryo to version 3.0 and added the missing classes (unmodifiable collections): https://github.com/Jasig/cas/pull/811/files#diff-58c48dbdf7bbeed1ecafda2dc0018198R142 -> in 4.0.x, unmodifiable collections are not defined in Kryo, that's why you get the error of your development logs. It was not done in 4.0.x. Hopefully, Misagh just backported this upgrade in 4.0.4: https://github.com/Jasig/cas/pull/1067 So the version 4.0.4 of the CAS server will remove this kind of error ("Unable to deserialize object of type"). Hope it makes things clearer. Thanks. Best regards, Jérôme 2015-07-31 0:12 GMT+02:00 Wickham, Jeremy <jeremy.wick...@msstate.edu>: > Last week I attempted to put CAS v4.0.2 into production, things were > rolling along until I noticed that old TGTs were being looked up from the > previous installation (v3.5.2.1) which was causing a wait to occur > essentially bogging down my resources then eventually running out of > PermGen space. Attached you’ll see the stack traces found in my production > log files. > > > > Which then I started seeing a lot of authentication failures and TGTs not > being crated in the audit trail. Below is the audit trail of when I > attempted to log in. > > > > 2015-07-24 07:12:23,757 INFO > [edu.msu.is.inspektr.audit.support.MsuLoggingAuditTrailManager] - WHO: > audit:unknown WHAT: supplied credentials: [jrw16+password] ACTION: > AUTHENTICATION_FAILED APPLICATION: CAS WHEN: Fri Jul 24 07:12:23 CDT 2015 > CLIENT IP ADDRESS: x.x.x.x SERVER IP ADDRESS: x.x.x.x > > 2015-07-24 07:12:23,757 INFO > [edu.msu.is.inspektr.audit.support.MsuLoggingAuditTrailManager] - WHO: > audit:unknown WHAT: 1 errors, 0 successes ACTION: > TICKET_GRANTING_TICKET_NOT_CREATED APPLICATION: CAS WHEN: Fri Jul 24 > 07:12:23 CDT 2015 CLIENT IP ADDRESS: x.x.x.x SERVER IP ADDRESS: x.x.x.x > > > > To note: I ran a load test on my development environment I am not seeing > these errors occurring. I have just recently added a CAS node to my > development instance and will rerun the load test against it and will > review the log files. > > > > Since that wasn’t a success I noticed that v4.0.3 was available, so I > slipped that into my development environment. I uncommented out the > KryoTranscoder property of my memcached client thinking this was the reason > the waits were occurring from the unregistered class. I get an unable to > deserialize object error. See development attachment. > > > > Now that I’m done explaining the situation (I hope well enough) here are a > few questions. > > > > 1. When upgrading CAS, do I need to clear memcached of all the > ticket data? If so, is there a command line way to do this? > > 2. Do you suspect that that the PermGen errors are from the waits > while trying to retrieve an old ticket from the ticket registry? > > 3. I have seen that the unable to deserialize object was asked to > be submitted as a bug. Is this still an outstanding bug? (to note, I am > able to get the memcached stats) > > 4. Are there repercussions by commenting out the KyroTranscoder > property of the memcached client? We are currently running 4 CAS nodes. > > > > Thanks, > > -Jeremy > > > > > > *________________________* > > *Jeremy Wickham* > > Senior Systems Analyst > > Mississippi State University > > jeremy.wick...@msstate.edu > > > > -- > You are currently subscribed to cas-user@lists.jasig.org as: lel...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
