[JBoss JIRA] (TEIID-2835) After switch to use io.netty, getting exception in TestJDBCSocketTransport
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2835?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2835:
---------------------------------------
Is this reproducible for you?
> After switch to use io.netty, getting exception in TestJDBCSocketTransport
> --------------------------------------------------------------------------
>
> Key: TEIID-2835
> URL: https://issues.jboss.org/browse/TEIID-2835
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.7
> Environment: Running build on mac
> Reporter: Van Halbert
> Assignee: Steven Hawkins
>
> When building off of master (which I see there's been a change to io.netty), I get the following error:
> Running org.teiid.transport.TestJDBCSocketTransport
> Feb 3, 2014 2:51:12 PM org.teiid.logging.JavaLogger log
> SEVERE: TEIID40113 Unhandled exception, aborting operation
> org.jboss.netty.handler.codec.frame.TooLongFrameException: Adjusted frame length exceeds 100000: 100293 - discarded
> at org.jboss.netty.handler.codec.frame.LengthFieldBasedFrameDecoder.fail(LengthFieldBasedFrameDecoder.java:417)
> at org.jboss.netty.handler.codec.frame.LengthFieldBasedFrameDecoder.failIfNecessary(LengthFieldBasedFrameDecoder.java:405)
> at org.jboss.netty.handler.codec.frame.LengthFieldBasedFrameDecoder.decode(LengthFieldBasedFrameDecoder.java:320)
> at org.teiid.transport.ObjectDecoder.decode(ObjectDecoder.java:108)
> at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:425)
> at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:303)
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
> at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88)
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:107)
> at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312)
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:88)
> at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
> 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:695)
> I made a change to SSLAwareChannelHandler to increase the estimated decoder size to Integer.MAX_VALUE and the problem was gone. Here's the difference in size estimates based on what the default was using and the MAX_VALUE I tested with:
> =========== DEFAULT ===========2097152
> =========== Int Max ===========2147483647
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (TEIID-2840) More control over TTL Snapshot Refresh
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2840?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-2840:
----------------------------------
Summary: More control over TTL Snapshot Refresh (was: TTL Snapshot Refresh may need to be a blocking load)
Issue Type: Enhancement (was: Feature Request)
Fix Version/s: 8.7
Description: The ttl load to may need to be changed to a blocking load or some configuration options provided to prevent stale reads after a certain time limit. (was: An asynch load may happen under a current request and when that request/session is closed, then the asynch load is killed.
The ttl load to may need to be changed to a blocking load or some configuration options provided.)
> More control over TTL Snapshot Refresh
> ---------------------------------------
>
> Key: TEIID-2840
> URL: https://issues.jboss.org/browse/TEIID-2840
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Affects Versions: 7.7.8
> Reporter: Johnathon Lee
> Assignee: Steven Hawkins
> Fix For: 8.7
>
>
> The ttl load to may need to be changed to a blocking load or some configuration options provided to prevent stale reads after a certain time limit.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (TEIID-1035) Replace Existing XML Document Functionality with other JBoss Technologies
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-1035?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-1035:
----------------------------------
Fix Version/s: (was: 9.0)
> Replace Existing XML Document Functionality with other JBoss Technologies
> -------------------------------------------------------------------------
>
> Key: TEIID-1035
> URL: https://issues.jboss.org/browse/TEIID-1035
> Project: Teiid
> Issue Type: Task
> Affects Versions: 7.0
> Reporter: Ted Jones
> Assignee: Steven Hawkins
>
> The current XML Document homegrown technologies in the Teiid Designer with existing JBoss technologies. The following use cases should be satisfied:
> 1. Start with an XML Schema to build a Document that can be filled with relational, heterogeneous data and "shipped around"
> 2. Given an XML document/message definition, submit a query on the document with criteria defined within the document structure
> 3. Send an input document, produce and output document
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month