[GLASSFISH-18648] intermittent failure with Jersey client Created: 19/Apr/12  Updated: 14/Feb/13  Resolved: 14/Feb/13

Status: Resolved
Project: glassfish
Component/s: jax-rs
Affects Version/s: 4.0_b32_ms1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: carlavmott Assignee: Jakub Podlesak
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Mac OS 10.5.8 but should happen on all OS


Attachments: File SimpleSessionDemo.war    

 Description   

Metric Gatherers are using REST to collect data from instances. Around April 5th my code stopped working and I would see the following stack trace when I tried to create a Jersey client. With my latest testing I noticed that there are times when I can create the client and then get data but that things work intermittently. In other words, I see a failure then after some time I see that the data is collected for some time and then again it fails. I can create an alert and see that data is collected but I also see the stack traces. Not sure why this is happening.

Currently, the elasticity code is checked in but will not run unless a system property start.elasticity is set to true. The file that creates the Jersey client is CollectMetricData. There I create a client each time I try to collect data. Could that be part of the problem?

To recreate the issue (I've attached the app that I used to test).

start the server with the system property start.elasticity=true
asadmin create-ims-config-native
asadmin deploy SimpleSessionDemo.war
asadmin create-tenant acme
asadmin create-jvm-alert --environment SimpleSessionDemo --tenantid acme alert1

tail the server log and see that the stack trace or metric values are printed.

[#|2012-04-19T15:16:55.793-0700|SEVERE|44.0|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=20;_ThreadName=Thread-41;|java.lang.IllegalStateException: WEB9031: WebappClassLoader unable to load resource [com.sun.jersey.core.impl.provider.xml.SAXParserContextProvider], because it has not yet been started, or was already stopped
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1402)
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1360)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at com.sun.jersey.core.reflection.ReflectionHelper.classForNameWithException(ReflectionHelper.java:236)
at com.sun.jersey.spi.service.ServiceFinder$AbstractLazyIterator.hasNext(ServiceFinder.java:744)
at com.sun.jersey.spi.service.ServiceFinder.toClassArray(ServiceFinder.java:595)
at com.sun.jersey.core.spi.component.ProviderServices.getServiceClasses(ProviderServices.java:318)
at com.sun.jersey.core.spi.component.ProviderServices.getProviderAndServiceClasses(ProviderServices.java:297)
at com.sun.jersey.core.spi.component.ProviderServices.getProvidersAndServices(ProviderServices.java:204)
at com.sun.jersey.core.spi.factory.InjectableProviderFactory.configure(InjectableProviderFactory.java:106)
at com.sun.jersey.api.client.Client.init(Client.java:263)
at com.sun.jersey.api.client.Client.access$000(Client.java:118)
at com.sun.jersey.api.client.Client$1.f(Client.java:191)
at com.sun.jersey.api.client.Client$1.f(Client.java:187)
at com.sun.jersey.spi.inject.Errors.processWithErrors(Errors.java:193)
at com.sun.jersey.api.client.Client.<init>(Client.java:187)
at com.sun.jersey.api.client.Client.<init>(Client.java:159)
at com.sun.jersey.api.client.Client.create(Client.java:669)
at org.glassfish.elasticity.metrics.util.CollectMetricData.getRestData(CollectMetricData.java:82)
at org.glassfish.elasticity.metrics.jvm.memory.JVMMemoryMetricHolder$JVMInstanceMemoryHolder.gatherMetric(JVMMemoryMetricHolder.java:264)
at org.glassfish.elasticity.metrics.jvm.memory.JVMMemoryMetricHolder.gatherMetric(JVMMemoryMetricHolder.java:147)
at org.glassfish.elasticity.engine.container.ElasticServiceContainer$MetricGathererWrapper.run(ElasticServiceContainer.java:397)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)

#]


 Comments   
Comment by Bhakti Mehta [ 19/Apr/12 ]

Assigning this to Jakub

Comment by Jakub Podlesak [ 20/Apr/12 ]

I have 3 comments to the issue:

1) we have not changed the client code in Jersey recently. The issue then can not be caused by a regression in the Jersey client code.
Something else must have changed, which caused the regression.

2) You should avoid creating a new client each time you want to get data, as client creation is an expensive operation.

3) We are about to update Jersey version in GlassFish 4.x soon, particularly to switch
to Jersey 2, where things have changed dramatically. I presume things would be fixed as part of the upgrade effort.

Comment by Jakub Podlesak [ 14/Feb/13 ]

Resolving as invalid, since Jersey has been upgraded and referred classes are no longer present in GF.
I am not able to reproduce the bug with the latest GF build.
Feel free to re-open, but then please provide updated info on the bug and reproducible test case.

Generated at Thu Sep 29 08:25:10 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.