Details
-
Type:
New Feature
-
Status:
Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: 2.0.0-M1
-
Fix Version/s: 2.0.0-M1
-
Component/s: Transport: TCP / UDP / SSL / Multicast
-
Labels:None
-
Environment:
Windows 2000 SP4, Java JDK 1.4.2_10, Mule development snapshot
-
Similar Issues:
MULE-1242Non-materializing streaming receiver for TCPMULE-1490Mina based TCP transportMULE-2396Rewrite the VMMessageReceiver to not extend PollingMessageReceiverMULE-1678Streaming Model Re-Dispatching Empty StreamsMULE-103Tcp provider not handling large messagesMULE-525TCP protocol to divide streaming data into xml messages using xml declarationMULE-1502Unify SSL and TCP ArchitectureMULE-2152TCP message receiver sending data back even if it is not suppose to
MULE-2448 Streaming Model Should set TCP Protocol?MULE-248Tcp Provider not handling large messages
Description
TcpStreamingMessageReceiver establishes a tcp client connection to an external server and reads the streaming data. No polling frequency is used since with blocking i/o reads will block, and with non-blocking i/o reads will occur when data is available. Causing delays between read attempts is unnecessary, so this forces the pollingFrequency property to zero so no pause occurs in the PollingMessageReceiver class. This class should be combined with XmlMessageProtocol or LengthProtocol in the config file to properly break up the stream into messages.
Attached my implementation. Sorry no test case