I do not think the TeiidDataSource is correctly wired for to be used with "embedded" server. In 8.6, Teiid is implementing support for the remote jdbc/odbc connections [TEIID-2439] jdbc socket transport support in teiid embedded mode, that can also be used for in VM solutions like "embeddable" servers.
I think we could also add a feature for TeiidDataSource, without above feature.
> I think we could also add a feature for TeiidDataSource, without above feature.
The rationale for not exposing a DataSource for embedded is that it in nearly all uses you simply want Teiid to enlist itself with the thread bound connection, which the embedded logic can automatically do for you.
As I understand it you are just looking for a way to provide a representative reproduction of your issue. However the only difference between using a DataSource and a Driver connection from the perspective of Teiid from the server side will be the transaction handling. Even then, the processing model under a local transaction vs. an XA transaction is effectively the same. It's just coordinated a little differently. Is your DataSource scenario running under a transaction? Is it a normal source (for example it returns a terminating result set)? Can you provide a detail/trace log highlighting that a final response is not being sent to the client? Are you doing anything unusual on the client side?
One is a File datasource and other one doesn't connect to any data source.
I am not doing any un-usual thing on the client. Just created a connection, statement and executed the SQL.
Yes, it is a terminating result set.
Attached is the Logs and Query Plan.
Can someone please suggest me how to solve this issue?
No need for a bump posting. This is not being ignored. From what I see the cancellation exception is not gracefully handled - but in my tests does not cause any bad behavior on the client. At worst it will deliver the exception (as indicated in the log you attached) and if the final results have already been delivered it will instead just get logged. So I haven't reproduced what you are describing.
Where are you running your client from? Can you produce a log and ideally a thread dump from the client side?
I will clean up the future cancellation so that no error is logged, but it does seem the root of the issue stems from:
30 Sep 2013 21:48:45,414 IST DEBUG [org.teiid.TRANSPORT] (New I/O worker #1) null Unhandled exception, closing client instance: java.io.IOException: An existing connection was forcibly closed by the remote host
at sun.nio.ch.SocketDispatcher.read0(Native Method) [rt.jar:1.7.0_03]
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:43) [rt.jar:1.7.0_03]
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:218) [rt.jar:1.7.0_03]
at sun.nio.ch.IOUtil.read(IOUtil.java:186) [rt.jar:1.7.0_03]
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:359) [rt.jar:1.7.0_03]
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:64) [netty-3.6.2.Final.jar:]
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:107) [netty-3.6.2.Final.jar:]
at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312) [netty-3.6.2.Final.jar:]
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:88) [netty-3.6.2.Final.jar:]
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) [netty-3.6.2.Final.jar:]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_03]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_03]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_03]
Which is that the server sees the client as disconnecting. The cancellation exception is really just a follow-on as we cleanup that does not interact well with the caching tuple source. Can you rerun at a trace level? Otherwise it certainly looks like more information is needed from the client side.
The cancellation exception is because I cancelled the request from the client as I see looping condition in the logs realted to the Blocking of the request waiting for the source query.
I am running the client using a junit test case. The logs are attached to the previous post.
> The cancellation exception is because I cancelled the request from the client as I see looping condition in the logs realted to the Blocking of the request waiting for the source query.
I'm not sure what you mean by a looping condition. Blocking on a source response is typical. Is there something there that doesn't meet your expectations?
Also you indicated that these were normal sources, but the log also shows:
30 Sep 2013 21:48:32,507 IST DEBUG [org.teiid.BUFFER_MGR] (Worker8_QueryProcessorQueue269) DSF9zLgD7ISB DSF9zLgD7ISB.0.1.661 Blocking on DataNotAvailableException DSF9zLgD7ISB.0.1.661
Meaning that you'll have to provide more information about the nature of the source, the duration of the DataNotAvailableException, etc.
> The logs are attached to the previous post.
That is the server log, not a client log - however if you are the one disconnecting and client Connection, then there probably isn't anything of note from the client side.
>>I'm not sure what you mean by a looping condition. Blocking on a source response is typical. Is there something there that doesn't meet your expectations?
I was thinking that because of this blocking, the response is not being sent to the client.
>>That is the server log, not a client log - however if you are the one disconnecting and client Connection, then there probably isn't anything of note from the client side.
Yes, I am disconnecting the client connection.
I will get you the logs from the server.log. with only the request for the particular SQL.
> I was thinking that because of this blocking, the response is not being sent to the client.
No blocking almost always occurs with any forked source request.
> I will get you the logs from the server.log. with only the request for the particular SQL.
I'm not sure what that will show beyond what you have already provided. What you need to do is determine why your source is throwing a datanotavailable exception and what that means for how results will be available. If you for example use a loopback for that source or do not throw a datanotavailable exception, do you get results back as you expect? If so then you should narrow in on what you are telling the engine with that exception.