Hi again You say that this might be a timing/threading/sync problem.... do you have any suggestion on how I more easy can reproduce the problem to be able to suply logs...
Regarss LF Den 13 apr. 2017 11:44 skrev "Lars-Fredrik Smedberg" <[email protected]>: > Hi! > > Please see the answers inline below. > > Thanks for the help > > Regards > LF > > > On Wed, Apr 12, 2017 at 3:41 AM, Andy McCright < > [email protected]> wrote: > >> Hi, >> >> Have you tried this same application on previous versions of Liberty and >> had different results? WLP 17.0.0.1 introduced a behavior change with the >> background initialization of servlets that may be contributing to this >> condition. It you did not see this problem with 16.0.0.4 or previous, >> then >> that might be the issue. >> > > To be honest we are not 100% sure of when we saw it the first time. It > might have occured before WLP 17.0.0.1 but the errors we see now are all on > WLP 17.0.0.1. > > >> >> It sounds like the injection is working correctly - it is injecting a >> > > Yes the injection seems to work, the injected proxy is not null and the > NPE is thrown from inside the proxy when there are no ResourceInfo > available on TLS (if I understood it correct). > > >> ThreadLocal proxy. But it sounds like that ThreadLocalInvocationHandler >> has not been configured correctly to point at the underlying ResourceInfo >> object. The way this works so that multiple threads accessing potentially >> different resources from the same field object is by using the >> ThreadLocalInvocationHandler - each thread will be accessing a proxy that >> invokes methods on the object that is specific to that thread. So it is >> possible that there is some timing issue - where the thread's ResourceInfo >> implementation object has not be specified until after it is invoked. >> >> You mentioned that you have other Liberty features installed. What are >> they? If you are using a CDI feature, would it be possible to try this >> > > We have always been using CDI together with JAX-RS 2.0, here is the > feature set we use: > > <!-- Common features --> > <feature>cdi-1.2</feature> > <feature>jaxrs-2.0</feature> > <feature>ejbLite-3.2</feature> > <feature>jaxb-2.2</feature> > <feature>wmqJmsClient-2.0</feature> > <feature>beanValidation-1.1</feature> > <feature>jsonp-1.0</feature> > > <!-- Resource features --> > <feature>apiDiscovery-1.0</feature> > > <feature>appSecurity-2.0</feature> > <feature>collectiveMember-1.0</feature> > <feature>clusterMember-1.0</feature> > <feature>jdbc-4.1</feature> > <feature>jndi-1.0</feature> > <feature>ldapRegistry-3.0</feature> > <feature>localConnector-1.0</feature> > <feature>monitor-1.0</feature> > <feature>restConnector-1.0</feature> > <feature>ssl-1.0</feature> > <feature>zosTransaction-1.0</feature> > <feature>zosWlm-1.0</feature> > <feature>zosRequestLogging-1.0</feature> > > > >> scenario without it (or if you don't have CDI enabled, could you enable >> it)? When the jaxrs-2.0 feature is enabled with the cdi-1.2 feature, then >> the CDI implementation handles the injection. So changing the injection >> mechanism may yield different results. >> >> If none of this helps, it would be good to get a trace of both the working >> and failing scenarios - the logging configuration that I would suggest is: >> <logging traceSpecification="com.ibm.ws.jaxrs*=all:org.apache.cxf.*=a >> ll" >> maxFileSize="0" /> >> By setting the maxFileSize to 0, it keeps all of the data in one trace.log >> file instead of using rolling logs. >> >> > We don't have a deterministic way of reproducing this error. It happens > occasionally (about 15-20% of the times but not on all installation as it > seems). > > >> If all else fails, I would suggest opening a PMR with IBM Support. >> >> > Would you suggest open a PMR that just describes our problem even though > we can not produce code that each time will reproduce the error? > > >> Hope this helps, >> >> Andy >> >> On Tue, Apr 11, 2017 at 4:15 PM, Lars-Fredrik Smedberg < >> [email protected]> >> wrote: >> >> > Hi! >> > >> > We are using running WLP 17.0.0.2 using the JAX-RS 2.0 feature (among >> > others) to be able to inject (using @Context) ResourceInfo. >> > >> > We are calling getResourceClass() and getResourceMethod() on the >> injected >> > ResourceInfo to get the matching resource/method (for statistical >> logging >> > and more). >> > >> > Sometimes we get a NPE when calling getResourceClass(). The NPE happens >> > internally in the proxy being injected, see stacktrace below. >> > We inject the ResourceInfo in a JAX-RS request filer (@Provider, >> > @Priority...). >> > >> > It is hard to reproduce consistently since it does not happen all the >> time, >> > I try to describe the behavior below: >> > >> > - It only occurs (sometimes) after application server start and when it >> > occurs it occurs for ALL requests (that is NO request using the request >> > filter can successfully call getResourceClass() on the injected >> > ResourceInfo). >> > - When it occurs it occurs for ALL subsequent calls and does not >> dissapere >> > until the application server has been restarted. >> > - If it works after application server start it seems to work for ALL >> > subsequent requests. >> > - ResourceInfoUtils:33 (as seen in the stacktrace below) calls >> > getResourceClass() on the injected ResourceInfo. >> > >> > Has anyone seen this or similar problems? CXF or IBM WLP integration >> > problem? Appreciate any help on this. >> > >> > Regards >> > Lars-Fredrik Smedberg >> > >> > -------------------------------------------- >> > >> > Stacktrace: >> > >> > javax.ws.rs.container.ResourceInfo context class has not been injected. >> > Check if ContextProvider supporting this class is registered >> > java.lang.NullPointerException: javax.ws.rs.container.ResourceInfo >> context >> > class has not been injected. Check if ContextProvider supporting this >> class >> > is registered >> > at >> > org.apache.cxf.jaxrs.impl.tl.ThreadLocalInvocationHandler.invoke( >> > ThreadLocalInvocationHandler.java:42) >> > at com.sun.proxy.ÅProxy210.getResourceClass(Unknown Source) >> > at >> > shb.rast.ws.rs.filter.ResourceInfoUtils.getTemplateUri( >> > ResourceInfoUtils.java:33) >> > at >> > shb.rast.ws.rs.filter.AvailabilityRequestFilter.getAction( >> > AvailabilityRequestFilter.java:160) >> > at >> > shb.rast.ws.rs.filter.AvailabilityRequestFilter.filter( >> > AvailabilityRequestFilter.java:92) >> > at >> > org.apache.cxf.jaxrs.utils.JAXRSUtils.runContainerRequestFilters( >> > JAXRSUtils.java:1686) >> > at >> > org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest( >> > JAXRSInInterceptor.java:244) >> > at >> > org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage( >> > JAXRSInInterceptor.java:85) >> > at >> > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept( >> > PhaseInterceptorChain.java:308) >> > at >> > org.apache.cxf.transport.ChainInitiationObserver.onMessage( >> > ChainInitiationObserver.java:124) >> > at >> > org.apache.cxf.transport.http.AbstractHTTPDestination.invoke( >> > AbstractHTTPDestination.java:265) >> > at >> > com.ibm.ws.jaxrs20.endpoint.AbstractJaxRsWebEndpoint.invoke( >> > AbstractJaxRsWebEndpoint.java:134) >> > at >> > com.ibm.websphere.jaxrs.server.IBMRestServlet. >> > handleRequest(IBMRestServlet.java:149) >> > at >> > com.ibm.websphere.jaxrs.server.IBMRestServlet.doGet( >> > IBMRestServlet.java:115) >> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) >> > at >> > com.ibm.websphere.jaxrs.server.IBMRestServlet.service( >> > IBMRestServlet.java:99) >> > at >> > com.ibm.ws.webcontainer.servlet.ServletWrapper. >> > service(ServletWrapper.java:1290) >> > at >> > com.ibm.ws.webcontainer.servlet.ServletWrapper. >> > handleRequest(ServletWrapper.java:778) >> > at >> > com.ibm.ws.webcontainer.servlet.ServletWrapper. >> > handleRequest(ServletWrapper.java:475) >> > at >> > com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget( >> > WebAppFilterChain.java:152) >> > at >> > com.ibm.ws.webcontainer.filter.WebAppFilterChain. >> > doFilter(WebAppFilterChain.java:94) >> > >> > >> > -- >> > Med vänlig hälsning / Best regards >> > >> > Lars-Fredrik Smedberg >> > >> > STATEMENT OF CONFIDENTIALITY: >> > The information contained in this electronic message and any >> > attachments to this message are intended for the exclusive use of the >> > address(es) and may contain confidential or privileged information. If >> > you are not the intended recipient, please notify Lars-Fredrik Smedberg >> > immediately at [email protected], and destroy all copies of this >> > message and any attachments. >> > >> > > > > -- > Med vänlig hälsning / Best regards > > Lars-Fredrik Smedberg > > STATEMENT OF CONFIDENTIALITY: > The information contained in this electronic message and any > attachments to this message are intended for the exclusive use of the > address(es) and may contain confidential or privileged information. If > you are not the intended recipient, please notify Lars-Fredrik Smedberg > immediately at [email protected], and destroy all copies of this > message and any attachments. >
