camel-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From acosent...@apache.org
Subject [camel] 08/20: CAMEL-13792 - Rename components to default names, Camel-netty4 to camel-netty - Fixed refs in camel-mllp
Date Wed, 07 Aug 2019 13:10:40 GMT
This is an automated email from the ASF dual-hosted git repository.

acosentino pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/camel.git

commit db3237042b4d15913fd41b5272b22cceb21e2da2
Author: Andrea Cosentino <ancosen@gmail.com>
AuthorDate: Wed Aug 7 12:58:11 2019 +0200

    CAMEL-13792 - Rename components to default names, Camel-netty4 to camel-netty - Fixed
refs in camel-mllp
---
 components/camel-mllp/README.md | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/components/camel-mllp/README.md b/components/camel-mllp/README.md
index a35fdc4..e398040 100644
--- a/components/camel-mllp/README.md
+++ b/components/camel-mllp/README.md
@@ -52,23 +52,23 @@ eliminates the dependencies on other camel components.
 While Camel already includes some of this functionality in the camel-hl7 component, the implementation
does not
 provide all of the functionality required to effectively handle the MLLP protocol - especially
under adverse conditions.
   
-The camel-hl7 Mina2 codec and Netty4 decoder do not handle MLLP Framing errors very well
- the component will hang waiting
+The camel-hl7 Mina2 codec and Netty decoder do not handle MLLP Framing errors very well -
the component will hang waiting
 for frames to complete in some instances.
 
-While both camel-mina and camel-netty4 provide a "timeout" function, it is only applied to
Producers.  MLLP Consumers
+While both camel-mina and camel-netty provide a "timeout" function, it is only applied to
Producers.  MLLP Consumers
 also need to be able to timeout to recover from MLLP framing errors.  Additionally, the timeout
functionality of the
-camel-netty4 component is disable after any data is received on the connection, making in
ineffective for detecting
+camel-netty component is disable after any data is received on the connection, making in
ineffective for detecting
 timeouts after the first messages is received.
 
-Also, neither the Mina2 codec nor the Netty4 decoder interrogate HL7 Acknowledgments.  Therefore,
it is much more
+Also, neither the Mina2 codec nor the Netty decoder interrogate HL7 Acknowledgments.  Therefore,
it is much more
 difficult to use the redelivery and error handling features Camel provides.
 
 The above issues may be addressable by updating/patching the existing components, but there
is one more that is not.
-Both camel-netty4 and camel-mina are designed to handle a large number of concurrent connections,
rapid connect/disconnect
+Both camel-netty and camel-mina are designed to handle a large number of concurrent connections,
rapid connect/disconnect
 rates, and asynchronous communication.  Forcing, these components to deal with the small
number of stateful connections
 inherent to the MLLP protocol seems inappropriate.
 
-An attempt was made to update the camel-netty4 decoder provided by the camel-hl7 component
to deal with the nuances of 
+An attempt was made to update the camel-netty decoder provided by the camel-hl7 component
to deal with the nuances of 
 the MLLP protocol, but it quickly became very complicated.  The decoder was updated to correctly
deal with the MLLP 
 frame.  The current implementation is based on the Netty DelimiterBasedFrameDecoder, but
this decoder only looks for a 
 single byte terminator and MLLP uses two bytes to terminate it's frame.  Additionally, the
second terminating byte of the


Mime
View raw message