jaeburger.blogg.se

1. Java jar file launch and exits install#
2. Java jar file launch and exits update#
3. Java jar file launch and exits manual#
4. Java jar file launch and exits zip#
5. Java jar file launch and exits download#

Java jar file launch and exits update#

The agent update servlet will disallow any more than this number of concurrent downloads occurring at any one time within a single RHQ Server. This setting does not affect the comm-layer messaging, but serves a similar purpose. In the future, you may be able to set this in the RHQ Server resource's Config tab, under the Concurrency Limit config group (see RHQ-1111).

Java jar file launch and exits install#

This means if you want to manually install the agent, you can "jar xvf rhq-enterprise-agent-X.jar rhq-enterprise-agent-X.zip" and then "unzip rhq-enterprise-agent-X.zip" - but I'll assume people won't want to do this since "java -jar rhq-enterprise-agent-X.jar" will be easier.

Java jar file launch and exits zip#

zip agent distro and package it directly in the agent update binary. The solution our first implementation will use is to take our existing.

We may need to still package our agent update binaries using "zip" (even if our extension to the file is still ".jar") to maintain cross-platform capabilities but warn people that if they use "jar" to unpackage it, they will need to "chmod -R +x *.sh" to get our scripts to have the proper execute permissions. This is important because it means we will lose +x permissions on our *.sh UNIX scripts. In other words, using "jar" either in the create or unpackage stage will cause you to lose the permission bits of the files. However, you will lose UNIX execute-bits (in fact, all permission bits) if you build the package with "jar" (even if you unpackage it with "unzip") and you will lose them if you unpackage them with "jar" (even if you created it with "zip"). You can create a binary using "jar cvf" and unpackage it with "unzip" and you can create a binary using "zip" and unpackage it with "jar xvf" (regardless of the file extension. Jar files and ZIP files are binary compatible. A rebuild of an agent in a development environment should somehow be able to stay at a particular version so it can be started and not be denied access because the new agent is not of the version the server thinks is the latest version. NOTE: we need a way to not make this too difficult for agent developers. To prevent that, we could add an out-of-band version string to be placed in the agent's outgoing commands' configuration and if the server gets a bad version, it will disallow the messages. Unfortunately, this will not prevent really old agents (those prior to this agent-update feature) from trying to talk to the server. The easiest way we can do this without requiring additional out-of-band data to flow over the comm connection is to have the agent kill itself if it detects it is one version but the server is another version.

In fact, we can somehow explicitly disallow a mis-versioned agent from talking to a server. In the future, we may decide to allow violations of this Prime Directive - we might be able to support different "minor" versions of agents however, in our first implementation, we will not support it. All servers in a cloud must support the same version of agent. We will not support servers installed in a cloud that are matched to different agent versions. We will not support updating agents such that there ends up being different agent versions running in the RHQ environment. Keeping the above fact in mind, this means:

Be able to turn it off at the server side to force the disablement of agent auto-update even if the agent wants to.Īll agents talking to a server cloud will be of the same version and an individual server will support talking to only one specific version of an agent. I'll need to be able to turn this off on the agent side because the embedded agent will have this feature turned off by default, in addition, this needs to be turned off to be able to run our unit tests.

Java jar file launch and exits download#

The agent should be able to automatically download the update, apply the update and restart itself.īe able to turn off the auto-update feature, from both the server and agent side.

Java jar file launch and exits manual#

Manual intervention must not be required to apply an update. We must make sure the agent can overwrite jar files that are currently open by the agent JVM's classloaders (on Windows XP, and perhaps other platforms, you cannot delete a file that is currently opened altering jar file content could screw up a classloader that is currently reading class definitions from it)Īgents not already running must be able to know immediately at startup they they need to update (and do so then) This seems obvious but is being explicitly mentioned for two reasons: The update solution must be cross-platform - Linux, Windows, UNIX and hopefully even MacOS.Īgents must be able to update themselves while they are running. The following are requirements that must be supported by our agent auto-update feature: