Bug 596680

Jochen, are you able to provide a stripped down example of the bogus embedded war?

I was trying locally with a EAP 5.0.1 instance and am not seeing the issue and want to be sure I am looking at the right thing.

Thanks
   Heiko

I also just tried with EAP 5.0.0 and the current release-3.0.0 branch (from yesterday) and my embedded war shows availability just fine.

Jochen: please provide us with a stripped down version of your ear file so we can try to reproduce it.

  Heiko

Jochen,
if you have steps to reproduce, please re-open this bz-entry.

  Heiko

Hello Heiko,

sorry for not responding earlier, I had a holiday.....

This morning I installed 3.0.0 final and I still have the problem with our root-web-application while all other web-apps are shown as available.

I'll try to provide you with a small example app, which has the same behaviour. Our "real"-app will not run in your environment (too many LDAP and database prerequisites...).

Thanks,
Jochen

Created attachment 430644 [details]
Very Basic Root Web Application

The EAR contains an embedded WAR. I deleted all EJBs and the (Struts-) web-Application logic from our original Application. It only contains one html and one JSP file. The descriptos are quite similar to the originals, I only commented out the things not needed.

I checkes on an EAP 5.0.0 JBoss on Win-32 and on 64-bit Linux.
The embedded-WAR itself is shown as available, but the "/home/jb/jboss-eap-5.0/jboss-as/server/production/log" and "//localhost" nodes beneath are shon as unavaiable (see also the new screenshot.

Created attachment 430645 [details]
New Screenshot with "stripped" Root Webapp and RHQ 3.0.0 final

This is a new screenshot which shows the issue with Version 3.0.0 final of RHQ.


P.S.: See also that not all of our XQ-Datasources are recognized as available, although they are all coonfigued the same way and point to the same database (just different schemas). This problem is also there in all servers I try to monitor...(win and linux)....

Jochen,
thanks for the ear file - now things start getting interesting (see screenshot).
what JVM are you using?

And I am also suddenly seeing an XA datasource being unavailable - could you perhaps open a new BZ ?

  heiko

Created attachment 430681 [details]
Screenshot of my local view

Hi Heiko,

hm, I don't like your screenshot very much, since it doesn't show the same result as mine;-)

Here's some additional informnation. I'm using:

RHQ Server on:
- Windows XP 32-bit, with Sun JDK 1.6u17

Monitored JBoss EAP 5.0.0 Servers (and their RHQ Agents):
- OpenSUSE 11.2 64-bit, Sun JDK 1.6u18
- Windows XP 32-bit, with Sun JDK 1.6u17

We use the "production" configuration of JBossAS and changed the settings in jboss-service.xml and EAR-Deployer to CallByValue and isolated classloading (I think this is the most significant difference to your setup).

We have deployed 18 EAR files most of which have Web-Application and/or Webservice WAR files embedded.


Yes, I can open a new Bug for the Datasource problem. But will will do that somewhen next week. I have some other priorities ( ;-( ) and I am not sure if always the same datasources are show as not available or if some of them are randomly shown as unavailable.

You'll hear from me next week.

Thanks,
Jochen

Hi Jochen,
By using the production configuration instead of 'default', I am now also seeing the embedded war (and actually the whole ear) as down. Switching from production back to default makes the vhost show as up again.


Debug logging in the *production* instance shows this stack trace for the .ear file. The EAP5 instance is shown as up the whole time and other children of it also show as UP (like other embedded wars in a SAR).

2010-07-11 15:59:24,414 DEBUG [ResourceContainer.invoker.daemon-6] (org.rhq.plugins.jbossas5.EmbeddedManagedDeploymentComponent)- Could not get deployment state, cause: 
java.lang.reflect.UndeclaredThrowableException
        at $Proxy89.load(Unknown Source)
        at org.rhq.plugins.jbossas5.AbstractManagedDeploymentComponent.getManagedDeployment(AbstractManagedDeploymentComponent.java:188)
        at org.rhq.plugins.jbossas5.AbstractManagedDeploymentComponent.getAvailability(AbstractManagedDeploymentComponent.java:109)
        at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        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:637)
Caused by: java.lang.reflect.InvocationTargetException
        at sun.reflect.GeneratedMethodAccessor78.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.rhq.plugins.jbossas5.connection.JaasAuthenticationInvocationHandler.invoke(JaasAuthenticationInvocationHandler.java:57)
        ... 12 more
Caused by: java.lang.RuntimeException: java.lang.InterruptedException
        at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:823)
        at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:167)
        at org.jboss.remoting.Client.invoke(Client.java:1917)
        at org.jboss.remoting.Client.invoke(Client.java:768)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.load(AOPProxy$1.java)
        ... 16 more
Caused by: java.lang.InterruptedException
        at EDU.oswego.cs.dl.util.concurrent.Semaphore.attempt(Semaphore.java:120)
        at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.getConnection(MicroSocketClientInvoker.java:1124)
        at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:816)
        at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:167)
        at org.jboss.remoting.Client.invoke(Client.java:1917)
        at org.jboss.remoting.Client.invoke(Client.java:768)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.load(AOPProxy$1.java)
        at sun.reflect.GeneratedMethodAccessor78.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.rhq.plugins.jbossas5.connection.JaasAuthenticationInvocationHandler.invoke(JaasAuthenticationInvocationHandler.java:57)
        at $Proxy89.load(Unknown Source)
        at org.rhq.plugins.jbossas5.AbstractManagedDeploymentComponent.getManagedDeployment(AbstractManagedDeploymentComponent.java:188)
        at org.rhq.plugins.jbossas5.AbstractManagedDeploymentComponent.getAvailability(AbstractManagedDeploymentComponent.java:109)
        at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)

This is an issue in the underlying EAP instances
See https://jira.jboss.org/browse/JBPAPP-4651

----- Forwarded Message -----
From: "Fernando Nasser" <fnasser>
To: "Charles Crouch" <ccrouch>, "Mike Millson" <mmillson>, "Fernando Nasser" <fnasser>
Sent: Friday, July 16, 2010 1:06:39 PM GMT -06:00 US/Canada Central
Subject: Re: patch for EAP5.1

Charles Crouch wrote:
> Hi Fernando
> How do we go about getting a patch applied for EAP5.1?
> https://jira.jboss.org/browse/JBPAPP-4651
>   

Mike can apply the patch the Remy provided to the JBPAPP_5_1 branch.

Regards,
Fernando

Moving to ON_QA this just needs to be tested with an EAP5.1 instance that has JBPAPP-4651 fixed

Currently no EAP 5.x builds exist with this fix.  Will revisit closer to GA.

Installed JON 2.4 GA on Postgres 8.4 and start EAP5.1 (production configuration)

The "Embedded Web Application Context (Service)" is shown with availability up.

If I deploy 'portal-1.2.0.ear' the attached in comment-5 then it shows availability down. There isn't any exception/error message in server log.

Created attachment 437563 [details]
screenshot

https://jira.jboss.org/browse/JBPAPP-4651 should be fixed in EAP5.1.1 so this 
issue should be resolved when retesting against that

Created attachment 526112 [details]
verification-screenshot

Result of verification

Verified with EAP 5.1.2 ER1 + JON build 11140:81e26be20d, see screenshot.

Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.