11-30-2011 04:47 PM
I'm having issues with the groups failing when I click the 'Edit' tab more than once inside a group in the Admin section. If I click it once and wait 5-10 seconds it will load the edit screen, but there is no contextual feedback to show the click was registered. If I click it again before the edit screen has loaded, the search crashes and sends me to the 'an unexpected error occurred' page. This occurs in several other places, like loading a group or uploading a file occasionally. I'm on a fast ethernet (>2MB/s actual speed) and the server is on my local LAN. I don't have that many groups or users, probably ~7 groups with 1-2 sublevels max and ~40 users, so I'm not sure why it is moving so slow and/or not blocking a second click before page loads. I've commented out essentially all of the logging in the log4j.xml file, so that's not the issue either.
My specs are:
/>
-Nuxeo 5.4.2-HF05
/>
-Ubuntu 10.04 LTS
/>
-LDAP authentication, SSL with local java certstore
/>
-If you need any more info please post here, or if there is a better way to get more debugging info I'd greatly appreciate it
/>
-The below 'Error reading 'searchEnabled' on type...' error is logged 4 or 5 times, I've included only the one for reference
Here are the error portions of the stack trace and context dump:
com.sun.faces.util.RequestStateManager : {com.sun.faces.renderKitImplForRequest=org.ajax4jsf.renderkit.ChameleonRenderKitFactory@b29cc93, com.sun.faces.INVOCATION_PATH=.faces, com.sun.faces.ELResolverChainType=Faces, com.sun.faces.ExternalContextImpl=com.sun.faces.context.ExternalContextImpl@486a39cc}
/>
org.nuxeo.theme.url : nxtheme://theme/default//jsf-facelets/admin/default/default
/>
org.nuxeo.theme.default.theme : galaxy/default
/>
org.richfaces.component.DecodesPhaseNotifiyingListener:_AFTER_DECODE_PHASE : true
/>
org.nuxeo.theme.default.engine : default
/>
javax.servlet.request.key_size : 128
/>
org.jboss.seam.core.manager : Manager(null)
/>
stackTrace : javax.servlet.ServletException: //default//jsf-facelets/admin/default/default @196,56 test="#{userServicesContext.searchEnabled}": Error reading 'searchEnabled' on type org.nuxeo.ecm.webapp.context.UserServicesContext_$$_javassist_4
javax.servlet.request.ssl_session : (PROPER TOKEN REDACTED)
/>
securityError : false
/>
facelets.ContentType : text/html
/>
org.jboss.seam.transaction.synchronizations : org.jboss.seam.transaction.SeSynchronizations@35f8a538
/>
org.jboss.seam.faces.validation : org.jboss.seam.faces.Validation@57271b36
/>
javax.servlet.request.cipher_suite : TLS_DHE_RSA_WITH_AES_128_CBC_SHA
/>
org.jboss.seam.web.requestContextPath : /nuxeo
/>
org.nuxeo.ecm.platform.ui.web.binding.alias.AliasVariableMapper_MARKER : {}
/>
nuxeo.disable.redirect.wrapper : true
/>
org.jboss.seam.core.conversationPropagation : org.jboss.seam.core.ConversationPropagation@486ba2ed
/>
org.nuxeo.theme.default.perspective : default
/>
org.ajax4jsf.application.AjaxStateManager.AJAX_VIEW_SEQUENCE : j_id8
/>
user_message : an unexpected error occurred
/>
NuxeoExceptionHandlerMarker : true
/>
org.jboss.seam.transaction.transaction : org.jboss.seam.transaction.Transaction@12959ac0
/>
exception_message : @In attribute requires non-null value: userServicesContext.navigationContext
/>
org.jboss.seam.web.servletContexts : org.jboss.seam.web.ServletContexts@1be2bcc8
/>
org.jboss.seam.web.requestServletPath : /view_admin.faces
/>
org.jboss.seam.core.events : org.jboss.seam.core.Events@42d7fcc5
12-02-2011 08:44 AM
Hi,
It looks like you're experiencing this issue: https://jira.nuxeo.com/browse/NXP-7935
The fix here consists in using features provided by the ajax framework to prevent concurrent ajax calls to the server. Maybe you can wait for the 5.5 release and upgrade, or apply patches on you instance.
As these calls often require seam components that are kept in the conversation, and as ajax calls do preserve the conversation context, Seam may receive multiple calls using the same context, and will require the previous call to a given component to be finished before processing a new one. If a configurable timeout is reached, the new call will be processed in a temporary conversation that does not hold the original conversation context, so this call is probably going to fail. In come cases, the conversation context is completely lost.
This is visible here in your stack trace:
org.jboss.seam.core.manager : Manager(null)
Here the manager should show the conversation id (here it's null, but it could look like Manager(1) or Manager(18) for instance). It should look like Manager(0NXMAIN1) if it was a proper context initialized by the Nuxeo application.
You can also read http://doc.nuxeo.com/x/pgU7 that gives more details on how to address this issues.
Note that this only explains the error page, i cannot say with the information you gave why you have the impression the rendering lags.
12-02-2011 08:44 AM
Hi,
It looks like you're experiencing this issue: https://jira.nuxeo.com/browse/NXP-7935
The fix here consists in using features provided by the ajax framework to prevent concurrent ajax calls to the server. Maybe you can wait for the 5.5 release and upgrade, or apply patches on you instance.
As these calls often require seam components that are kept in the conversation, and as ajax calls do preserve the conversation context, Seam may receive multiple calls using the same context, and will require the previous call to a given component to be finished before processing a new one. If a configurable timeout is reached, the new call will be processed in a temporary conversation that does not hold the original conversation context, so this call is probably going to fail. In come cases, the conversation context is completely lost.
This is visible here in your stack trace:
org.jboss.seam.core.manager : Manager(null)
Here the manager should show the conversation id (here it's null, but it could look like Manager(1) or Manager(18) for instance). It should look like Manager(0NXMAIN1) if it was a proper context initialized by the Nuxeo application.
You can also read http://doc.nuxeo.com/x/pgU7 that gives more details on how to address this issues.
Note that this only explains the error page, i cannot say with the information you gave why you have the impression the rendering lags.
12-02-2011 04:20 PM
Thanks. The lagging has something to do with ldap vs ldaps, because when I revert back to standard ldap the processing time goes from 8-20secs down to a second or under. I'm thinking it may have something to do with a cert lookup, I will post back when I find the issue.
Find what you came for
We want to make your experience in Hyland Connect as valuable as possible, so we put together some helpful links.