Hi Lars-Fredrik, If the issue is related to background servlet initialization, then you may be able to reproduce the problem by invoking the services as early as possible - maybe write a script that starts the server (in the background) and then invokes the service repeatedly using a command line tool like curl.
As for opening a PMR, you could certainly open one with the information you have provided so far, but the more details you can provide, the better. My team and I will be moving to a new building tomorrow and Monday, so I may be slow to respond. I would like to try to reproduce this issue with a smaller test case. Thanks, Andy On Thu, Apr 13, 2017 at 6:25 AM Lars-Fredrik Smedberg <[email protected]> wrote: > 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. > > >
