Bug 957689 - Unable to complete tasks when server is shutdown

David A. Webster DAWEBSTER at UP.COM
Wed Jun 26 13:00:23 UTC 2013


Sorry, 'bout that....need to keep up better.  We don't use JEE containers 
at all here, even moving away from Servlet containers in favor of 
home-grown HTTP/AJP listener wrappers, so not my best technical area....

As a user of an extensive RHQ installation, I don't mind post install 
recycles...in fact, they are kind of expected.  Afterall, Windows and 
Eclipse and such reboot after updates all the time....

David Webster
Union Pacific Railroad
Lead Architect-Systems Engineering
Phone: (402) 544-1094 | Email: dawebster at up.com



From:   Thomas Segismont <tsegismo at redhat.com>
To:     rhq-devel at lists.fedorahosted.org
Date:   06/26/2013 07:47 AM
Subject:        Re: Bug 957689 - Unable to complete tasks when server is 
shutdown
Sent by:        rhq-devel-bounces at lists.fedorahosted.org



AS7/EAP6 are not based on JMX anymore. That's exactly why we have the 
shutdown problems. This is explained in the wiki page:

https://docs.jboss.org/author/display/RHQ/Shutdown+process+on+AS7


Le 26/06/2013 14:43, David A. Webster a écrit :
> Isn't there an MBean you guys could check?  Maybe with a useful
> operational method that could initialize this specific component?  I
> would have thought you guys would have developed some RHQ-specific
> MBeans to go along with the system to help with this sort of thing....
>
> At least use the main server MBean's status flag detect it's in a state
> needed then issue your internal recycle command.
>
> David Webster
> Union Pacific Railroad
> Lead Architect-Systems Engineering
> Phone: (402) 544-1094 | Email: dawebster at up.com
>
>
>
> From: John Mazzitelli <mazz at redhat.com>
> To: rhq-devel at lists.fedorahosted.org
> Date: 06/26/2013 07:38 AM
> Subject: Re: Bug 957689 - Unable to complete tasks when server is 
shutdown
> Sent by: rhq-devel-bounces at lists.fedorahosted.org
> ------------------------------------------------------------------------
>
>
>
> Wait. what?? The server has to be restarted after the installation for
> the server to work?
>
> I agree with Larry, we need to rethink this.
>
> We do not want the user to have to monitor the server and restart it
> after install, in fact, we shouldn't have to take down the server
> entirely and restarted at all after installation.
>
> The installer DOES "reload" the server after the install, but before the
> EAR is deployed. But IIRC reloading after the EAR is deployed causes
> errors so even that is probably not going to be an answer.
>
> I haven't been following this closely, sorry :} but if the answer is to
> ask the user to restart the server after an install just to get a
> functional server, that should be last-ditch solution and we should
> first try hard to figure out how NOT to have to do this. It actually
> would suck if we required that.
>
> This isn't in master yet is it? :)
>
> ----- Original Message -----
>  > On Wed, 2013-06-26 at 13:05 +0200, Thomas Segismont wrote:
>  > > Le 26/06/2013 12:54, Larry O'Leary a écrit :
>  > > > On Wed, 2013-06-26 at 12:22 +0200, Thomas Segismont wrote:
>  > > >> I forgot to say that the DeploymentUnitProcessor classes are 
only
>  > > >> activated at boot time. So after installing RHQ you will need to
> restart
>  > > >> the server.
>  > > >>
>  > > >> Do you think that deserves a message in the server installer?
>  > > >
>  > > > Seems that asking a user to "restart" the server as part of the
> install
>  > > > is a bad idea. It doesn't make sense from a usability
> perspective. If we
>  > > > can't implement this any other way then the question becomes,
> should the
>  > > > installer only install and not start anything? Therefore the
> action of
>  > > > starting the server becomes part of the post-install process.
>  > > >
>  > > >  From my perspective, I would prefer a better/different solution 
that
>  > > > allowed the server to start as part of the install process
> without the
>  > > > user having to do it separately.
>  > > >
>  > >
>  > > We need the server to be up during the installation process. The
>  > > installer communicates with the management interface to install our
>  > > queues, EAR, ... etc.
>  >
>  > Right. This part makes sense.
>  >
>  > > We could look at the server log and catch the "server started" 
message
>  > > then restart the server.
>  > >
>  > > What do you think?
>  >
>  > If there isn't an alternative way to load the classes post-boot then 
a
>  > "restart in the background" approach seems ideal. However, monitoring
>  > the server log probably isn't very stable. Considering that logging
>  > configuration may change or log message 
refactoring/internationalization
>  > may result in a break in the future.
>  >
>  > Perhaps more input/discussion is needed to come up with a better
>  > approach.
>  > --
>  > Larry O'Leary
>  > https://plus.google.com/u/0/112645929986009801513
>  >
>  > _______________________________________________
>  > rhq-devel mailing list
>  > rhq-devel at lists.fedorahosted.org
>  > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>  >
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>
>
> **
>
> This email and any attachments may contain information that is
> confidential and/or privileged for the sole use of the intended
> recipient. Any use, review, disclosure, copying, distribution or
> reliance by others, and any forwarding of this email or its contents,
> without the express permission of the sender is strictly prohibited by
> law. If you are not the intended recipient, please contact the sender
> immediately, delete the e-mail and destroy all copies.
> **
>
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>

_______________________________________________
rhq-devel mailing list
rhq-devel at lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel



**

This email and any attachments may contain information that is confidential and/or privileged for the sole use of the intended recipient.  Any use, review, disclosure, copying, distribution or reliance by others, and any forwarding of this email or its contents, without the express permission of the sender is strictly prohibited by law.  If you are not the intended recipient, please contact the sender immediately, delete the e-mail and destroy all copies.
**
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/rhq-devel/attachments/20130626/5e8768dd/attachment.html>


More information about the rhq-devel mailing list