[JBoss JIRA] (TEIID-4952) release notes is not having tokens replaced
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-4952:
-------------------------------------
Summary: release notes is not having tokens replaced
Key: TEIID-4952
URL: https://issues.jboss.org/browse/TEIID-4952
Project: Teiid
Issue Type: Task
Components: Build/Kits
Affects Versions: 9.1
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 10.0
When the server kit feature pack is built the release notes is not having project.version replaced.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years
[JBoss JIRA] (TEIID-4896) Two VDB's referencing same teiid_ispn:cache is not using the same cache
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4896?page=com.atlassian.jira.plugin... ]
Ramesh Reddy reassigned TEIID-4896:
-----------------------------------
Assignee: Van Halbert (was: Ramesh Reddy)
> Two VDB's referencing same teiid_ispn:cache is not using the same cache
> -----------------------------------------------------------------------
>
> Key: TEIID-4896
> URL: https://issues.jboss.org/browse/TEIID-4896
> Project: Teiid
> Issue Type: Bug
> Components: Infinispan
> Affects Versions: 9.3
> Reporter: Van Halbert
> Assignee: Van Halbert
> Fix For: 9.3.1
>
> Attachments: jdg-remote-cache-ddl-vdb.xml, jdg-remote-cache-registered-pb-vdb.xml
>
>
> I have 2 VDB's where they both reference the same cache using OPTIONS property:
> "teiid_ispn:cache" 'datasourceCache'
> However, when I insert into one VDB, its not seen by the other VDB.
> This was testing out the translators ability to use an already registered protobuf in Infinispan.
> The first VDB (jdg-remote-cache-vdb.xml) was deployed and then inserted and selected the results. This registered the protobuf.
> The second VDB (jdg-remote-cache-registered-pb-vdb.xml) was then deployed and was expecting to be able to read the same cache. The metadata was derived correctly, but it appears that one of the two are using the default cache, not the specified cache.
> I'll attach the vdb's.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years
[JBoss JIRA] (TEIID-4948) java.lang.IllegalArgumentException: No marshaller registered for ispn.G1
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4948?page=com.atlassian.jira.plugin... ]
Ramesh Reddy resolved TEIID-4948.
---------------------------------
Fix Version/s: 9.3.1
Resolution: Done
The issue is when DDL is provided instead of .proto file as the metadata, internally the DDL is first converted to .proto file and then DDL is generated back. However, during the regeneration previously defined extension metadata on the DDL based tables is not restored back to the original values, thus the error about duplicate/non-existing marshallers.
This fix copies the extension metadata back again on to the generated schema. I believe TEIID-4896 may be a duplicate of this issue.
> java.lang.IllegalArgumentException: No marshaller registered for ispn.G1
> ------------------------------------------------------------------------
>
> Key: TEIID-4948
> URL: https://issues.jboss.org/browse/TEIID-4948
> Project: Teiid
> Issue Type: Bug
> Components: Infinispan
> Affects Versions: 9.3
> Reporter: Van Halbert
> Assignee: Ramesh Reddy
> Fix For: 9.3.1
>
> Attachments: jdg-remote-cache-ddl-vdb.xml
>
>
> Deploying a VDB that contains 2 models with tables that reference the same JNDI, but defined different caches. (see vdb attached).
> Can query both caches and based on results, I know they are not the same cache.
> When performing an insert to the first table (G1) it works. When performing an insert to other table (G2), get the IllegalArgmentException.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years
[JBoss JIRA] (TEIID-4948) java.lang.IllegalArgumentException: No marshaller registered for ispn.G1
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4948?page=com.atlassian.jira.plugin... ]
Ramesh Reddy reassigned TEIID-4948:
-----------------------------------
Assignee: Ramesh Reddy (was: Van Halbert)
> java.lang.IllegalArgumentException: No marshaller registered for ispn.G1
> ------------------------------------------------------------------------
>
> Key: TEIID-4948
> URL: https://issues.jboss.org/browse/TEIID-4948
> Project: Teiid
> Issue Type: Bug
> Components: Infinispan
> Affects Versions: 9.3
> Reporter: Van Halbert
> Assignee: Ramesh Reddy
> Attachments: jdg-remote-cache-ddl-vdb.xml
>
>
> Deploying a VDB that contains 2 models with tables that reference the same JNDI, but defined different caches. (see vdb attached).
> Can query both caches and based on results, I know they are not the same cache.
> When performing an insert to the first table (G1) it works. When performing an insert to other table (G2), get the IllegalArgmentException.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years
[JBoss JIRA] (TEIID-4896) Two VDB's referencing same teiid_ispn:cache is not using the same cache
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4896?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-4896:
-------------------------------------
I see "CACHE" extension metadata usage is consistent as designed, it does make sure that during the selection or updates it does use the name to grab the correct cache from CacheFactory.
I will change the code such that during the metadata import the cache name is set, such that extra DDL statement is not required. It will be set to the default cache name that is defined in the configuration. If it that is different from the default, then we can use the DDL ALTER option to set to correct one. This will cut down one extra step.
> Two VDB's referencing same teiid_ispn:cache is not using the same cache
> -----------------------------------------------------------------------
>
> Key: TEIID-4896
> URL: https://issues.jboss.org/browse/TEIID-4896
> Project: Teiid
> Issue Type: Bug
> Components: Infinispan
> Affects Versions: 9.3
> Reporter: Van Halbert
> Assignee: Ramesh Reddy
> Fix For: 9.3.1
>
> Attachments: jdg-remote-cache-ddl-vdb.xml, jdg-remote-cache-registered-pb-vdb.xml
>
>
> I have 2 VDB's where they both reference the same cache using OPTIONS property:
> "teiid_ispn:cache" 'datasourceCache'
> However, when I insert into one VDB, its not seen by the other VDB.
> This was testing out the translators ability to use an already registered protobuf in Infinispan.
> The first VDB (jdg-remote-cache-vdb.xml) was deployed and then inserted and selected the results. This registered the protobuf.
> The second VDB (jdg-remote-cache-registered-pb-vdb.xml) was then deployed and was expecting to be able to read the same cache. The metadata was derived correctly, but it appears that one of the two are using the default cache, not the specified cache.
> I'll attach the vdb's.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years
[JBoss JIRA] (TEIID-4861) ASSERTION FAILED: expected reference to be not null
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-4861?page=com.atlassian.jira.plugin... ]
Van Halbert updated TEIID-4861:
-------------------------------
Git Pull Request: https://github.com/teiid/teiid/pull/966
> ASSERTION FAILED: expected reference to be not null
> ---------------------------------------------------
>
> Key: TEIID-4861
> URL: https://issues.jboss.org/browse/TEIID-4861
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 9.0.2, 9.2.1, 9.2.2
> Reporter: Harold Campbell
> Assignee: Steven Hawkins
> Fix For: 9.3, 8.12.x-6.4, 9.2.3, 8.12.11.6_3
>
> Attachments: DEBUG_LOG, DEBUG_LOG_WORKS
>
>
> I have a vdb containing a multi-source schema (channel) and a single source schema (ops). The following query which uses an aggregate function and groups by both a mulit-source column and a single source column causes the error "TEIID30019 Unexpected exception for request l1HvA1r84nyA.0: java.lang.AssertionError: ASSERTION FAILED: expected reference to be not null" and a stack trace which looks quite similar to that in TEIID-4325:
> {code}
> select s.channel, m.user_name, count(*)
> from channel.dbo.service_request s
> join ops.dbo.manager m
> on s.staff_id = m.manager_id
> group by s.channel, m.user_name;
> {code}
> Apr 15 20:09:52 localhost docker[27044]: 2017-04-16 01:09:52,237 ERROR [org.teiid.PROCESSOR] (Worker2_QueryProcessorQueue7) l1HvA1r84nyA TEIID30019 Unexpected exception for request l1HvA1r84nyA.0: java.lang.AssertionError: ASSERTION FAILED: expected reference to be not null
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.core.util.Assertion.failed(Assertion.java:73)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.core.util.Assertion.isNotNull(Assertion.java:100)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.core.util.Assertion.isNotNull(Assertion.java:92)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.relational.RelationalNode.getProjectionIndexes(RelationalNode.java:367)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.relational.JoinNode.initialize(JoinNode.java:133)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:96)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:102)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:102)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:102)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.relational.RelationalPlan.initialize(RelationalPlan.java:91)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.QueryProcessor.init(QueryProcessor.java:226)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:138)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:164)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:477)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:349)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:275)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:282)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210)
> Apr 15 20:09:52 localhost docker[27044]: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> Apr 15 20:09:52 localhost docker[27044]: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> Apr 15 20:09:52 localhost docker[27044]: at java.lang.Thread.run(Thread.java:745)
> Interestingly, if I narrow the query down to specific channels the error goes away:
> {code}
> select s.channel, m.user_name, count(*)
> from channel.dbo.service_request s
> join ops.dbo.manager m
> on s.staff_id = m.manager_id
> where channel in ('oak', 'cypress')
> group by s.channel, m.user_name;
> {code}
> I will attach both query plans.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years
[JBoss JIRA] (TEIID-4861) ASSERTION FAILED: expected reference to be not null
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-4861?page=com.atlassian.jira.plugin... ]
Van Halbert updated TEIID-4861:
-------------------------------
Fix Version/s: 8.12.x-6.4
> ASSERTION FAILED: expected reference to be not null
> ---------------------------------------------------
>
> Key: TEIID-4861
> URL: https://issues.jboss.org/browse/TEIID-4861
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 9.0.2, 9.2.1, 9.2.2
> Reporter: Harold Campbell
> Assignee: Steven Hawkins
> Fix For: 9.3, 8.12.x-6.4, 9.2.3, 8.12.11.6_3
>
> Attachments: DEBUG_LOG, DEBUG_LOG_WORKS
>
>
> I have a vdb containing a multi-source schema (channel) and a single source schema (ops). The following query which uses an aggregate function and groups by both a mulit-source column and a single source column causes the error "TEIID30019 Unexpected exception for request l1HvA1r84nyA.0: java.lang.AssertionError: ASSERTION FAILED: expected reference to be not null" and a stack trace which looks quite similar to that in TEIID-4325:
> {code}
> select s.channel, m.user_name, count(*)
> from channel.dbo.service_request s
> join ops.dbo.manager m
> on s.staff_id = m.manager_id
> group by s.channel, m.user_name;
> {code}
> Apr 15 20:09:52 localhost docker[27044]: 2017-04-16 01:09:52,237 ERROR [org.teiid.PROCESSOR] (Worker2_QueryProcessorQueue7) l1HvA1r84nyA TEIID30019 Unexpected exception for request l1HvA1r84nyA.0: java.lang.AssertionError: ASSERTION FAILED: expected reference to be not null
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.core.util.Assertion.failed(Assertion.java:73)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.core.util.Assertion.isNotNull(Assertion.java:100)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.core.util.Assertion.isNotNull(Assertion.java:92)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.relational.RelationalNode.getProjectionIndexes(RelationalNode.java:367)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.relational.JoinNode.initialize(JoinNode.java:133)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:96)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:102)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:102)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:102)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.relational.RelationalPlan.initialize(RelationalPlan.java:91)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.QueryProcessor.init(QueryProcessor.java:226)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:138)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:164)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:477)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:349)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:275)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:282)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210)
> Apr 15 20:09:52 localhost docker[27044]: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> Apr 15 20:09:52 localhost docker[27044]: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> Apr 15 20:09:52 localhost docker[27044]: at java.lang.Thread.run(Thread.java:745)
> Interestingly, if I narrow the query down to specific channels the error goes away:
> {code}
> select s.channel, m.user_name, count(*)
> from channel.dbo.service_request s
> join ops.dbo.manager m
> on s.staff_id = m.manager_id
> where channel in ('oak', 'cypress')
> group by s.channel, m.user_name;
> {code}
> I will attach both query plans.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years
[JBoss JIRA] (TEIID-4951) get-schema CLI call ending up NPE
by Ramesh Reddy (JIRA)
Ramesh Reddy created TEIID-4951:
-----------------------------------
Summary: get-schema CLI call ending up NPE
Key: TEIID-4951
URL: https://issues.jboss.org/browse/TEIID-4951
Project: Teiid
Issue Type: Bug
Components: AdminApi
Affects Versions: 9.2
Reporter: Ramesh Reddy
Assignee: Ramesh Reddy
A CLI call like
/subsystem=teiid:get-schema(vdb-name=ispn, vdb-version=1)
producing
{code}
4:45:28,356 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 7) WFLYCTL0013: Operation ("get-schema") failed - address: ([("subsystem" => "teiid")]): java.lang.NullPointerException
at java.lang.String$CaseInsensitiveComparator.compare(String.java:1192)
at java.lang.String$CaseInsensitiveComparator.compare(String.java:1186)
at java.util.TreeMap.getEntryUsingComparator(TreeMap.java:376)
at java.util.TreeMap.getEntry(TreeMap.java:345)
at java.util.TreeMap.get(TreeMap.java:278)
at org.teiid.metadata.MetadataStore.getSchema(MetadataStore.java:56)
at org.teiid.jboss.GetSchema.executeOperation(TeiidOperationHandler.java:937)
at org.teiid.jboss.GetSchema.executeOperation(TeiidOperationHandler.java:875)
at org.teiid.jboss.BaseOperationHandler$1.execute(BaseOperationHandler.java:79)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:208)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:152)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:148)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:148)
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years
[JBoss JIRA] (TEIID-4948) java.lang.IllegalArgumentException: No marshaller registered for ispn.G1
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-4948?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-4948:
------------------------------------
Hm, I didn't do much of a test the first time. Which the data was different between both inserts for each table. However, when I tried to insert into the G2 table with the same data as G1, it threw the same exception. And then I changed the data to be different (than used in G1 insert) and it worked.
> java.lang.IllegalArgumentException: No marshaller registered for ispn.G1
> ------------------------------------------------------------------------
>
> Key: TEIID-4948
> URL: https://issues.jboss.org/browse/TEIID-4948
> Project: Teiid
> Issue Type: Bug
> Components: Infinispan
> Affects Versions: 9.3
> Reporter: Van Halbert
> Assignee: Van Halbert
> Attachments: jdg-remote-cache-ddl-vdb.xml
>
>
> Deploying a VDB that contains 2 models with tables that reference the same JNDI, but defined different caches. (see vdb attached).
> Can query both caches and based on results, I know they are not the same cache.
> When performing an insert to the first table (G1) it works. When performing an insert to other table (G2), get the IllegalArgmentException.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years