[JBoss JIRA] (TEIID-4563) Too much COMMAND_LOG
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-4563?page=com.atlassian.jira.plugin... ]
Kylin Soong updated TEIID-4563:
-------------------------------
Description: I have found each query will generate 2 INFO COMMAND_LOG as attached server log, also the mat table update with a time interval, if this configured a little small, there will be great number of logs generated. (was: I have found each query will generate 2 INFO COMMAND_LOG as attached server log, also the mat table update wither a time interval, if these configured mall, there will be great number of logs generated.)
> Too much COMMAND_LOG
> --------------------
>
> Key: TEIID-4563
> URL: https://issues.jboss.org/browse/TEIID-4563
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Affects Versions: 9.2
> Reporter: Kylin Soong
> Assignee: Steven Hawkins
> Fix For: 9.2
>
> Attachments: server.log.zip
>
>
> I have found each query will generate 2 INFO COMMAND_LOG as attached server log, also the mat table update with a time interval, if this configured a little small, there will be great number of logs generated.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (TEIID-3825) Add a wildfly-swarm-teiid Fraction for running teiid as an uberjar
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-3825?page=com.atlassian.jira.plugin... ]
Kylin Soong edited comment on TEIID-3825 at 11/8/16 2:00 AM:
-------------------------------------------------------------
h2. How to Test
1. build teiid master
2. build swarm teiid(teiid/wildfly-swarm-teiid)
3. build swarm teiid example(teiid/wildfly-swarm-teiid-examples)
4. start uberjar like
{code}
java -jar vdb-datafederation/target/vdb-datafederation-swarm.jar
java -jar vdb-materialization/target/vdb-materialization-swarm.jar
java -jar rdbms-as-datasource/target/rdbms-as-datasource-swarm.jar
java -jar loopback-source/target/loopback-source-swarm.jar
{code}
Each module has a readme which contain more depictions and how to run.
I believe there will be some suggestions once you finished the test, for build swarm teiid, I am not configure the swarm related plugin in project, I use wildfly-swarm as parent instead
{code}
<parent>
<groupId>org.wildfly.swarm</groupId>
<artifactId>wildfly-swarm</artifactId>
<version>2016.8.1</version>
</parent>
<artifactId>teiid</artifactId>
<name>Teiid</name>
{code}
If take Bob's suggestions, put the swarm teiid together with others, I doubt there may have risk, because wildfly swarm is a sub-project of wildfly, the wildfly feature pack and config api swarm used are always base on latest wildfly version, for example:
* the least version of swarm base on wildfly 10.0.0 is 2016.8.1(swarm start from 2016.9 use wildfly 10.1)
* the teiid master still use wildfly 10.0.0
was (Author: kylin):
h2. How to Test
1. build teiid master
2. build swarm teiid(teiid/wildfly-swarm-teiid)
3. build swarm teiid example(teiid/wildfly-swarm-teiid-examples)
4. start uberjar like
{code}
java -jar vdb-datafederation/target/vdb-datafederation-swarm.jar
java -jar vdb-materialization/target/vdb-materialization-swarm.jar
java -jar rdbms-as-datasource/target/rdbms-as-datasource-swarm.jar
java -jar loopback-source/target/loopback-source-swarm.jar
{code}
Each module has a readme which contain more depictions and how to run.
> Add a wildfly-swarm-teiid Fraction for running teiid as an uberjar
> ------------------------------------------------------------------
>
> Key: TEIID-3825
> URL: https://issues.jboss.org/browse/TEIID-3825
> Project: Teiid
> Issue Type: Feature Request
> Components: Embedded
> Affects Versions: 9.0
> Reporter: Kylin Soong
> Assignee: Kylin Soong
> Fix For: 9.2
>
>
> Fractions within WildFly Swarm are roughly equivalent to subsystems within WildFly, we have teiid subsystem in Server mode, so I think a Fraction is necessary to run teiid with Swarm.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (TEIID-3825) Add a wildfly-swarm-teiid Fraction for running teiid as an uberjar
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-3825?page=com.atlassian.jira.plugin... ]
Kylin Soong commented on TEIID-3825:
------------------------------------
h2. How to Test
1. build teiid master
2. build swarm teiid(teiid/wildfly-swarm-teiid)
3. build swarm teiid example(teiid/wildfly-swarm-teiid-examples)
4. start uberjar like
{code}
java -jar vdb-datafederation/target/vdb-datafederation-swarm.jar
java -jar vdb-materialization/target/vdb-materialization-swarm.jar
java -jar rdbms-as-datasource/target/rdbms-as-datasource-swarm.jar
java -jar loopback-source/target/loopback-source-swarm.jar
{code}
Each module has a readme which contain more depictions and how to run.
> Add a wildfly-swarm-teiid Fraction for running teiid as an uberjar
> ------------------------------------------------------------------
>
> Key: TEIID-3825
> URL: https://issues.jboss.org/browse/TEIID-3825
> Project: Teiid
> Issue Type: Feature Request
> Components: Embedded
> Affects Versions: 9.0
> Reporter: Kylin Soong
> Assignee: Kylin Soong
> Fix For: 9.2
>
>
> Fractions within WildFly Swarm are roughly equivalent to subsystems within WildFly, we have teiid subsystem in Server mode, so I think a Fraction is necessary to run teiid with Swarm.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (TEIID-4563) Too much COMMAND_LOG
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-4563?page=com.atlassian.jira.plugin... ]
Kylin Soong commented on TEIID-4563:
------------------------------------
*server.log.zip* is the log that I test the feature pack and execute 10000 time query, it's size equal t0 38 MB and almost 99.9% are INFO COMMAND_LOG.
> Too much COMMAND_LOG
> --------------------
>
> Key: TEIID-4563
> URL: https://issues.jboss.org/browse/TEIID-4563
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Affects Versions: 9.2
> Reporter: Kylin Soong
> Assignee: Steven Hawkins
> Fix For: 9.2
>
> Attachments: server.log.zip
>
>
> I have found each query will generate 2 INFO COMMAND_LOG as attached server log, also the mat table update wither a time interval, if these configured mall, there will be great number of logs generated.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (TEIID-4563) Too much COMMAND_LOG
by Kylin Soong (JIRA)
Kylin Soong created TEIID-4563:
----------------------------------
Summary: Too much COMMAND_LOG
Key: TEIID-4563
URL: https://issues.jboss.org/browse/TEIID-4563
Project: Teiid
Issue Type: Quality Risk
Components: Query Engine
Affects Versions: 9.2
Reporter: Kylin Soong
Assignee: Steven Hawkins
Fix For: 9.2
I have found each query will generate 2 INFO COMMAND_LOG as attached server log, also the mat table update wither a time interval, if these configured mall, there will be great number of logs generated.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (TEIID-4437) Convert Teiid build to use "feature-pack"
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-4437?page=com.atlassian.jira.plugin... ]
Kylin Soong edited comment on TEIID-4437 at 11/8/16 1:12 AM:
-------------------------------------------------------------
salesforce-34 change seems be missed
{code}
13:11:37,651 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 50) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "resource-adapters"),
("resource-adapter" => "salesforce-34")
]) - failure description: "WFLYJCA0073: Failed to load module for RA [org.jboss.teiid.resource-adapter.salesforce-34]"
{code}
https://github.com/teiid/teiid/pull/824 is for this.
was (Author: kylin):
salesforce-34 change seems be missed
{code}
13:11:37,651 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 50) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "resource-adapters"),
("resource-adapter" => "salesforce-34")
]) - failure description: "WFLYJCA0073: Failed to load module for RA [org.jboss.teiid.resource-adapter.salesforce-34]"
{code}
> Convert Teiid build to use "feature-pack"
> -----------------------------------------
>
> Key: TEIID-4437
> URL: https://issues.jboss.org/browse/TEIID-4437
> Project: Teiid
> Issue Type: Task
> Components: Build/Kits
> Reporter: Ramesh Reddy
> Assignee: Kylin Soong
> Fix For: 9.2
>
>
> Change the current build process to build "feature-packs" for project, and then based on feature pack, build
> - WildFly Server distribution
> -WildFly Server Overlay distribution
> Teiid currently have distributions, but not based on feature-packs, they need to be. Other distributions like AdminShell do not fall into this category. Only distributions that has WF involvement need a feature -pack (this is important to remember).
> Currently Teiid uses "kit" directory in many different projects along with "wildfly-dist.xml" to populate "modules" directory. A feature-pack does EXACTLY same thing, but more with checks and balances. A feature pack, makes sure all the dependencies are met based on module.xml and module.xml defines the maven artifact rather than JAR file. i.e. it defines a metadata file, from which it can be build the zip file that "wildfly-dist.xml" assembly is currently doing. It also can has capabilities to "configure" the WF subsystem. That is manually done or done through CLI currently, using this part will be new.
> Implementation Rules
> 1) Every where we have "kit" directory, that module REQUIRES a "feature-pack" module. That means, every translator and resource-adapter gets it's own, and Teiid engine modules separately gets its own module. The reason to keep/create multiple modules is STRICTLY to keep the "modules" directory in feature-pack aligned ONE TO ONE with project that feature-pack represents. Otherwise, as developer we will NOT know which project is bringing in certain dependency, if all the modules are in single place. So, this is more about management of dependencies in a sane way. (Teiid did have all the modules in once place before in 7.x/8.x time, it is a nightmare to handle growing dependencies with our translators)
> 2) NONE of the work we have is useless/or need to be redone, most everything we have PERFECTLY maps to this effort, except for for configuration part.
> 3) For translator and resource adapter pair, I recommend that we pull them into single sub folder, and create a single feature pack for it. For example:
> we have
> {code}
> connectors/translator-mongodb
> connectors/connector-mongodb
> {code}
> I would like see we design as
> {code}
> connectors
> /mongdb
> /translator-mongodb
> /connector-mongodb
> /feature-pack-mongodb
> {code}
> No need to create "dist" packages for any resource-adapters or translators. As I mentioned in the beginning of the issue, there are two distributions, they are built using these various feature-packs.
> 4) I would like to see a clean move of "kit/wildfly/modules" to "feature-packs" using "git", NOT CUT n PASTE where we loose the GIT history. This will preserve the confidence that what we have currently is EXACTLY same as in future with feature-packs.
> 5) When designing the "feature-pack" projects, they ABSOLUTELY MUST NOT define any dependencies in their pom.xml other than Teiid project(s) they represent and any other feature-pack they refer to. (Kylin this is what cause most concern from your design for me)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (TEIID-4437) Convert Teiid build to use "feature-pack"
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-4437?page=com.atlassian.jira.plugin... ]
Kylin Soong commented on TEIID-4437:
------------------------------------
salesforce-34 change seems be missed
{code}
13:11:37,651 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 50) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "resource-adapters"),
("resource-adapter" => "salesforce-34")
]) - failure description: "WFLYJCA0073: Failed to load module for RA [org.jboss.teiid.resource-adapter.salesforce-34]"
{code}
> Convert Teiid build to use "feature-pack"
> -----------------------------------------
>
> Key: TEIID-4437
> URL: https://issues.jboss.org/browse/TEIID-4437
> Project: Teiid
> Issue Type: Task
> Components: Build/Kits
> Reporter: Ramesh Reddy
> Assignee: Kylin Soong
> Fix For: 9.2
>
>
> Change the current build process to build "feature-packs" for project, and then based on feature pack, build
> - WildFly Server distribution
> -WildFly Server Overlay distribution
> Teiid currently have distributions, but not based on feature-packs, they need to be. Other distributions like AdminShell do not fall into this category. Only distributions that has WF involvement need a feature -pack (this is important to remember).
> Currently Teiid uses "kit" directory in many different projects along with "wildfly-dist.xml" to populate "modules" directory. A feature-pack does EXACTLY same thing, but more with checks and balances. A feature pack, makes sure all the dependencies are met based on module.xml and module.xml defines the maven artifact rather than JAR file. i.e. it defines a metadata file, from which it can be build the zip file that "wildfly-dist.xml" assembly is currently doing. It also can has capabilities to "configure" the WF subsystem. That is manually done or done through CLI currently, using this part will be new.
> Implementation Rules
> 1) Every where we have "kit" directory, that module REQUIRES a "feature-pack" module. That means, every translator and resource-adapter gets it's own, and Teiid engine modules separately gets its own module. The reason to keep/create multiple modules is STRICTLY to keep the "modules" directory in feature-pack aligned ONE TO ONE with project that feature-pack represents. Otherwise, as developer we will NOT know which project is bringing in certain dependency, if all the modules are in single place. So, this is more about management of dependencies in a sane way. (Teiid did have all the modules in once place before in 7.x/8.x time, it is a nightmare to handle growing dependencies with our translators)
> 2) NONE of the work we have is useless/or need to be redone, most everything we have PERFECTLY maps to this effort, except for for configuration part.
> 3) For translator and resource adapter pair, I recommend that we pull them into single sub folder, and create a single feature pack for it. For example:
> we have
> {code}
> connectors/translator-mongodb
> connectors/connector-mongodb
> {code}
> I would like see we design as
> {code}
> connectors
> /mongdb
> /translator-mongodb
> /connector-mongodb
> /feature-pack-mongodb
> {code}
> No need to create "dist" packages for any resource-adapters or translators. As I mentioned in the beginning of the issue, there are two distributions, they are built using these various feature-packs.
> 4) I would like to see a clean move of "kit/wildfly/modules" to "feature-packs" using "git", NOT CUT n PASTE where we loose the GIT history. This will preserve the confidence that what we have currently is EXACTLY same as in future with feature-packs.
> 5) When designing the "feature-pack" projects, they ABSOLUTELY MUST NOT define any dependencies in their pom.xml other than Teiid project(s) they represent and any other feature-pack they refer to. (Kylin this is what cause most concern from your design for me)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (TEIID-4437) Convert Teiid build to use "feature-pack"
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4437?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-4437:
-------------------------------------
I think my .gitignore is set on bin directory, looks that may be the reason for missing files in this case of TEIID-4472
> Convert Teiid build to use "feature-pack"
> -----------------------------------------
>
> Key: TEIID-4437
> URL: https://issues.jboss.org/browse/TEIID-4437
> Project: Teiid
> Issue Type: Task
> Components: Build/Kits
> Reporter: Ramesh Reddy
> Assignee: Kylin Soong
> Fix For: 9.2
>
>
> Change the current build process to build "feature-packs" for project, and then based on feature pack, build
> - WildFly Server distribution
> -WildFly Server Overlay distribution
> Teiid currently have distributions, but not based on feature-packs, they need to be. Other distributions like AdminShell do not fall into this category. Only distributions that has WF involvement need a feature -pack (this is important to remember).
> Currently Teiid uses "kit" directory in many different projects along with "wildfly-dist.xml" to populate "modules" directory. A feature-pack does EXACTLY same thing, but more with checks and balances. A feature pack, makes sure all the dependencies are met based on module.xml and module.xml defines the maven artifact rather than JAR file. i.e. it defines a metadata file, from which it can be build the zip file that "wildfly-dist.xml" assembly is currently doing. It also can has capabilities to "configure" the WF subsystem. That is manually done or done through CLI currently, using this part will be new.
> Implementation Rules
> 1) Every where we have "kit" directory, that module REQUIRES a "feature-pack" module. That means, every translator and resource-adapter gets it's own, and Teiid engine modules separately gets its own module. The reason to keep/create multiple modules is STRICTLY to keep the "modules" directory in feature-pack aligned ONE TO ONE with project that feature-pack represents. Otherwise, as developer we will NOT know which project is bringing in certain dependency, if all the modules are in single place. So, this is more about management of dependencies in a sane way. (Teiid did have all the modules in once place before in 7.x/8.x time, it is a nightmare to handle growing dependencies with our translators)
> 2) NONE of the work we have is useless/or need to be redone, most everything we have PERFECTLY maps to this effort, except for for configuration part.
> 3) For translator and resource adapter pair, I recommend that we pull them into single sub folder, and create a single feature pack for it. For example:
> we have
> {code}
> connectors/translator-mongodb
> connectors/connector-mongodb
> {code}
> I would like see we design as
> {code}
> connectors
> /mongdb
> /translator-mongodb
> /connector-mongodb
> /feature-pack-mongodb
> {code}
> No need to create "dist" packages for any resource-adapters or translators. As I mentioned in the beginning of the issue, there are two distributions, they are built using these various feature-packs.
> 4) I would like to see a clean move of "kit/wildfly/modules" to "feature-packs" using "git", NOT CUT n PASTE where we loose the GIT history. This will preserve the confidence that what we have currently is EXACTLY same as in future with feature-packs.
> 5) When designing the "feature-pack" projects, they ABSOLUTELY MUST NOT define any dependencies in their pom.xml other than Teiid project(s) they represent and any other feature-pack they refer to. (Kylin this is what cause most concern from your design for me)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (TEIID-4437) Convert Teiid build to use "feature-pack"
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4437?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-4437:
-------------------------------------
Rebase did not show this one, I also did the "git mv". may if the original directory is deleted it will not show new adds? The scripts are in teiid-feature-pack/wildfly-integration-feature-pack/src/main/resources/content. I will add them. logging scripts are there in directory mentioned.
> Convert Teiid build to use "feature-pack"
> -----------------------------------------
>
> Key: TEIID-4437
> URL: https://issues.jboss.org/browse/TEIID-4437
> Project: Teiid
> Issue Type: Task
> Components: Build/Kits
> Reporter: Ramesh Reddy
> Assignee: Kylin Soong
> Fix For: 9.2
>
>
> Change the current build process to build "feature-packs" for project, and then based on feature pack, build
> - WildFly Server distribution
> -WildFly Server Overlay distribution
> Teiid currently have distributions, but not based on feature-packs, they need to be. Other distributions like AdminShell do not fall into this category. Only distributions that has WF involvement need a feature -pack (this is important to remember).
> Currently Teiid uses "kit" directory in many different projects along with "wildfly-dist.xml" to populate "modules" directory. A feature-pack does EXACTLY same thing, but more with checks and balances. A feature pack, makes sure all the dependencies are met based on module.xml and module.xml defines the maven artifact rather than JAR file. i.e. it defines a metadata file, from which it can be build the zip file that "wildfly-dist.xml" assembly is currently doing. It also can has capabilities to "configure" the WF subsystem. That is manually done or done through CLI currently, using this part will be new.
> Implementation Rules
> 1) Every where we have "kit" directory, that module REQUIRES a "feature-pack" module. That means, every translator and resource-adapter gets it's own, and Teiid engine modules separately gets its own module. The reason to keep/create multiple modules is STRICTLY to keep the "modules" directory in feature-pack aligned ONE TO ONE with project that feature-pack represents. Otherwise, as developer we will NOT know which project is bringing in certain dependency, if all the modules are in single place. So, this is more about management of dependencies in a sane way. (Teiid did have all the modules in once place before in 7.x/8.x time, it is a nightmare to handle growing dependencies with our translators)
> 2) NONE of the work we have is useless/or need to be redone, most everything we have PERFECTLY maps to this effort, except for for configuration part.
> 3) For translator and resource adapter pair, I recommend that we pull them into single sub folder, and create a single feature pack for it. For example:
> we have
> {code}
> connectors/translator-mongodb
> connectors/connector-mongodb
> {code}
> I would like see we design as
> {code}
> connectors
> /mongdb
> /translator-mongodb
> /connector-mongodb
> /feature-pack-mongodb
> {code}
> No need to create "dist" packages for any resource-adapters or translators. As I mentioned in the beginning of the issue, there are two distributions, they are built using these various feature-packs.
> 4) I would like to see a clean move of "kit/wildfly/modules" to "feature-packs" using "git", NOT CUT n PASTE where we loose the GIT history. This will preserve the confidence that what we have currently is EXACTLY same as in future with feature-packs.
> 5) When designing the "feature-pack" projects, they ABSOLUTELY MUST NOT define any dependencies in their pom.xml other than Teiid project(s) they represent and any other feature-pack they refer to. (Kylin this is what cause most concern from your design for me)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months