Petals ESB Container

Lack of robustness if we play with JMX

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Trivial Trivial
  • Resolution: Fixed
  • Affects Version/s: 3.1.1
  • Fix Version/s: 3.1.2, 4.0.0
  • Component/s: Installation/Deployment
  • Security Level: Public
  • Description:
    Hide

    The container remains stuck after an unusual usage.

    1. Run the JConsole and onnect to brand new Petals through JMX (start Petals first).
    2. Load a new installer for a component (e.g. the sample client). Petals is fine with this.
    3. Invoke the same JMX operation with the same parameter (basially, clcik the button from the JConsole a second time). Peals displays an exception.
    4. Try to invoke another JMX operation (e.g. startComponent). Nothing happens in the Petals console.
    5. Try to shutdown Petals from the command line, by invoking the shutdown script. Nothing happens in the Petals console.
    6. Try to copy a component in the install directory. Five minutes later, it is still here.

    The container should handle this without remaining stuck.
    It should still react, even if the user makes a mistake (in purpose or not is not the deal here).

    Show
    The container remains stuck after an unusual usage.
    1. Run the JConsole and onnect to brand new Petals through JMX (start Petals first).
    2. Load a new installer for a component (e.g. the sample client). Petals is fine with this.
    3. Invoke the same JMX operation with the same parameter (basially, clcik the button from the JConsole a second time). Peals displays an exception.
    4. Try to invoke another JMX operation (e.g. startComponent). Nothing happens in the Petals console.
    5. Try to shutdown Petals from the command line, by invoking the shutdown script. Nothing happens in the Petals console.
    6. Try to copy a component in the install directory. Five minutes later, it is still here.
    The container should handle this without remaining stuck. It should still react, even if the user makes a mistake (in purpose or not is not the deal here).
  • Environment:
    Windows XP

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Vincent Zurczak added a comment - Tue, 9 Nov 2010 - 13:40:31 +0100

I encountered a similar problem today.
I deployed components and SA with the web console.
Then, I try to install a SA by hand, using the install directory. The SA was not taken and I removed it 2 minutes later.

Then, I tried to deploy other components and SA with ANT.
The ANT script remained stuck on the first task (deploy-component).

Eventually, I wondered whether the JMX connection was somehow locked.
I tried to refresh data from the console, and it worked. Or at least, I saw no timeout in the Tomcat log and my artifacts were displayed correctly, even after a "refresh domain" click.

I then stopped the console.
And few seconds later, Petals displayed messages about my handly-deployed SA and the ANT script was executed right after.
BUILD SUCCESSFUL.

I think there is a race condition with JMX. Or maybe it is a problem with my OS.
Next time I encounter it, I will create a dump.

Show
Vincent Zurczak added a comment - Tue, 9 Nov 2010 - 13:40:31 +0100 I encountered a similar problem today. I deployed components and SA with the web console. Then, I try to install a SA by hand, using the install directory. The SA was not taken and I removed it 2 minutes later. Then, I tried to deploy other components and SA with ANT. The ANT script remained stuck on the first task (deploy-component). Eventually, I wondered whether the JMX connection was somehow locked. I tried to refresh data from the console, and it worked. Or at least, I saw no timeout in the Tomcat log and my artifacts were displayed correctly, even after a "refresh domain" click. I then stopped the console. And few seconds later, Petals displayed messages about my handly-deployed SA and the ANT script was executed right after. BUILD SUCCESSFUL. I think there is a race condition with JMX. Or maybe it is a problem with my OS. Next time I encounter it, I will create a dump.
Hide
Permalink
Christophe DENEUX added a comment - Wed, 27 Apr 2011 - 09:08:16 +0200

I have check your problems with the current maintenance version 3.1.2-SNAPSHOT, and I'm not able to reproduce them.
Can you check if you always have them ?

Show
Christophe DENEUX added a comment - Wed, 27 Apr 2011 - 09:08:16 +0200 I have check your problems with the current maintenance version 3.1.2-SNAPSHOT, and I'm not able to reproduce them. Can you check if you always have them ?
Hide
Permalink
Vincent Zurczak added a comment - Fri, 29 Apr 2011 - 15:44:35 +0200

