[JBoss JIRA] Created: (TEIID-741) SQL Server type hadling issues
by Steven Hawkins (JIRA)
SQL Server type hadling issues
------------------------------
Key: TEIID-741
URL: https://jira.jboss.org/jira/browse/TEIID-741
Project: Teiid
Issue Type: Bug
Components: JDBC Connector
Affects Versions: 6.0.0
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 6.2.0
If we pushdown a convert(stringvalue, char) function, it turns into the source expression convert(char, stringvalue), which has the following problems: it defaults to type char(30) which is right padded, it is not trimmed since the target type was Char and the trim logic looks only for String. Also it does not account for empty string mapping to null.
The SQL Server tinyint type is unsigned. Our import needs to be modified to this to short, since our byte type is unsigned. Pushing down a convert(numericvalue, byte) as convert(tinyint, numericvalue) is problematic if the byte values are stored in a signed manner.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 6 months
[JBoss JIRA] Created: (TEIID-876) Server Times Out Session Despite Configuration
by Nestor D. Rodriguez (JIRA)
Server Times Out Session Despite Configuration
----------------------------------------------
Key: TEIID-876
URL: https://jira.jboss.org/jira/browse/TEIID-876
Project: Teiid
Issue Type: Bug
Components: Server
Affects Versions: 6.2.0
Environment: Solaris 10
Reporter: Nestor D. Rodriguez
Assignee: Steven Hawkins
I have a Teiid server set up on a Solaris 10 machine. The deploy.properties file has the session.expirationTimeInMilli property commented out to avoid any sessions timing out.
Nevertheless, when connecting to the server using the adminshell tool, I inevitable get the following error in the tool after five or so minutes:
Exception in thread "SocketPing" java.net.SocketException: Socket closedjava.net.SocketException: Socket closedjava.net.SocketException: Socket closedSocket closed
at com.metamatrix.client.ExceptionUtil.convertException(ExceptionUtil.java: 75)
at com.metamatrix.common.comm.platform.socket.client.SocketServerInstanceImpl$RemoteInvocationHandler.invoke(SocketServerInstanceImpl.java:342)
at $Proxy0.logoff(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.metamatrix.common.comm.platform.socket.client.SocketServerConnection$ServerConnectionInvocationHandler.invoke(SocketServerConnection.java:218)
at $Proxy0.logoff(Unknown Source)
at com.metamatrix.common.comm.platform.socket.client.SocketServerConnection.shutdown(SocketServerConnection.java:258)
at com.metamatrix.common.comm.platform.socket.client.SocketServerConnection.shutdown(SocketServerConnection.java:248)
at com.metamatrix.common.comm.platform.socket.client.SocketServerConnection$1.run(SocketServerConnection.java:113)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
Caused by: com.metamatrix.common.comm.exception.SingleInstanceCommunicationException: java.net.SocketException: Socket closed
at com.metamatrix.common.comm.platform.socket.client.SocketServerInstanceImpl.send(SocketServerInstanceImpl.java:179)
at com.metamatrix.common.comm.platform.socket.client.SocketServerInstanceImpl$RemoteInvocationHandler.invoke(SocketServerInstanceImpl.java:330)
... 12 more
Caused by: java.util.concurrent.ExecutionException: java.net.SocketException: Socket closed
at com.metamatrix.dqp.client.ResultsFuture.convertResult(ResultsFuture.java:94)
at com.metamatrix.dqp.client.ResultsFuture.get(ResultsFuture.java:89)
at com.metamatrix.common.comm.platform.socket.client.SocketServerInstanceImpl.send(SocketServerInstanceImpl.java:176)
... 13 more
Caused by: java.net.SocketException: Socket closed
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:99)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
at java.io.DataOutputStream.flush(DataOutputStream.java:106)
at org.teiid.netty.handler.codec.serialization.ObjectEncoderOutputStream.flush(ObjectEncoderOutputStream.java:71)
at com.metamatrix.common.comm.platform.socket.client.OioOjbectChannelFactory$OioObjectChannel.write(OioOjbectChannelFactory.java:142)
at com.metamatrix.common.comm.platform.socket.client.SocketServerInstanceImpl.send(SocketServerInstanceImpl.java:175)
... 13 more
Once this happens, the connection is closed and any attempt to re-connect gives me the message "Failed to connect: (Timer already connected.)"
I don't know if it's relevant, but I've also noted that when I run my test JDBC query program, I get my results back, but this message shows up in the teiid.log file:
java.io.IOException: Connection reset by peer
at sun.nio.ch.FileDispatcher.read0(Natve Method)
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:21)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:233)
at sun.nio.ch.IOUtil.read(IOUtil.java:206)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:236)
at org.jboss.netty.buffer.HeapChannelBuffer.setBytes(HeapChannelBuffer.java:163)
at org.jboss.netty.buffer.AbstractChannelBuffer.writeBytes(AbstractChannelBuffer.java:429)
at org.jboss.netty.channel.socket.nio.NioWorker.readIntoHeapBuffer(NioWorker.java:282)
at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:254)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:163)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 6 months
[JBoss JIRA] Updated: (TEIID-7) Control of BigDecimal precision and scale
by Steve Hawkins (JIRA)
[ https://jira.jboss.org/browse/TEIID-7?page=com.atlassian.jira.plugin.syst... ]
Steve Hawkins updated TEIID-7:
------------------------------
Fix Version/s: 8.0
(was: 7.1)
> Control of BigDecimal precision and scale
> -----------------------------------------
>
> Key: TEIID-7
> URL: https://jira.jboss.org/browse/TEIID-7
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.x
> Reporter: Jerry Helbling
> Priority: Minor
> Fix For: 8.0
>
>
> Problem 1: The parser defaults to parsing literals that look like bigdecimal as doubles, which have no scale.
> Workaround (which is on devcentral): You can avoid the above conversions by wrapping the values in a convert in the query (example: "convert('123.00', BigDecimal )").
> A better fix is update the parser to look for loss of scale information and to use the bigdecimal type instead.
> Problem 2: default division behavior JBEDSP-305
> Problem 3: No explicit control via the parser
> It would be good to provide explicit precision and scale via "convert(xxx, BigDecimal(10, 2))" - side note bigdecimal is a bad name for this type. it should really just be decimal
> Reference: This is related to Issue Tracker Issue 175485.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 6 months
[JBoss JIRA] Resolved: (TEIID-954) Need method to control max amount of buffer disk space
by Steve Hawkins (JIRA)
[ https://jira.jboss.org/browse/TEIID-954?page=com.atlassian.jira.plugin.sy... ]
Steve Hawkins resolved TEIID-954.
---------------------------------
Resolution: Done
See bufferserviceimpl get/setMaxBufferSpace to control the amount of space. See getBatchesAdded, getReadCount, getWriteCount, getReadAttempts to metrics on batches.
> Need method to control max amount of buffer disk space
> ------------------------------------------------------
>
> Key: TEIID-954
> URL: https://jira.jboss.org/browse/TEIID-954
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Affects Versions: 6.0.0
> Reporter: Steven Hawkins
> Fix For: 7.1
>
>
> There needs to be a configurable limit to how much disk space buffer manager is able to use.
> Currently, you can specify the limit per file and the limit of how many files buffer manager can have open at one time, but there is no means of keeping buffer manager for eating up all the available disk space and then resulting in unpredictable behavior and stability.
> It's fine if queries that need the file buffer manager but find it is full fail outright when it is full.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 6 months
[JBoss JIRA] Updated: (TEIID-954) Need method to control max amount of buffer disk space
by Steve Hawkins (JIRA)
[ https://jira.jboss.org/browse/TEIID-954?page=com.atlassian.jira.plugin.sy... ]
Steve Hawkins updated TEIID-954:
--------------------------------
Summary: Need method to control max amount of buffer disk space (was: Need method to controll max amount of bufer disk space)
Complexity: Low
Affects: [Documentation (Ref Guide, User Guide, etc.), Compatibility/Configuration, Release Notes]
> Need method to control max amount of buffer disk space
> ------------------------------------------------------
>
> Key: TEIID-954
> URL: https://jira.jboss.org/browse/TEIID-954
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Affects Versions: 6.0.0
> Reporter: Steven Hawkins
> Fix For: 7.1
>
>
> There needs to be a configurable limit to how much disk space buffer manager is able to use.
> Currently, you can specify the limit per file and the limit of how many files buffer manager can have open at one time, but there is no means of keeping buffer manager for eating up all the available disk space and then resulting in unpredictable behavior and stability.
> It's fine if queries that need the file buffer manager but find it is full fail outright when it is full.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 6 months