[JBoss JIRA] (TEIID-3661) Spatial functions broken
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3661?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-3661.
---------------------------------
> Spatial functions broken
> ------------------------
>
> Key: TEIID-3661
> URL: https://issues.jboss.org/browse/TEIID-3661
> Project: Teiid
> Issue Type: Bug
> Components: Build/Kits
> Affects Versions: 8.11, 8.12, 8.11.1, 8.11.2
> Reporter: Tom Arnold
> Assignee: Steven Hawkins
> Fix For: 8.12, 8.11.3
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> Spatial functions (like {{ST_GeomFromText}}) are broken in the JBoss kit by the module refactor that happened around 8.11.0.Beta2.
> {code}
> select st_geomfromtext('POINT(0 0)');
> {code}
> {code}
> Caused by: java.lang.NoClassDefFoundError: org/xml/sax/helpers/DefaultHandler
> at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.7.0_79]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:800) [rt.jar:1.7.0_79]
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:361) [jboss-modules.jar:1.3.6.Final-redhat-1]
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:482) [jboss-modules.jar:1.3.6.Final-redhat-1]
> ... 61 more
> Caused by: java.lang.ClassNotFoundException: org.xml.sax.helpers.DefaultHandler from [Module "com.vividsolutions:main" from local module loader @1de368ab (finder: local module finder @3cecc1e1 (roots: /home/tom/wkspace/teiid-8.12.0.Beta2-SNAPSHOT/modules,/home/tom/wkspace/teiid-8.12.0.Beta2-SNAPSHOT/modules/system/layers/dv,/home/tom/wkspace/teiid-8.12.0.Beta2-SNAPSHOT/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.6.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.6.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.6.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.6.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.6.Final-redhat-1]
> ... 65 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (TEIID-3558) Duplicate records being for formed for Internal Materialized View cluster
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3558?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-3558.
---------------------------------
> Duplicate records being for formed for Internal Materialized View cluster
> -------------------------------------------------------------------------
>
> Key: TEIID-3558
> URL: https://issues.jboss.org/browse/TEIID-3558
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.0
> Reporter: Pranav K
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 8.7.1.6_2, 8.12, 8.7.4, 8.11.1
>
>
> -On running a query over one of the nodes of a cluster (say node A) to fetch 25000 records (with internal materialization switched on), the cache gets formed on node A and presumably gets synced using the JgroupsObjectReplicator.
> -On running the same query on the cache formed in the other node (node B), I noticed that I was getting 25600 records.
> -On analysis the records, I saw there were only 1024 distinct records each of which repeated 25 times.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (TEIID-3596) Command logging: last command's log is not ended
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3596?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-3596.
---------------------------------
> Command logging: last command's log is not ended
> ------------------------------------------------
>
> Key: TEIID-3596
> URL: https://issues.jboss.org/browse/TEIID-3596
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.7.1.6_2
> Reporter: Jan Stastny
> Assignee: Steven Hawkins
>
> There are incomplete entries when performing queries on some vdb and examining the org.teiid.COMMAND_LOG entries in server.log.
> From the logs it seems, that the closing entry for a user command is not logged until either another command is performed or the server is shut down.
> The following logs appears right after the command is performed:
> {code:plain}
> [org.teiid.COMMAND_LOG] (New I/O worker #64) START USER COMMAND: startTime=2015-07-28 13:43:18.441 requestID=rfFDiTxhxLGL.0 txID=null sessionID=rfFDiTxhxLGL applicationName=JDBC principal=user@teiid-security vdbName=Portfolio vdbVersion=1 sql=select * from product
> [org.teiid.COMMAND_LOG] (Worker1_QueryProcessorQueue1) START DATA SRC COMMAND: startTime=2015-07-28 13:43:18.54 requestID=rfFDiTxhxLGL.0 sourceCommandID=0 executionID=0 txID=null modelName=Accounts translatorName=translator-h2 sessionID=rfFDiTxhxLGL principal=user@teiid-security sql=SELECT g_0.ID, g_0.SYMBOL, g_0.COMPANY_NAME FROM Accounts.PRODUCT AS g_0
> [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue2) END SRC COMMAND: endTime=2015-07-28 13:43:18.548 requestID=rfFDiTxhxLGL.0 sourceCommandID=0 executionID=0 txID=null modelName=Accounts translatorName=translator-h2 sessionID=rfFDiTxhxLGL principal=user@teiid-security finalRowCount=25
> {code}
> while the following appers only when the server is shut down (notice the time difference between this one and preceding ones):
> {code:plain}
> [org.teiid.COMMAND_LOG] (New I/O worker #64) CANCEL USER COMMAND: endTime=2015-07-28 13:43:29.152 requestID=rfFDiTxhxLGL.0 txID=null sessionID=rfFDiTxhxLGL principal=user@teiid-security vdbName=Portfolio vdbVersion=1 finalRowCount=null
> {code}
> If there is another command following, the previous command log entry is completed (but it can take even minutes):
> {code:plain}
> [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue3) END USER COMMAND: endTime=2015-07-28 14:18:59.511 requestID=q97k+Z4gwV64.0 txID=null sessionID=q97k+Z4gwV64 principal=user@teiid-security vdbName=Portfolio vdbVersion=1 finalRowCount=25
> {code}
> Also the ending log entry of one command and opening entry of another appear in any order.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (TEIID-3422) Setting more than 513MB for buffer-service-max-storage-object-size, OOME occurs at org.teiid.common.buffer.impl.BufferFrontedFileStoreCache.initialize()
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3422?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-3422.
---------------------------------
> Setting more than 513MB for buffer-service-max-storage-object-size, OOME occurs at org.teiid.common.buffer.impl.BufferFrontedFileStoreCache.initialize()
> --------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-3422
> URL: https://issues.jboss.org/browse/TEIID-3422
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.7
> Environment: JBoss DV 6.0, 6.1
> Reporter: hisao furuichi
> Assignee: Steven Hawkins
> Fix For: 8.7.1.6_2, 8.11
>
>
> Setting more than 513MB for buffer-service-max-storage-object-size, OOME occurs at org.teiid.common.buffer.impl.BufferFrontedFileStoreCache.initialize().
> One of our user needs to set more than 512MB for buffer-service-max-storage-object-size to avoid TEIID30001[1], this limitation becomes a critical issue for them.
> Additional Information:
> By taking look at the source code[2], if the value of maxStorageObjectSize is more than equals with 536870912, the loop becomes infinit, and will cause OOME.
> [1]
> TEIID30001 Max block number exceeded by 233,144 21,422,155. Increase the maxStorageObjectSize to support larger storage objects. Alternatively you could make the processor batch size smaller.
> [2]teiid/engine/src/main/java/org/teiid/common/buffer/impl/BufferFrontedFileStoreCache.java
> ===
> public static final long MAX_ADDRESSABLE_MEMORY = 1l<<(ADDRESS_BITS+LOG_BLOCK_SIZE);
> ~~
> static final int BLOCK_SIZE = 1 << LOG_BLOCK_SIZE;
> ~~
> public void initialize() throws TeiidComponentException {
> ~~
> List<BlockStore> stores = new ArrayList<BlockStore>();
> int size = BLOCK_SIZE;
> int files = 32; //this allows us to have 64 terabytes of smaller block sizes
> do {
> stores.add(new BlockStore(this.storageManager, size, 30, files));
> size <<=1;
> if (files > 1) {
> files >>= 1;
> }
> } while ((size>>1) < maxStorageObjectSize);
> ~~
> ===
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (TEIID-3597) OData PUT call returns "NotFoundException"
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3597?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-3597.
---------------------------------
> OData PUT call returns "NotFoundException"
> ------------------------------------------
>
> Key: TEIID-3597
> URL: https://issues.jboss.org/browse/TEIID-3597
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Affects Versions: 8.7.1, 8.11
> Reporter: Debbie Steigner
> Assignee: Ramesh Reddy
> Attachments: CompleteSubvdb.vdb
>
>
> Unable to PUT via Odata , I am able to GET and POST and JDBC Select, Insert and update on the same table so the transformations are correct:
> {code}
> $ curl -H 'Content-Type: application/json' \
> -X PUT http://127.0.0.1:8080/odata/CompleteSubVDB/V1.patch_SUBMISSION \
> -d '{"SUBMISSION_ID": "15232", "AUTHOR_REV_ID":"3"}' -u teiidUser:datavirt_61
> {code}
> <?xml version='1.0' encoding='utf-8'?><error xmlns="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"><code>NotFoundException</code><message lang="en-US">V1.patch_SUBMISSION</message></error>
> Full stacktrace from server.log:
> {code}
> 08:04:27,441 DEBUG [org.jboss.resteasy.core.SynchronousDispatcher] (http-/127.0.0.1:8080-1) PathInfo: /V1.patch_SUBMISSION
> 08:04:27,443 WARN [org.teiid.ODATA] (http-/127.0.0.1:8080-1) TEIID16012 Could not produce a successful OData response. Returning status NotFoundException with message V1.patch_SUBMISSION.: org.odata4j.exceptions.NotFoundException: V1.patch_SUBMISSION
> at org.odata4j.producer.resources.EntitiesRequestResource.functionCallPut(EntitiesRequestResource.java:192) [odata4j-core-0.8.0.redhat-2.jar:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:216) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at org.teiid.odata.ODataServletContainerDispatcher.service(ODataServletContainerDispatcher.java:118) [classes:]
> at org.teiid.odata.ODataServlet.service(ODataServlet.java:65) [classes:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:512) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.4.3.Final-redhat-2.jar:7.4.3.Final-redhat-2]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months