4 a.m.
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
Fix For: 6.1.0
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
4:10 a.m.
New subject: [JBoss JIRA] Updated: (TEIID-533) HostController Process is redundent and should be removed
[
https://jira.jboss.org/jira/browse/TEIID-533?page=com.atlassian.jira.plug...
]
Van Halbert updated TEIID-533:
------------------------------
Assignee: Van Halbert
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: Van Halbert
Fix For: 6.1.0
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
4:58 a.m.
New subject: [JBoss JIRA] Commented: (TEIID-533) HostController Process is redundent and should be removed
[
https://jira.jboss.org/jira/browse/TEIID-533?page=com.atlassian.jira.plug...
]
Van Halbert commented on TEIID-533:
-----------------------------------
Getting rid of the hostcontroller will reduce resources and the complexity of the server.
To do this, and in the least amount of time, the following is how the process of
starting/bouncing the server will be done:
- the startserver script will be the script used to start, bounce, and start a process
- the hostcontroller class will become the boot class, starting one or more processes
and then exiting
starting the server:
- startserver script will work as is does now, if called a second time and there are
services running, they will be restarted (as it does now)
bouncing server:
- the ProcessController (used to be called VMController), will call the startserver
script, passing no arguments. The startserver script
will restart the processes, just as if the startserver script was called a second time
from the command line.
start/restart a process:
- the ProcessController will call the startserver script, passing in the name of the
process to start/restart.
If there are multiple processes defined for the host, then there will be a call for each
process.
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: Van Halbert
Fix For: 6.1.0
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
9:44 p.m.
New subject: [JBoss JIRA] Work started: (TEIID-533) HostController Process is redundent and should be removed
[
https://jira.jboss.org/jira/browse/TEIID-533?page=com.atlassian.jira.plug...
]
Work on TEIID-533 started by Ramesh Reddy.
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.0
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
9:44 p.m.
New subject: [JBoss JIRA] Assigned: (TEIID-533) HostController Process is redundent and should be removed
[
https://jira.jboss.org/jira/browse/TEIID-533?page=com.atlassian.jira.plug...
]
Ramesh Reddy reassigned TEIID-533:
----------------------------------
Assignee: Ramesh Reddy (was: Van Halbert)
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.0
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
6:03 p.m.
New subject: [JBoss JIRA] Updated: (TEIID-533) HostController Process is redundent and should be removed
[
https://jira.jboss.org/jira/browse/TEIID-533?page=com.atlassian.jira.plug...
]
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
10:26 p.m.
New subject: [JBoss JIRA] Updated: (TEIID-533) HostController Process is redundent and should be removed
[
https://jira.jboss.org/jira/browse/TEIID-533?page=com.atlassian.jira.plug...
]
Ramesh Reddy updated TEIID-533:
-------------------------------
Fix Version/s: 6.2.0
(was: 6.1.1)
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.2.0
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
8:01 p.m.
New subject: [JBoss JIRA] Updated: (TEIID-533) HostController Process is redundent and should be removed
[
https://jira.jboss.org/jira/browse/TEIID-533?page=com.atlassian.jira.plug...
]
Ramesh Reddy updated TEIID-533:
-------------------------------
Fix Version/s: 6.3.0
(was: 6.2.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.3.0
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
8:01 p.m.
New subject: [JBoss JIRA] Work stopped: (TEIID-533) HostController Process is redundent and should be removed
[
https://jira.jboss.org/jira/browse/TEIID-533?page=com.atlassian.jira.plug...
]
Work on TEIID-533 stopped by Ramesh Reddy.
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.3.0
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
10:58 p.m.
New subject: [JBoss JIRA] Resolved: (TEIID-533) HostController Process is redundent and should be removed
[
https://jira.jboss.org/jira/browse/TEIID-533?page=com.atlassian.jira.plug...
]
Steven Hawkins resolved TEIID-533.
----------------------------------
Resolution: Deferred
Deferring since these are targeted to the old server implementation.
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.3.0
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
9:04 p.m.
New subject: [JBoss JIRA] Closed: (TEIID-533) HostController Process is redundent and should be removed
[
https://jira.jboss.org/jira/browse/TEIID-533?page=com.atlassian.jira.plug...
]
Ramesh Reddy closed TEIID-533.
------------------------------
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.3.0
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
5583
days inactive
5734
days old
10 comments
3 participants
participants (3)
-
Ramesh Reddy (JIRA) -
Steven Hawkins (JIRA)
-
Van Halbert (JIRA)