[JBoss JIRA] (TEIID-3116) Teiid Partial Results Mode: unavailability of datasource causes error (which is not masked)
by Jan Stastny (JIRA)
[ https://issues.jboss.org/browse/TEIID-3116?page=com.atlassian.jira.plugin... ]
Jan Stastny commented on TEIID-3116:
------------------------------------
I write to confirm, that after setting DatabaseVersion property to a translator via vdb.xml PartialResultsMode works as expected. As Van mentioned, it would be helpful a note about that in the doc's. And a sentence or two about what values does the DatabaseVersion support would be nice. There is some info at https://docs.jboss.org/author/display/teiid87final/JDBC+Translator, but not with each translator (sqlserver section mentions that, but oracle does not) and it is not linked from https://docs.jboss.org/author/display/TEIID/Partial+Results+Mode.
> Teiid Partial Results Mode: unavailability of datasource causes error (which is not masked)
> -------------------------------------------------------------------------------------------
>
> Key: TEIID-3116
> URL: https://issues.jboss.org/browse/TEIID-3116
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.7.1
> Reporter: Van Halbert
> Assignee: Steven Hawkins
> Priority: Critical
>
> Description of problem:
> Querying a vdb-table which is formed as union of two tables from different datasources. Even though "set partialresultsmode true" is run as initial query, instead of retreiving 0 rows from a datasources that is down, exception is promoted.
> Version-Release number of selected component (if applicable):
> DV 6.1 ER1
> How reproducible:
> Every time
> Steps to Reproduce:
> 1. Define one valid and one invalid datasource(invalid connection-url).
> 2. Create vdb which maps tables from both datasources.
> 3. Set partialresultsmode to true
> 4. Execute query on the given vdb-table
> Actual results:
> TeiidSQLException
> TEIID30498 Remote org.teiid.api.exception.query.QueryPlannerException: TEIID30498 Capabilities for ORBQT were not avaialable. The command could not be planned properly.
> Expected results:
> 0 rows from invalid datasource.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (TEIID-3117) NullPointerException while creating source model from Excel table
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3117?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3117:
------------------------------------------------
Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1138697|https://bugzilla.redhat.com/show_bug.cgi?id=1138697] from NEW to MODIFIED
> NullPointerException while creating source model from Excel table
> -----------------------------------------------------------------
>
> Key: TEIID-3117
> URL: https://issues.jboss.org/browse/TEIID-3117
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.7
> Environment: Fedora 20, data virtualization 6.1.0.ER1
> Reporter: Juraj Duráni
> Assignee: Ramesh Reddy
> Labels: Beta1
> Fix For: 8.7.1, 8.9
>
> Attachments: ExcelDynamic-vdb.xml, Server.log, smalla.xlsx, smalla_raw.xlsx
>
>
> I am trying to create source model from Excel file (.xlsx). When I set property "Header Row Number" to 1 (using Teiid Designer), creating ends with NullPointerException. Setting "Header Row Number" to 0 executes with no problems.
> Same problem (and same exception) with dynamic VDB (only with <property name="importer.headerRowNumber" value="1"/>).
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (TEIID-3026) NPE using Excel translator
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3026?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3026:
------------------------------------------------
Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1138697|https://bugzilla.redhat.com/show_bug.cgi?id=1138697] from NEW to MODIFIED
> NPE using Excel translator
> --------------------------
>
> Key: TEIID-3026
> URL: https://issues.jboss.org/browse/TEIID-3026
> Project: Teiid
> Issue Type: Bug
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Fix For: 8.8, 8.7.1
>
>
> {code}
> 10:48:26,620 WARN [org.teiid.RUNTIME] (teiid-async-threads - 3) TEIID50036 VDB importVDB.1 model "importVDBSrcModel" metadata failed to load. Reason:java.lang.NullPointerException: java.lang.NullPointerException
> at org.teiid.translator.excel.ExcelMetadataProcessor.addTable(ExcelMetadataProcessor.java:106)
> at org.teiid.translator.excel.ExcelMetadataProcessor.process(ExcelMetadataP
> rocessor.java:87)
> at org.teiid.translator.excel.ExcelMetadataProcessor.process(ExcelMetadataProcessor.java:45)
> at org.teiid.translator.ExecutionFactory.getMetadata(ExecutionFactory.java:915) [teiid-api-8.7.0.Final.jar:8.7.0.Final]
> at org.teiid.query.metadata.NativeMetadataRepository.loadMetadata(NativeMetadataRepository.java:73) [teiid-engine-8.7.0.Final.jar:8.7.0.Final]
> at org.teiid.query.metadata.ChainingMetadataRepository.loadMetadata(ChainingMetadataRepository.java:55) [teiid-engine-8.7.0.Final.jar:8.7.0.Final]
> at org.teiid.jboss.VDBService$6.run(VDBService.java:395) [teiid-jboss-integration-8.7.0.Final.jar:8.7.0.Final]
> at org.teiid.jboss.VDBService$7.run(VDBService.java:442) [teiid-jboss-integration-8.7.0.Final.jar:8.7.0.Final]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [rt.jar:1.6.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [rt.jar:1.6.0_45]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_45]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (TEIID-3117) NullPointerException while creating source model from Excel table
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3117?page=com.atlassian.jira.plugin... ]
Ramesh Reddy resolved TEIID-3117.
---------------------------------
Labels: Beta1 (was: )
Fix Version/s: 8.7.1
8.9
Resolution: Done
The issue here is during the metadata building, the translator looks at the data row configured to sniff out the data types. If the given data row has a empty cell, the above exception occurs.
As workaround, when a cell is empty, I have added code to look for non empty cell in the next available row, it that empty it will forward cursor until it finds a non-null cell value. If all the values are null then it will choose the data type as string.
> NullPointerException while creating source model from Excel table
> -----------------------------------------------------------------
>
> Key: TEIID-3117
> URL: https://issues.jboss.org/browse/TEIID-3117
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.7
> Environment: Fedora 20, data virtualization 6.1.0.ER1
> Reporter: Juraj Duráni
> Assignee: Ramesh Reddy
> Labels: Beta1
> Fix For: 8.7.1, 8.9
>
> Attachments: ExcelDynamic-vdb.xml, Server.log, smalla.xlsx, smalla_raw.xlsx
>
>
> I am trying to create source model from Excel file (.xlsx). When I set property "Header Row Number" to 1 (using Teiid Designer), creating ends with NullPointerException. Setting "Header Row Number" to 0 executes with no problems.
> Same problem (and same exception) with dynamic VDB (only with <property name="importer.headerRowNumber" value="1"/>).
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (TEIID-3118) Excel translator is not able to manage WHERE clause with time value
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3118?page=com.atlassian.jira.plugin... ]
Ramesh Reddy resolved TEIID-3118.
---------------------------------
Labels: Beta1 (was: )
Fix Version/s: 8.7.1
8.9
Resolution: Done
Excel supports WHERE clause push down only on ROW_ID, in this case it is being handled by the engine. However this is what I see. When engine builds the java.sql.Time instance it from Epoach, where as the java.sql.Time object that is built in Excel is from a date type that Apache POI returns. Even though the time value is correct the date value is not from these both instances thus they do not match.
The solution is just to extract the Time specific value from Excel instance and build the Time result.
> Excel translator is not able to manage WHERE clause with time value
> -------------------------------------------------------------------
>
> Key: TEIID-3118
> URL: https://issues.jboss.org/browse/TEIID-3118
> Project: Teiid
> Issue Type: Bug
> Reporter: Juraj Duráni
> Assignee: Ramesh Reddy
> Labels: Beta1
> Fix For: 8.7.1, 8.9
>
>
> Excel translator is not able to manage WHERE clause with time value. When I use time value in WHERE clause (with <, >, =) I get bad result. There is no problem with Timestamp and Date.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (TEIID-3106) BufferManager Cleaner consuming 90% of total CPU time
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3106?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3106:
---------------------------------------
Ok, there is another commit. I believe another possible issue was when the persistent flag was set, which could cause an issue in that the insertion into the secondary queue will modify the key while the entry is still in the initial queue.
> BufferManager Cleaner consuming 90% of total CPU time
> -----------------------------------------------------
>
> Key: TEIID-3106
> URL: https://issues.jboss.org/browse/TEIID-3106
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.7
> Environment: zOS
> Reporter: Devesh Mishra
> Assignee: Steven Hawkins
> Labels: teiid-engine
> Attachments: BufferManagerImpl.java, BufferManagerImpl.java, CacheKey_Loog.patch, complete_log.zip, cpu monitoring.docx, dump.zip, in_local.docx, LrfuEvictionQueue.java, LrfuEvictionQueue.patch, non_high_cpu.docx
>
>
> BufferManager Cleaner thread is consuming almost all of the CPU utilized by the jboss process. Thread dump shows following information.
> 3XMTHREADINFO "BufferManager Cleaner" J9VMThread:0x0000004C41CFEB00, j9thread_t:0x0000004C52B85AE0, java/lang/Thread:0x000000481C036E20, state:CW, prio=5
> 3XMJAVALTHREAD (java/lang/Thread getId:0x76, isDaemon:true)
> 3XMTHREADINFO1 (native thread ID:0x3AEC2600, native priority:0x5, native policy:UNKNOWN)
> 3XMHEAPALLOC Heap bytes allocated since last GC cycle=2609184 (0x27D020)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACE at java/util/concurrent/ConcurrentSkipListMap.doRemove(ConcurrentSkipListMap.java:1070(Compiled Code))
> 4XESTACKTRACE at java/util/concurrent/ConcurrentSkipListMap.remove(ConcurrentSkipListMap.java:1659(Compiled Code))
> 4XESTACKTRACE at org/teiid/common/buffer/impl/LrfuEvictionQueue.remove(LrfuEvictionQueue.java:60(Compiled Code))
> 4XESTACKTRACE at org/teiid/common/buffer/impl/BufferManagerImpl.doEvictions(BufferManagerImpl.java:854(Compiled Code))
> 5XESTACKTRACE (entered lock: org/teiid/common/buffer/CacheEntry@0x00000048393C2598, entry count: 1)
> 4XESTACKTRACE at org/teiid/common/buffer/impl/BufferManagerImpl$Cleaner.run(BufferManagerImpl.java:108)
> 4XESTACKTRACE at java/util/TimerThread.mainLoop(Timer.java:555)
> 4XESTACKTRACE at java/util/TimerThread.run(Timer.java:505)
> When we added log statements around the BufferManagerImpl.doEvictions() it loops through the remove and firstEntry loop.
> Forum discussion link : https://community.jboss.org/message/901792
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (TEIID-3106) BufferManager Cleaner consuming 90% of total CPU time
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3106?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3106:
---------------------------------------
Yes, that appears to be the concurrency issue which is modifying the key of an entry that is already in the queue. I'll add another commit to correct that.
> BufferManager Cleaner consuming 90% of total CPU time
> -----------------------------------------------------
>
> Key: TEIID-3106
> URL: https://issues.jboss.org/browse/TEIID-3106
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.7
> Environment: zOS
> Reporter: Devesh Mishra
> Assignee: Steven Hawkins
> Labels: teiid-engine
> Attachments: BufferManagerImpl.java, BufferManagerImpl.java, CacheKey_Loog.patch, complete_log.zip, cpu monitoring.docx, dump.zip, in_local.docx, LrfuEvictionQueue.java, LrfuEvictionQueue.patch, non_high_cpu.docx
>
>
> BufferManager Cleaner thread is consuming almost all of the CPU utilized by the jboss process. Thread dump shows following information.
> 3XMTHREADINFO "BufferManager Cleaner" J9VMThread:0x0000004C41CFEB00, j9thread_t:0x0000004C52B85AE0, java/lang/Thread:0x000000481C036E20, state:CW, prio=5
> 3XMJAVALTHREAD (java/lang/Thread getId:0x76, isDaemon:true)
> 3XMTHREADINFO1 (native thread ID:0x3AEC2600, native priority:0x5, native policy:UNKNOWN)
> 3XMHEAPALLOC Heap bytes allocated since last GC cycle=2609184 (0x27D020)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACE at java/util/concurrent/ConcurrentSkipListMap.doRemove(ConcurrentSkipListMap.java:1070(Compiled Code))
> 4XESTACKTRACE at java/util/concurrent/ConcurrentSkipListMap.remove(ConcurrentSkipListMap.java:1659(Compiled Code))
> 4XESTACKTRACE at org/teiid/common/buffer/impl/LrfuEvictionQueue.remove(LrfuEvictionQueue.java:60(Compiled Code))
> 4XESTACKTRACE at org/teiid/common/buffer/impl/BufferManagerImpl.doEvictions(BufferManagerImpl.java:854(Compiled Code))
> 5XESTACKTRACE (entered lock: org/teiid/common/buffer/CacheEntry@0x00000048393C2598, entry count: 1)
> 4XESTACKTRACE at org/teiid/common/buffer/impl/BufferManagerImpl$Cleaner.run(BufferManagerImpl.java:108)
> 4XESTACKTRACE at java/util/TimerThread.mainLoop(Timer.java:555)
> 4XESTACKTRACE at java/util/TimerThread.run(Timer.java:505)
> When we added log statements around the BufferManagerImpl.doEvictions() it loops through the remove and firstEntry loop.
> Forum discussion link : https://community.jboss.org/message/901792
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (TEIID-3106) BufferManager Cleaner consuming 90% of total CPU time
by Devesh Mishra (JIRA)
[ https://issues.jboss.org/browse/TEIID-3106?page=com.atlassian.jira.plugin... ]
Devesh Mishra updated TEIID-3106:
---------------------------------
Attachment: complete_log.zip
> BufferManager Cleaner consuming 90% of total CPU time
> -----------------------------------------------------
>
> Key: TEIID-3106
> URL: https://issues.jboss.org/browse/TEIID-3106
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.7
> Environment: zOS
> Reporter: Devesh Mishra
> Assignee: Steven Hawkins
> Labels: teiid-engine
> Attachments: BufferManagerImpl.java, BufferManagerImpl.java, CacheKey_Loog.patch, complete_log.zip, cpu monitoring.docx, dump.zip, in_local.docx, LrfuEvictionQueue.java, LrfuEvictionQueue.patch, non_high_cpu.docx
>
>
> BufferManager Cleaner thread is consuming almost all of the CPU utilized by the jboss process. Thread dump shows following information.
> 3XMTHREADINFO "BufferManager Cleaner" J9VMThread:0x0000004C41CFEB00, j9thread_t:0x0000004C52B85AE0, java/lang/Thread:0x000000481C036E20, state:CW, prio=5
> 3XMJAVALTHREAD (java/lang/Thread getId:0x76, isDaemon:true)
> 3XMTHREADINFO1 (native thread ID:0x3AEC2600, native priority:0x5, native policy:UNKNOWN)
> 3XMHEAPALLOC Heap bytes allocated since last GC cycle=2609184 (0x27D020)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACE at java/util/concurrent/ConcurrentSkipListMap.doRemove(ConcurrentSkipListMap.java:1070(Compiled Code))
> 4XESTACKTRACE at java/util/concurrent/ConcurrentSkipListMap.remove(ConcurrentSkipListMap.java:1659(Compiled Code))
> 4XESTACKTRACE at org/teiid/common/buffer/impl/LrfuEvictionQueue.remove(LrfuEvictionQueue.java:60(Compiled Code))
> 4XESTACKTRACE at org/teiid/common/buffer/impl/BufferManagerImpl.doEvictions(BufferManagerImpl.java:854(Compiled Code))
> 5XESTACKTRACE (entered lock: org/teiid/common/buffer/CacheEntry@0x00000048393C2598, entry count: 1)
> 4XESTACKTRACE at org/teiid/common/buffer/impl/BufferManagerImpl$Cleaner.run(BufferManagerImpl.java:108)
> 4XESTACKTRACE at java/util/TimerThread.mainLoop(Timer.java:555)
> 4XESTACKTRACE at java/util/TimerThread.run(Timer.java:505)
> When we added log statements around the BufferManagerImpl.doEvictions() it loops through the remove and firstEntry loop.
> Forum discussion link : https://community.jboss.org/message/901792
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (TEIID-3106) BufferManager Cleaner consuming 90% of total CPU time
by Devesh Mishra (JIRA)
[ https://issues.jboss.org/browse/TEIID-3106?page=com.atlassian.jira.plugin... ]
Devesh Mishra commented on TEIID-3106:
--------------------------------------
:( Looks like I forgot to attach Pls check complete_log.zip. Thanks
> BufferManager Cleaner consuming 90% of total CPU time
> -----------------------------------------------------
>
> Key: TEIID-3106
> URL: https://issues.jboss.org/browse/TEIID-3106
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.7
> Environment: zOS
> Reporter: Devesh Mishra
> Assignee: Steven Hawkins
> Labels: teiid-engine
> Attachments: BufferManagerImpl.java, BufferManagerImpl.java, CacheKey_Loog.patch, complete_log.zip, cpu monitoring.docx, dump.zip, in_local.docx, LrfuEvictionQueue.java, LrfuEvictionQueue.patch, non_high_cpu.docx
>
>
> BufferManager Cleaner thread is consuming almost all of the CPU utilized by the jboss process. Thread dump shows following information.
> 3XMTHREADINFO "BufferManager Cleaner" J9VMThread:0x0000004C41CFEB00, j9thread_t:0x0000004C52B85AE0, java/lang/Thread:0x000000481C036E20, state:CW, prio=5
> 3XMJAVALTHREAD (java/lang/Thread getId:0x76, isDaemon:true)
> 3XMTHREADINFO1 (native thread ID:0x3AEC2600, native priority:0x5, native policy:UNKNOWN)
> 3XMHEAPALLOC Heap bytes allocated since last GC cycle=2609184 (0x27D020)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACE at java/util/concurrent/ConcurrentSkipListMap.doRemove(ConcurrentSkipListMap.java:1070(Compiled Code))
> 4XESTACKTRACE at java/util/concurrent/ConcurrentSkipListMap.remove(ConcurrentSkipListMap.java:1659(Compiled Code))
> 4XESTACKTRACE at org/teiid/common/buffer/impl/LrfuEvictionQueue.remove(LrfuEvictionQueue.java:60(Compiled Code))
> 4XESTACKTRACE at org/teiid/common/buffer/impl/BufferManagerImpl.doEvictions(BufferManagerImpl.java:854(Compiled Code))
> 5XESTACKTRACE (entered lock: org/teiid/common/buffer/CacheEntry@0x00000048393C2598, entry count: 1)
> 4XESTACKTRACE at org/teiid/common/buffer/impl/BufferManagerImpl$Cleaner.run(BufferManagerImpl.java:108)
> 4XESTACKTRACE at java/util/TimerThread.mainLoop(Timer.java:555)
> 4XESTACKTRACE at java/util/TimerThread.run(Timer.java:505)
> When we added log statements around the BufferManagerImpl.doEvictions() it loops through the remove and firstEntry loop.
> Forum discussion link : https://community.jboss.org/message/901792
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months