I have reproduced this bug on Windows 7 x64 (JDK 6) and Petals 3.1.2-SNAPSHOT.
But it appears the supposed cause was not the good one. So here are the detailed steps to reproduce the problem.

  1. Start Petals in command line by running bin/startup.bat.
  2. Start the JConsole and connect it to Petals.
  3. Go in the MBeans tab and look for the JMX operation loadNewInstaller (Petals > Service > Installation > Operations).
  4. Invoke this operation for a component (the parameter is the full file path to the component archive). I tried with the Talend SE this time.
  5. You should have a success message. Invoke the same operation again, with the same parameter. You should have an error dialog.
  6. Invoke another MBean (org.ow2.petals > installer > petals-se-yourComponent > Operations > install). No resulting dialog.
  7. Take another component archive, copy and paste it in the Petals install directory. It should remain there.
  8. Take a look at the console (command line). You should see the previous exception, but nothing else.
  9. Give the command line the focus and type in Enter. All the previous actions will be executed (or at least, displayed).


It's just like if the component loggers could not write to stdout.
You have to give the focus back to the console.

Show
Vincent Zurczak added a comment - Fri, 29 Apr 2011 - 15:44:35 +0200 I have reproduced this bug on Windows 7 x64 (JDK 6) and Petals 3.1.2-SNAPSHOT. But it appears the supposed cause was not the good one. So here are the detailed steps to reproduce the problem.
  1. Start Petals in command line by running bin/startup.bat.
  2. Start the JConsole and connect it to Petals.
  3. Go in the MBeans tab and look for the JMX operation loadNewInstaller (Petals > Service > Installation > Operations).
  4. Invoke this operation for a component (the parameter is the full file path to the component archive). I tried with the Talend SE this time.
  5. You should have a success message. Invoke the same operation again, with the same parameter. You should have an error dialog.
  6. Invoke another MBean (org.ow2.petals > installer > petals-se-yourComponent > Operations > install). No resulting dialog.
  7. Take another component archive, copy and paste it in the Petals install directory. It should remain there.
  8. Take a look at the console (command line). You should see the previous exception, but nothing else.
  9. Give the command line the focus and type in Enter. All the previous actions will be executed (or at least, displayed).

It's just like if the component loggers could not write to stdout. You have to give the focus back to the console.
Hide
Permalink
Christophe DENEUX added a comment - Fri, 29 Apr 2011 - 16:49:19 +0200

Under Windows, if you select the JMX URL in the DOS console before to paste it in the JConsole, you freeze the Petals process until you unfreeze it by typing 'Enter'.
So, just free you selection before to paste it.

Petals ESB container documentation has been updated: http://doc.petalslink.com/display/petalsesb31/Known+Problems

Show
Christophe DENEUX added a comment - Fri, 29 Apr 2011 - 16:49:19 +0200 Under Windows, if you select the JMX URL in the DOS console before to paste it in the JConsole, you freeze the Petals process until you unfreeze it by typing 'Enter'. So, just free you selection before to paste it. Petals ESB container documentation has been updated: http://doc.petalslink.com/display/petalsesb31/Known+Problems
Hide
Permalink
Christophe DENEUX added a comment - Fri, 29 Apr 2011 - 16:55:40 +0200

Documentation merge in trunk: http://doc.petalslink.com/display/petalsesbsnapshot/Known+Problems

Show
Christophe DENEUX added a comment - Fri, 29 Apr 2011 - 16:55:40 +0200 Documentation merge in trunk: http://doc.petalslink.com/display/petalsesbsnapshot/Known+Problems

People

Dates

  • Created:
    Mon, 8 Nov 2010 - 16:40:25 +0100
    Updated:
    Fri, 29 Apr 2011 - 16:55:40 +0200
    Resolved:
    Fri, 29 Apr 2011 - 16:49:50 +0200
Atlassian JIRA (v4.1.2#531) | Report a problem | Request a feature | Contact administrators
Powered by a free Atlassian JIRA open source license for Petals ESB. Try JIRA - bug tracking software for your team.