[JBoss JIRA] (TEIID-3435) IllegalStateException closing connection
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3435?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-3435.
---------------------------------
> IllegalStateException closing connection
> ----------------------------------------
>
> Key: TEIID-3435
> URL: https://issues.jboss.org/browse/TEIID-3435
> Project: Teiid
> Issue Type: Quality Risk
> Affects Versions: 8.7
> Reporter: Ramesh Reddy
…
[View More]> Assignee: Steven Hawkins
>
> Another thing from the log are what appear to be exceptions related to close calls:
> {code}
> 10:30:27,074 INFO
> [org.jboss.jca.core.connectionmanager.listener.TxConnectionListener]
> (http-localhost/127.0.0.1:8080-1) IJ000311: Throwable from unregister
> connection: java.lang.IllegalStateException: Trying to return an unknown connection2! org.jboss.jca.adapters.jdbc.jdk6.WrappedConnectionJDK6@b036577
> at
> org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl.unregisterConnection(CachedConnectionManagerImpl.java:347)
> at
> org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.connectionClosed(TxConnectionListener.java:371)
> at
> org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.closeHandle(BaseWrapperManagedConnection.java:574)
> at
> org.jboss.jca.adapters.jdbc.WrappedConnection.close(WrappedConnection.java:265)
> at
> org.teiid.translator.jdbc.JDBCExecutionFactory.closeConnection(JDBCExecutionFactory.java:287)
> at
> org.teiid.translator.jdbc.JDBCExecutionFactory.closeConnection(JDBCExecutionFactory.java:51)
> at
> org.teiid.dqp.internal.datamgr.ConnectorWorkItem.close(ConnectorWorkItem.java:226)
> [teiid-engine-8.4.2-redhat-1.jar:8.4.2-redhat-1]
> {code}
>
> It looks like it's only happening for the XML subplans. We explicitly prevent close from being called multiple times on connector work item.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
[View Less]
8 years, 7 months
[JBoss JIRA] (TEIID-2762) Can't deploy or execute VDB by JBDS with setting useDisk property to false
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2762?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-2762.
---------------------------------
> Can't deploy or execute VDB by JBDS with setting useDisk property to false
> --------------------------------------------------------------------------
>
> Key: TEIID-2762
> URL: https://issues.jboss.org/browse/TEIID-2762
> Project: Teiid
> Issue Type: Bug
> …
[View More]Components: Server
> Affects Versions: 7.7.8
> Reporter: Van Halbert
> Assignee: Steven Hawkins
> Fix For: 9.0
>
>
> Description of problem:
> Can't deploy or execute VDB by JBDS with setting useDisk property to false.
> Version-Release number of selected component (if applicable):
> EDS 5.3.1
> Steps to Reproduce:
> 1. Set following property to false;
> $JBOSS_HOME/server/default/deploy/teiid/teiid-jboss-beans.xml
> ~~
> <bean name="BufferService" class="org.teiid.services.BufferServiceImpl">
> <!-- Use disk for buffer management -->
> <property name="useDisk">true</property>
> ~~
> 2. Deploy or execute VDB whose size is 2.38MB by JBDS
> Actual results:
> Following ERROR was thrown by teiid server.
> 2013-12-04 16:14:45,800 ERROR [org.teiid.TRANSPORT] (New I/O server worker #2-1) Unhandled exception, closing client instance
> java.lang.IllegalArgumentException
> at java.nio.Buffer.limit(Buffer.java:247)
> at org.teiid.common.buffer.impl.MemoryStorageManager$MemoryFileStore.readWrite(MemoryStorageManager.java:74)
> at org.teiid.common.buffer.FileStore.write(FileStore.java:178)
> at org.teiid.common.buffer.FileStore.write(FileStore.java:171)
> at org.teiid.common.buffer.FileStore$2.write(FileStore.java:238)
> at java.io.BufferedOutputStream.write(BufferedOutputStream.java:105)
> at org.jboss.netty.buffer.HeapChannelBuffer.getBytes(HeapChannelBuffer.java:116)
> at org.jboss.netty.buffer.DynamicChannelBuffer.getBytes(DynamicChannelBuffer.java:156)
> at org.jboss.netty.buffer.AbstractChannelBuffer.readBytes(AbstractChannelBuffer.java:381)
> at org.teiid.transport.ObjectDecoder.decode(ObjectDecoder.java:158)
> at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:282)
> at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:214)
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:302)
> at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:317)
> at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:299)
> at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:214)
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:274)
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:261)
> at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:350)
> at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:281)
> at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:201)
> at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:46)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:662
> Expected results:
> Can deploy or execute VDB
> Additional info:
> Original buffer size used in org.teiid.common.buffer.impl.MemoryStorageManager was initialized by MAX_FILE_SIZE(131072bytes) at L47. However, readWrite() tried to allocate more size to the buffer at L74.
> org.teiid.common.buffer.impl.MemoryStorageManager.java
> ~~~
> public static final int MAX_FILE_SIZE = 1 << 17; // L44
> ~~~
> private ByteBuffer buffer = ByteBuffer.allocate(MAX_FILE_SIZE); // L47
> ~~~
> @Override
> protected synchronized int readWrite(long fileOffset, byte[] b, int offSet,
> int length, boolean write) {
> if (!write) {
> if (fileOffset >= getLength()) {
> return -1;
> }
> int position = (int)fileOffset;
> buffer.position(position);
> length = Math.min(length, (int)getLength() - position);
> buffer.get(b, offSet, length);
> return length;
> }
> int requiredLength = (int)(fileOffset + length);
> if (requiredLength > buffer.limit()) {
> buffer.limit(requiredLength); //L74
> }
> buffer.position((int)fileOffset);
> buffer.put(b, offSet, length);
> return length;
> ~~~
> According to JavaSE7's javadoc, it's not allowed to assign a larger limit size to the Buffer than it's capacity.
> http://docs.oracle.com/javase/7/docs/api/java/nio/Buffer.html
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
[View Less]
8 years, 7 months
[JBoss JIRA] (TEIID-3244) XML Choice is not being evaluated as expected
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3244?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-3244.
---------------------------------
> XML Choice is not being evaluated as expected
> ---------------------------------------------
>
> Key: TEIID-3244
> URL: https://issues.jboss.org/browse/TEIID-3244
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Reporter: Debbie …
[View More]Steigner
> Priority: Minor
>
> We have an XML View model, built on a schema that includes choice nodes. We've used the choice editor to define a default choice; however, no data comes back for any of these choices, despite the fact that data does exist.
> It appears that MMX is not executing the queries under the default choice nodes.
> As a second test, we tried setting criteria that would always be true. Still, the choice nodes were not executed.
> Finally, we tried setting criteria that would never be true, and told the choice editor to throw an exception if the criteria was not met. No exception was thrown. This seems to indicate that MMX simply isn't evaluating this part of the document.
> Finally, I have an theory about what could be the source of the problem, based on what I did differently during the rebuild. If you click on the "Subject" mapping class, notice that "choice" gets highlighted. In my rebuild, when I click on "Subject", the "category" gets highlighted, but the choice above it does not. The behavior is problematic in the first case, but works as expected in the second case.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
[View Less]
8 years, 7 months
[JBoss JIRA] (TEIID-3816) Informix translator - <> ALL is translated as NOT IN - this statement seem to not work in Infromix
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3816?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-3816.
---------------------------------
> Informix translator - <> ALL is translated as NOT IN - this statement seem to not work in Infromix
> --------------------------------------------------------------------------------------------------
>
> Key: TEIID-3816
> URL: https://issues.jboss.org/browse/TEIID-3816
> …
[View More]Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.7.2.6_2
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
>
> Query:
> {code:sql}
> SELECT INTKEY, BOOLEANVALUE FROM BQT1.SMALLA WHERE BOOLEANVALUE <> ALL (SELECT BOOLEANVALUE FROM BQT1.SMALLA WHERE INTKEY = 40)
> {code}
> Source-specific command:
> {code:sql}
> SELECT g_0.IntKey, g_0.BooleanValue FROM Source.SmallA AS g_0 WHERE g_0.BooleanValue NOT IN (SELECT g_1.BooleanValue FROM Source.SmallA AS g_1 WHERE g_1.IntKey = 40)
> {code}
> *Note: boolean value for row where Intkey = 40 is false.*
> Expected result:
> |intkey|booleanvalue|
> |1|true|
> |...|...|
> Actual result:
> |intkey|booleanvalue|
> |0|false|
> |...|...|
> This seems to be an Informix issue as neither '<> ALL' nor 'NOT IN' works.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
[View Less]
8 years, 7 months