[Spacewalk-list] Errata application to systems causes Internal Error

[Jan Pazdziora]

On Tue, Aug 14, 2012 at 01:10:58PM +0000, Velayutham, Prakash wrote:
> On Aug 13, 2012, at 10:14 AM, Jan Pazdziora wrote:
> 
> > On Wed, Aug 08, 2012 at 01:46:52PM +0000, Velayutham, Prakash wrote:
> >> Hello,
> >> 
> >> Spacewalk - 1.6
> >> Server OS - CentOS 6.2
> >> 
> >> I am using the API call "system.getUnscheduledErrata" to fetch the recent errata applicable to systems and "system.scheduleApplyErrata" to apply the relevant ones. It seems to go fine with most of the 8 systems I am testing it on except for one, which seems to have a rather large errata set. This is what I see on the server's catalina.out.
> >> 
> >> 2012-08-08 09:30:22,064 [TP-Processor7] WARN  org.hibernate.util.JDBCExceptionReporter - SQL Error: 12899, SQLState: 72000
> >> 2012-08-08 09:30:22,064 [TP-Processor7] ERROR org.hibernate.util.JDBCExceptionReporter - ORA-12899: value too large for column "SPACEWALKSCHEMA"."RHNACTION"."NAME" (actual: 530, maximum: 128)
> >> 
> >> 2012-08-08 09:30:22,064 [TP-Processor7] ERROR org.hibernate.event.def.AbstractFlushingEventListener - Could not synchronize database state with session
> >> org.hibernate.exception.GenericJDBCException: could not insert: [com.redhat.rhn.domain.action.errata.ErrataAction]
> >>        at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103)
> >>        at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91)
> >>        at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
> >>        at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2267)
> >>        at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2660)
> >>        at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:56)
> >>        at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:250)
> >>        at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:234)
> >>        at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:141)
> >>        at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298)
> >>        at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
> >>        at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
> >>        at com.redhat.rhn.common.db.datasource.CachedStatement.stealConnection(CachedStatement.java:857)
> >>        at com.redhat.rhn.common.db.datasource.CachedStatement.execute(CachedStatement.java:440)
> >>        at com.redhat.rhn.common.db.datasource.CachedStatement.execute(CachedStatement.java:430)
> >>        at com.redhat.rhn.common.db.datasource.CachedStatement.execute(CachedStatement.java:336)
> >>        at com.redhat.rhn.common.db.datasource.CachedStatement.execute(CachedStatement.java:341)
> >> …
> >> 
> >> And the client from where I run the API call shows this in the stdout/stderr.
> >> 
> >> ...
> >> Errata is 25978
> >> Errata is 25969
> >> Traceback (most recent call last):
> >>  File "/root/spacewalk-scripts/applyErrata.py", line 67, in <module>
> >>    client.system.scheduleApplyErrata(key, sys, erIds)
> >>  File "/usr/lib64/python2.6/xmlrpclib.py", line 1199, in __call__
> >>    return self.__send(self.__name, args)
> >>  File "/usr/lib64/python2.6/xmlrpclib.py", line 1489, in __request
> >>    verbose=self.__verbose
> >>  File "/usr/lib64/python2.6/xmlrpclib.py", line 1243, in request
> >>    headers
> >> xmlrpclib.ProtocolError: <ProtocolError for bmispacewalkp1.chmcres.cchmc.org/rpc/api: 500 Internal Server Error>
> >> 
> >> Any help to figure out what is going on would be greatly appreciated.
> > 
> > You are hitting a known issue which was fixed in Spacewalk nightly.
> > 
> > -- 
> > Jan Pazdziora
> > Principal Software Engineer, Satellite Engineering, Red Hat
> 
> Hi Jan,
> 
> Thanks for the response. If this is a bug, could you please share the bugzilla ID so I can understand what the issue is? Also, is there a workaround that I can use until I upgrade?
> 

The issues is that for long enough errata names, the action
description is too long for the column.

The possible workaround would be to extend that column in the database
temporarily or add a trigger to truncate the :new.name accordingly..

-- 
Jan Pazdziora
Principal Software Engineer, Satellite Engineering, Red Hat