Redirected to maintenance page after login

[TS]

I uploaded an invalid fragment definition into our 5.8.2 uPortal instance.  Afterwards, the system started redirecting me to our maintenance page after login.  I was able to gain access to the system via another node, and uploaded the saved copy of the fragment definition.  Now that node exhibits the same symptom.  I tried restarting the application on the affected nodes, but no change.  For now I am leaving the httpd service off on the affected nodes.  Is there a way to remedy this, short of restoring from backup?

# I see this in the localhost.2024-01-11.log
11-Jan-2024 17:48:05.345 SEVERE [ajp-nio-127.0.0.1-8009-exec-1] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [AuthenticationDispatcherServlet] in context with path [/uPortal] threw exception [Request processing failed; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'userLayoutManager' defined in file [/home/portal/uPortal/tomcat/webapps/uPortal/WEB-INF/classes/properties/contexts/layoutContext.xml]: Invocation of init method failed; nested exception is org.apereo.portal.PortalException: Exception encountered while reading a layout for userId=107789, profileId=212569] with root cause
        org.springframework.dao.IncorrectResultSizeDataAccessException: Incorrect result size: expected 1, actual 2
                at org.springframework.dao.support.DataAccessUtils.uniqueResult(DataAccessUtils.java:92)
                at org.apereo.portal.layout.dlm.FragmentDefinitionDao.getFragmentDefinitionByOwner(FragmentDefinitionDao.java:120)
                at sun.reflect.GeneratedMethodAccessor341.invoke(Unknown Source)
                at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
                at java.lang.reflect.Method.invoke(Method.java:498)
                at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:333)
…

[TS]

To reduce downtime, we decided to move forward with restoring the database from backup, to a point just prior to the ill-fated fragment definition upload.  The system appears to be functioning normally now.

I still wouldn't mind finding a solution that didn't require a database restore.  Or, at least, I would like to recommend adding file validation to the import function.  That may help prevent issues like this.

[Mary Elder]

Hi,

A long time ago we had a similar issue. I uploaded a fragment definition with a changed fragment name, but the same OwnerID. I can't now remember the error behaviour in uPortal, but the error log message we got looks similar.

The issue was that we'd created duplicate “OWNER_ID” values in UP_DLM_EVALUATOR table entries (and associated records in UP_DLM_EVALUATOR_PAREN). We did manage to fix it without a full db restore by manually removing the duplicate record (and associated ones) from both UP_DLM_EVALUATOR and UP_DLM_EVALUATOR_PAREN tables and reimporting the original fragment definition. However, we only had the issue on our dev server so were probably a little less worried about experimenting than we might have been on live.

See https://apereo.atlassian.net/browse/UP-4679 for more info on the issue that we had.

Thanks,
Mary