[teiid-issues] [JBoss JIRA] Updated: (TEIID-533) HostController Process is redundent and should be removed

[Steven Hawkins (JIRA)]

     [ https://jira.jboss.org/jira/browse/TEIID-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-533:
---------------------------------

    Fix Version/s: 6.1.1
                       (was: 6.1.0)


> HostController Process is redundent and should be removed
> ---------------------------------------------------------
>
>                 Key: TEIID-533
>                 URL: https://jira.jboss.org/jira/browse/TEIID-533
>             Project: Teiid
>          Issue Type: Feature Request
>          Components: Server
>    Affects Versions: 6.0.0
>            Reporter: Ramesh Reddy
>            Assignee: Ramesh Reddy
>             Fix For: 6.1.1
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Host Controller process does not really have significant importance in a server environment and is redundant. The main responsibility of the Host Controller is spawn the process that is the Server. The second responsibility is to act as surviving process during the "bounce", and kill and restart the Server processes. To accomplish this it takes up valuable resources like memory and cluster  replication etc.  We can accomplish these both task in alternative means
> Option: 1
> Instead of keeping Host Controller alive all the time, it can be retired once the Server process(es) are spawned. When Console or Admin API, request a bounce of server or cluster, it can be communicated to all the participating Servers over the JGroups channel then Server process that received bounce request, can spawn a "nanny" process ( this can be same Host controller which started first time) and kill itself. The the invoked nanny process will finish the starting the process back up.
> Option: 2
> Scripts can written to start the server process first time easily, when the bounce request comes in the process can die with certain unique exit code, scripts can be written such that when they see the bounce specific exit code, they restart the process again.
> These options have a good side effect, that is when the Server is bounced in the new scenario, any patches submitted can be applied to the new server before they are started.
> Option2 is simple, however the only hurdle with Option 2 is when single host has two+ processes, and got bounced, then there is possible way to way to communicate back with script, as to which Server process it is responsible to start back up. It can start all of them, but starting a single seems difficult.
> Please offer suggestions and your preference. If we can not solve the issue with option 2, option 1 will be implemented.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira