> We are seeing more of the following exceptions then we use to. My guess is > that one or more of the service urls are getting too long.
The problem in the stack trace you cited is in the SERVICES_GRANTED_ACCESS_TO column. That column stores a serialized List of all Services that have been accessed during the CAS SSO session. There are a lot of factors that impact the number of services that can be accessed before the 2K (IIRC) limit is exceeded on BLOB type, but for users that are very active in an SSO session it can happen. It appears to be entirely platform-specific; many folks have reported trouble with MySQL, but I've not seen any reports for other RDBMS platforms. > I can go increase the field length in question on the DB > but I would like the update to be based on a little data. Anyone have any > ideas? This is a known problem with MySQL. Use the LONGBLOG data type for the SERVICES_GRANTED_ACCESS_TO column. I believe it's discussed on the JpaTicketRegistry page in the CASUM wiki. > Caused by: java.sql.BatchUpdateException: Data truncation: Data too long for > column 'SERVICES_GRANTED_ACCESS_TO' at row 1 At least it's throwing. MySQL can be configured to simply silently truncate data for some fields (this used to be the default; not sure if it is any longer). It's far better to throw than fail silently. M -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
