[JBoss JIRA] Created: (TEIID-685) Define Metadata aware Connector API
by Ramesh Reddy (JIRA)
Define Metadata aware Connector API
-----------------------------------
Key: TEIID-685
URL: https://jira.jboss.org/jira/browse/TEIID-685
Project: Teiid
Issue Type: Sub-task
Components: Connector API
Reporter: Ramesh Reddy
Assignee: Steven Hawkins
Priority: Critical
Fix For: 6.2.0
Connector API needs to be extended, such that a connector can selectively implement an interface with which it can expose the metadata of the connector. This is similar to the concept of JDBC drivers exposing the metadata of the sources they are connected to.
At a minimum, this API must expose all the available
- Tables, with corresponding elements
- Procedures with corresponding parameters
in the data source. There should also be a way to define user defined properties on all the objects, that can used by tools as they fit.
Please comment, if there are any specific features you would like this to extend, as PK, FK, Unique keys, indexes etc. Overtime, it is expectation that this will be grown to full blown metadata store API as the teiid-metadata project.
--
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
15 years, 3 months
[JBoss JIRA] Created: (TEIID-580) Add ability to monitor Connector Connection Pool
by Van Halbert (JIRA)
Add ability to monitor Connector Connection Pool
-------------------------------------------------
Key: TEIID-580
URL: https://jira.jboss.org/jira/browse/TEIID-580
Project: Teiid
Issue Type: Feature Request
Components: AdminApi, Query Engine, Server
Affects Versions: 6.1.0
Reporter: Van Halbert
Assignee: Van Halbert
Here are the discussed changes to enable connection pool monitoring:
- Create a new stat's class to expose the information: ConnectionPoolStats
- Enable the ConnectionPool to monitor the following pieces of information:
a. Total Connections - Total Number of Connections for the Connection Pool
b Available Connections - Number of available connections in the connection pool.
c Active Connections - Number of Connections currently supporting clients.
d Connections Created - Number of Connections created since the Connection Pool was created.
e Connections Destroyed - Number of Connections destroyed since the Connection Pool was created.
In the config.xml for the base Connector component type
a. Rename the ConnectorMaxThreads to MaxConnections so that it
relates better to the user
- Expose the ConnectionPoolStats out the adminAPI
--
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
15 years, 3 months
[JBoss JIRA] Created: (TEIID-533) HostController Process is redundent and should be removed
by Ramesh Reddy (JIRA)
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
15 years, 3 months