Re: [teiid-designer-dev] Re: [teiid-dev] 6.1 Release
by John Doyle
I'm not sure there's a response to my concern in your response.
I'm aware that there's an aggressive schedule, but I question that value of releasing Teiid on it's projected release date, if the Designer is not ready to release, or vice versa. I have changes coming in 6.1 to connectors that are depending upon importer changes. I can mock up tests for the connector changes, but I won't really be able to validate a feature until I have two stable projects in my hands that are pretty much locked down.
We can call them independent all we want, users will disagree. There's already traffic on the lists to demonstrate that.
What's wrong with leaving it on the shelf until both are ready, and then making it official?
~jd
----- "Steven Hawkins" <shawkins(a)redhat.com> wrote:
> >From here out the versions of Teiid and Teiid Designer are
> independent. The 6.0 release of Designer currently corresponds to
> Teiid 6.0 + patches. We will release a Teiid 6.0.1 if necessary to
> support the Designer, but the current thought is just to wrap up Teiid
> 6.1.0 in the near term. Teiid Designer has an aggressive schedule for
> their 6.1 release, but there's no guarantee that it will be extremely
> close to Teiid 6.1.0.
>
> ----- Original Message -----
> From: "John Doyle" <jdoyle(a)redhat.com>
> To: teiid-dev(a)lists.jboss.org, teiid-designer-dev(a)lists.jboss.org
> Sent: Wednesday, April 22, 2009 4:26:15 PM GMT -06:00 US/Canada
> Central
> Subject: [teiid-dev] 6.1 Release
>
> I'm having issues testing the 6.0 release and I want to ensure that we
> have a plan for 6.1 to address the issues I'm having.
>
> The challenge is this. Teiid 6.0 was released on the 23rd of March.
> The 6.0 Designer release is just now wrapping up - a month later.
> It's difficult to accurately determine the quality of connectors
> delivered in 6.0 until the Designer is finished and I can create the
> models that the connectors consume. This is particularly accute when
> there is a strong connector dependency on importer-produced metadata
> (such as XML-Relational and Salesforce.com connectors).
>
> Are we planning on releasing Teiid Designer and Teiid together (or
> extremely close) for 6.1?
>
> I've copied both dev lists to ensure that both projects are included.
>
> ~jd
>
> --
> John Doyle
> Senior Software Engineer
> JBoss, a division of Red Hat
> Office: 978.392.3916
> Email: jdoyle(a)redhat.com
>
> _______________________________________________
> teiid-dev mailing list
> teiid-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev
>
> _______________________________________________
> teiid-designer-dev mailing list
> teiid-designer-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
16 years, 11 months
Re: [teiid-dev] 6.1 Release
by Steven Hawkins
>From here out the versions of Teiid and Teiid Designer are independent. The 6.0 release of Designer currently corresponds to Teiid 6.0 + patches. We will release a Teiid 6.0.1 if necessary to support the Designer, but the current thought is just to wrap up Teiid 6.1.0 in the near term. Teiid Designer has an aggressive schedule for their 6.1 release, but there's no guarantee that it will be extremely close to Teiid 6.1.0.
----- Original Message -----
From: "John Doyle" <jdoyle(a)redhat.com>
To: teiid-dev(a)lists.jboss.org, teiid-designer-dev(a)lists.jboss.org
Sent: Wednesday, April 22, 2009 4:26:15 PM GMT -06:00 US/Canada Central
Subject: [teiid-dev] 6.1 Release
I'm having issues testing the 6.0 release and I want to ensure that we have a plan for 6.1 to address the issues I'm having.
The challenge is this. Teiid 6.0 was released on the 23rd of March. The 6.0 Designer release is just now wrapping up - a month later. It's difficult to accurately determine the quality of connectors delivered in 6.0 until the Designer is finished and I can create the models that the connectors consume. This is particularly accute when there is a strong connector dependency on importer-produced metadata (such as XML-Relational and Salesforce.com connectors).
Are we planning on releasing Teiid Designer and Teiid together (or extremely close) for 6.1?
I've copied both dev lists to ensure that both projects are included.
~jd
--
John Doyle
Senior Software Engineer
JBoss, a division of Red Hat
Office: 978.392.3916
Email: jdoyle(a)redhat.com
_______________________________________________
teiid-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
16 years, 11 months
6.1 Release
by John Doyle
I'm having issues testing the 6.0 release and I want to ensure that we have a plan for 6.1 to address the issues I'm having.
The challenge is this. Teiid 6.0 was released on the 23rd of March. The 6.0 Designer release is just now wrapping up - a month later. It's difficult to accurately determine the quality of connectors delivered in 6.0 until the Designer is finished and I can create the models that the connectors consume. This is particularly accute when there is a strong connector dependency on importer-produced metadata (such as XML-Relational and Salesforce.com connectors).
Are we planning on releasing Teiid Designer and Teiid together (or extremely close) for 6.1?
I've copied both dev lists to ensure that both projects are included.
~jd
--
John Doyle
Senior Software Engineer
JBoss, a division of Red Hat
Office: 978.392.3916
Email: jdoyle(a)redhat.com
16 years, 11 months
Supporting Unicast based Cluster for Teiid (TEIID-233)
by Ramesh Reddy
Hi,
Here is some communication between loleary and me on the topic of supporting unicast for Teiid server clusters by default, please read it and let me know you opinion. If you do not want read the whole thing it can be summarized as
The user would have those three deployment options. Our default would be Unicast over TCP using an embedded router that supports fail-over. Option two would be Multicast over UDP (what we do now by default) and option three would be Unicast over UDP or TCP using GossipRouter (like we offer now).
Thanks
Ramesh..
(10:16:45 AM) ramesh1: I am looking into unicast; and I remember you saying this needs to be default
(10:17:24 AM) ramesh1: also, there are two types of unicast JGroups provides UDP based and TCP based
(10:17:42 AM) ramesh1: both requires some kind of gossip router
(10:17:53 AM) loleary: I figured as much.
(10:18:05 AM) ramesh1: JGroups recommends UDP in LAN and TCP in WAN
(10:18:21 AM) loleary: Sounds right.
(10:18:26 AM) loleary: We should use UDP by defult.
(10:18:29 AM) ramesh1: also, when unicast the traffic for each message n(n-1)
(10:18:39 AM) ramesh1: which is understandable
(10:19:01 AM) ramesh1: so, do customers do not like to use TCP?
(10:19:29 AM) loleary: I can't say they do not like to use TCP. I think TCP would be most common but also adds overhead.
(10:19:44 AM) ramesh1: We were also thinking, how to get rid of the separate gossip router
(10:20:06 AM) loleary: Is there a way we can embed gossip router into the host controller?
(10:20:40 AM) ramesh1: if we can assume the availability of gossip router some where like on port x + range then we can embed in some process
(10:20:42 AM) loleary: I believe, with the latest release of JGroups, GossipRouter now supports fail-over (maybe load balancing but not sure).
(10:21:03 AM) ramesh1: they call it TCPGOSSIP, which is only on TCP
(10:21:33 AM) loleary: Well, when the embedded GossipRouter starts, can't it just write its listening port information to the configuration?
(10:21:44 AM) loleary: Ahh..
(10:22:17 AM) ramesh1: it could, but that may be error prone as system state
(10:22:43 AM) ramesh1: i.e. when system shuts down it needs to remove it self
(10:22:54 AM) ramesh1: may be it can shun itself I think
(10:23:26 AM) ramesh1: also, when using UDP, this notion multiple gossip routers does not exist
(10:23:36 AM) ramesh1: there has to be only one.
(10:23:56 AM) loleary: Yes. I can see that to be an issue.
(10:24:14 AM) ramesh1: so, I am torn between, what we would want to support by default
(10:24:49 AM) loleary: Well, we know multicast is an issue in most deployments.
(10:25:09 AM) loleary: We know that UDP is preferred for performance.
(10:25:22 AM) ramesh1: Yes, we want unicast by default; multicast only by more config
(10:25:46 AM) loleary: By using Unicast, we introduce GossipRouter.
(10:25:51 AM) ramesh1: and resource consumption; port availability
(10:25:59 AM) loleary: GossipRouter with UDP can only run as a single instance.
(10:26:01 AM) ramesh1: firewall issues
(10:26:28 AM) ramesh1: that is correct
(10:26:39 AM) loleary: So, although I do not like introducing a dedicated administration server in the cluster, it almost seems that we do not have a choice.
(10:27:19 AM) loleary: A single server must be determined to be the administrative (primary) server upon start-up if unicast/udp configuration is selected.
(10:28:33 AM) loleary: Now, it would be nice if the primary/administrative server could be dynamic.
(10:29:01 AM) loleary: In other words, the first server I start in the cluster becomes the primary. And, the primary server could change at any time.
(10:29:30 AM) ramesh1: so, when the second server comes up it would tunnel?
(10:29:33 AM) loleary: For that to work, each server in the cluster would have to rely on configuration information/state to determine who is the primary.
(10:30:38 AM) ramesh1: how would we transfer the administrative stuff to one to another
(10:30:49 AM) ramesh1: when primary goes down?
(10:31:20 AM) loleary: One of the remaining servers would take over and update the configuration.
(10:31:30 AM) ramesh1: I wish UDP supported multiple gossip, then this would not have been a issue
(10:31:39 AM) loleary: For this to work, we would have to lock/synch the configuration to prevent another node from doing the same.
(10:31:51 AM) loleary: Agreed.
(10:32:11 AM) ramesh1: but for that to work JGroups channel needs to be recycled with new info
(10:32:21 AM) loleary: Correct.
(10:32:48 AM) loleary: So each node of the cluster much periodically check to see who is the primary server (or do it as soon as communication fails with the old primary).
(10:33:21 AM) loleary: Once they determine that the new primary is different from their existing primary router, they dump their old channels and start/create new ones with the new primary.
(10:33:34 AM) ramesh1: that may not be possible; may cause loss of data; unless we write some elaborate code to move the data
(10:33:52 AM) loleary: True.
(10:34:26 AM) loleary: Well, if we are using UDP, do we have message delivery confirmation/ack?
(10:34:46 AM) ramesh1: you can configure that in the stack
(10:34:58 AM) ramesh1: TCP you do not
(10:35:10 AM) loleary: :)
(10:35:19 AM) loleary: Right... which is why UDP is better for performance.
(10:35:35 AM) loleary: So, by introducing delivery confirmation, we might as well be using TCP.
(10:35:50 AM) ramesh1: since our typical customer cluster sizes are small; why not use TCP?
(10:36:10 AM) ramesh1: little overhead, sure but lot more flexibility
(10:36:28 AM) loleary: It is very tempting.
(10:36:59 AM) loleary: Seems like a good solution for the time being.
(10:37:26 AM) loleary: If it is to network intense (which I doubt it would be) we can work on implementing a usable UDP version in a later release.
(10:38:00 AM) ramesh1: actually, we have UDP now
(10:38:19 AM) ramesh1: with separate gossip server
(10:38:21 AM) loleary: Well yeah... but it uses multicast.
(10:38:29 AM) loleary: True.
(10:38:56 AM) loleary: So, embedded router would be unicast with TCP to support fail-over.
(10:39:26 AM) ramesh1: so, we can keep what we have; if we do not want that then embedded router is TCP
(10:39:32 AM) ramesh1: true
(10:39:46 AM) loleary: Or, no router would use multicast with UDP or TCP... and a third option would be unicast with UDP or TCP using GossipRouter.
(10:39:55 AM) loleary: Right.
(10:39:57 AM) loleary: Sounds good.
(10:41:39 AM) ramesh1: I am leaning towards TCP one; I will get feedback from others
(10:43:04 AM) ramesh1: thanks
(10:43:33 AM) loleary: Right. That is what I am saying... the user would have those three deployment options. Our default would be Unicast over TCP using an embedded router that supports fail-over. Option two would be Multicast over UDP (what we do now by default) and option three would be Unicast over UDP or TCP using GossipRouter (like we offer now).
(10:44:32 AM) ramesh1: yep, got to think about the configuration options, but sounds good.
16 years, 11 months
Connector API changes for 6.1.0
by Steven Hawkins
I'm looking at addressing TEIID-525, TEIID-124, and TEIID-203, which all impact the Connector API. If there are additional comments on these or any other changes needed to the Connector API in the 6.1.0 cycle, please create let us know.
Thanks,
Steve
16 years, 11 months
Native JDBC vendor driver support in 6.0.0
by Ramesh Reddy
Starting with release Teiid 6.0.0 (Designer and Embedded) the support
for the vendor supplied JDBC drivers is extended to include
Oracle
Microsoft SQL Server
DB2
Teiid Designer will provide templates for you to use the vendor's JDBC
drivers to import and preview data from database. Embedded will work
with the native drivers in building a respective Connector connections.
Note that we *DO NOT* bundle any vendor JDBC drivers with Teiid kits,
you are still required for providing these drivers to be used with Teiid
Designer and Teiid Embedded and configuring them correctly to make use
of them.
"Data Direct" based JDBC templates for importing and building Connectors
are removed from community versions. Please note that you could still
use the "Data Direct" drivers, but pre-built customized templates are
not available. We will give directions on how you can use "Data Direct"
in forth coming WIKI article soon.
If you are looking for a specific Database support, please be sure to
let us know, and open up a JIRA.
Thanks.
Ramesh..
16 years, 11 months
Special Language Processors in Code
by Ramesh Reddy
Hi,
In support of providing a JDBC client which works with JDK 1.5, and
compatible with JDBC 3.0 per JIRA
https://jira.jboss.org/jira/browse/TEIID-177
I have added some language processing identifiers in the code like
//## JDBC4.0-begin ##
import java.sql.SQLXML;
//## JDBC4.0-end ##
/*## JDBC3.0-JDK1.5-begin ##
import com.metamatrix.core.jdbc.SQLXML;
## JDBC3.0-JDK1.5-end ##*/
which by use of additional ant tasks during the build can turn ON or OFF
certain portions of the code, that suits for the required 1.5 or 1.6
compilation of the code. The following projects have these processors
teiid-common-core
teiid-client
teiid-client-jdbc
So, when you are editing any of java code that has these processors,
please make a note of them and preserve them. Also, try to refrain from
using any java 1.6 specific methods, especially you can do with out in
your edits. A new project called
teiid-client-jdbc30
has been added for purposes of building the JDK1.5 supported client jar
file. This project copies the all the required java files from above
projects and runs the language processors and builds 1.5 compatible code
and builds the required jar file.
Thanks
Ramesh..
16 years, 11 months
Upcoming releases
by Steven Hawkins
The 6.1.0 release has been moved up to 5/21, with a target for an RC release on 5/4. There are several reasons for this adjustment:
- there have been several issues discovered with 6.0.0 (xa pooling, classloading issues, a mysql defect), so getting 6.1.0 out earlier will remove the need for a 6.0.1 release.
- the community release of server and console are in the 6.2.0 bucket, so only blocker and critical server/console defects will be worked in 6.1.0 with the remainder moved to 6.1.1
Please retarget or close out defects as necessary to help meet the target date.
Thanks,
Steve Hawkins
16 years, 11 months
Configuration Changes for Connectors
by Ramesh Reddy
Currently we do not have integrated way to pull together all the
'ConnectorType' information for the 'Embedded', this only working for
Server.
So, if you are editing the CDK information in connector's CDK file under
"/main/resources/.xml" file, then please note that those changes
manually need to move to embedded's configuration.xml. (in embedded's
kit)
Soon, we will have an integrated way to pull together configuration for
both server and embedded then we would not need this step. Until then
please make edits both places.
Ramesh..
17 years