[Tomcat Wiki] Trivial Update of "TomcatGridDiscussion" by theimpaler

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification.

The "TomcatGridDiscussion" page has been changed by theimpaler:
https://wiki.apache.org/tomcat/TomcatGridDiscussion?action=diff&rev1=14&rev2=15

  
  The Grid Agents are Java processes installed and running on each machine that listen (on a configured port) for commands from a Grid Manager application (Web or  CLI) and act upon them by interacting with the local Tomcat instances. No  encryption is envisioned on the network channels, since all these machines are  considered to be installed on a secured network segment (at least in prod).  [Maybe we should reconsider this]
  
- ''markt: I think this needs to be reconsidered.''
+ ''__markt__: I think this needs to be reconsidered.''
  
- ''vlad: Sure. My take was to use unencrypted connections, since it's fast to implement for me and I don't know well how to implement a secured connection. Maybe we could even offer both options. Anyway, why do you consider we need an secured connection? In my experience, I've never needed them in dev/state/QA/test, and in prod the environment are isolated. Well... I guess there are other scenarios I haven't been exposed to.''
+ ''__vlad__: Sure. My take was to use unencrypted connections, since it's fast to implement for me and I don't know well how to implement a secured connection :/ . Maybe we could even offer both options. Anyway, why do you consider we need an secured connection? In my experience, I've never needed them in dev/state/QA/test, and in prod the environment are isolated. Well... I guess there are other scenarios I haven't been exposed to.''
  
  All Tomcat instances (including the Web Grid Managers), as well as the Grid  Agents, are installed manually. The primary grid manager and all the agents are started manually too.
  
@@ -35, +35 @@

  
  Collectively, Tomcat instances and Grid Agents are "services" since both can be managed.
  
- ''markt: Managing the agents strikes me as making this significantly more complex. Operating systems have tools to ensure particular services are running and are restarted if they fail. What is the benefit of pulling this into this tool?''
+ ''__markt__: Managing the agents strikes me as making this significantly more complex. Operating systems have tools to ensure particular services are running and are restarted if they fail. What is the benefit of pulling this into this tool?''
  
- ''vlad: I agree that agents can run as daemons and be up all the time. However, I've seen many "robust" programs to have memory leaks and that for one reason or another stop working normally after some time. Maybe after a couple of days, or weeks, or months. Maybe it would be useful to restart them just before a critical operation such as a deployment. I agree that managing agent is more expensive since it requires the development and maintenance of multiple OS-dependent implementations.''
+ ''__vlad__: I agree that agents can run as daemons and be up all the time. However, I've seen many "robust" programs to have memory leaks and that for one reason or another stop working normally after some time. Maybe after a couple of days, or weeks, or months. Maybe it would be useful to restart them just before a critical operation such as a deployment. I agree that managing agent is more expensive since it requires the development and maintenance of multiple OS-dependent implementations.''
  
  Later versions of the Grid include "collection" management. This allows to  group subsets of services (Tomcat instances and Grid Agents), so they can be  operated as whole. Each collection can include plain services, or other  collections (recursively).
  
  Considering all the above, the following phases could be considered as a base line for the road map of the Tomcat Grid.
  
- ''markt: I'd like to see a little more high level architecture to steer development. For example, is there a common core of management functionality that we then wrap with a web-based GUI and a CLI? That would allow others to write other wrappers to plug this into other tools.''
+ ''__markt__: I'd like to see a little more high level architecture to steer development. For example, is there a common core of management functionality that we then wrap with a web-based GUI and a CLI? That would allow others to write other wrappers to plug this into other tools.''
  
- ''vlad: I would like to provide as much detail as you need, but I'm afraid I still I don't quite understand exactly what you do you refer as the architecture. Anyway, below is a general overview of the software modules and their responsibilities.''
+ ''__vlad__: I would like to provide as much detail as you need, but I'm afraid I still I don't quite understand exactly what you do you refer as the architecture. Anyway, below is a general overview of the software modules and their responsibilities.''
  
   {{attachment:TomcatGridSoftwareModules.png}}
  
@@ -113, +113 @@

  
  In particular, no Tomcat instances or Grid Agents automatic provisioning is  considered, no configuration GUI (only pre-configured XML config files), no WAR  deployments, no command-line interface, no complex grid operations, no  secondary managers, and no collections.
  
- ''markt: This raises another architectural question. Wouldn't this be more scalable if agents were configured with the location of the primary manager and registered themselves? The manager could persist that registration so an agent would have to be explicitly removed if it was taken off-line permanently.''
+ ''__markt__: This raises another architectural question. Wouldn't this be more scalable if agents were configured with the location of the primary manager and registered themselves? The manager could persist that registration so an agent would have to be explicitly removed if it was taken off-line permanently.''
+ 
+ ''__vlad__: Definitively. A basic agent install, and registration could "summon" all the necessary software from the primary manager: i.e. Tomcat executables, grid configuration, etc. I thought about something like this as an advanced feature (phase 12), but we can rearrange the priorities if needed.''
  
  Included features are:
  
@@ -126, +128 @@

    * '''trigger-start''': sends a start request to the Tomcat instance using the corresponding Grid Agent
    * '''trigger-stop''': sends a stop request to the Tomcat instance using the corresponding Grid Agent
    * '''trigger-kill''': sends a kill request to the Tomcat instance using the corresponding Grid Agent
-    * ''markt: A small thing. I think I'd prefer start/stop/kill/''
+    * ''__markt__: A small thing. I think I'd prefer start/stop/kill/''
+    * ''__vlad__: I added these commands on phase 7 and, as I see them, they behave are a little bit different from the trigger ones, specially when we refer to the CLI manager. The '''trigger-start''', issues the signal to the Grid Agent and ends. The '''start''' keeps on working (and updating the user) until the Tomcat instance is actually up (or fails to start up). On the Web interface the trigger start could show up as a simple icon (omitting its name). On the CLI I see the start command as far more useful than the trigger-start.''
  
   1. A simple configuration file lists all the machines and their instances so the Grid knows where each instance resides. [This configuration file is probably in XML format]
  
@@ -137, +140 @@

    * OS calls for any OS related need.
  
   1. It's assumed that a port will be accessible from each Grid Manager to each machine where the Grid Agents are serving. The firewall, if present must allow active server-type sockets on that port.
-   * ''markt: Another architectural question. Which end opens the connection, does it stay open and which protocol is used? For example, agents connect to Manager via WebSocket.''
+   * ''__markt__: Another architectural question. Which end opens the connection, does it stay open and which protocol is used? For example, agents connect to Manager via WebSocket.''
+   * ''__vlad__: I always considered the Grid Agent would would open a server NIO socket, to avoid using ephemereal ports. The Grid Agent is always listening, and the Managers connect when needed.''
  
   1. Multiple Grids (and Grid Agents) can be running on the same set (or subset) of machines. If that's the case, Tomcat instances, and Grid Agents run on different ports for each grid. When multiple grids use the same machines they don't interfere with each other and can be operated simultaneously.
  

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org