Fix some typos in the whats-new.adoc & ip.adoc

This commit is contained in:
Artem Bilan
2019-05-13 16:27:02 -04:00
parent b976ce2240
commit e05b6f75f4
2 changed files with 20 additions and 27 deletions

View File

@@ -197,7 +197,7 @@ The following example shows how to configure a basic multicast inbound udp chann
----
====
By default, reverse DNS lookups are done on inbound packets to convert IP addresses to hostnames for use in message headers.
By default, reverse DNS lookups are done on inbound packets to convert IP addresses to host names for use in message headers.
In environments where DNS is not configured, this can cause delays.
You can override this default behavior by setting the `lookup-host` attribute to `false`.
@@ -233,8 +233,7 @@ public IntegrationFlow udpIn() {
Starting with version 5.0.2, a `UdpServerListeningEvent` is emitted when an inbound adapter is started and has begun listening.
This is useful when the adapter is configured to listen on port 0, meaning that the operating system chooses the port.
It can also be used instead of polling `isListening()`, if you need to wait before starting some other process that will
connect to the socket.
It can also be used instead of polling `isListening()`, if you need to wait before starting some other process that will connect to the socket.
==== Advanced Outbound Configuration
@@ -427,8 +426,7 @@ The default maximum message size is 2048 bytes.
You can increase it by setting the `maxMessageSize` property.
If you use the default serializer or deserializer and wish to increase the maximum message size, you must declare the maximum message size as an explicit bean with the `maxMessageSize` property set and configure the connection factory to use that bean.
The classes marked with ^*^ earlier in this section use an intermediate buffer and copy the decoded data to a final buffer of the correct
size.
The classes marked with ^*^ earlier in this section use an intermediate buffer and copy the decoded data to a final buffer of the correct size.
Starting with version 4.3, you can configure these buffers by setting a `poolSize` property to let these raw buffers be reused instead of being allocated and discarded for each message, which is the default behavior.
Setting the property to a negative value creates a pool that has no bounds.
If the pool is bounded, you can also set the `poolWaitTimeout` property (in milliseconds), after which an exception is thrown if no buffer becomes available.
@@ -480,12 +478,12 @@ A server connection factory that uses `java.net.Socket` connections and uses Jav
For full details of the attributes available on connection factories, see <<ip-annotation,the reference>> at the end of this section.
By default, reverse DNS lookups are done on inbound packets to convert IP addresses to hostnames for use in message headers.
By default, reverse DNS lookups are done on inbound packets to convert IP addresses to host names for use in message headers.
In environments where DNS is not configured, this can cause connection delays.
You can override this default behavior by setting the `lookup-host` attribute to `false`.
NOTE: You can also modify the attributes of sockets and socket factories.
See <<ssl-tls>>.
See <<ssl-tls>> for more information.
As noted there, such modifications are possible whether or not SSL is being used.
==== Custom Serializers and Deserializers
@@ -650,9 +648,7 @@ Applications can use a normal `ApplicationListener` or an `ApplicationEventListe
Starting with versions 4.0.7 and 4.1.3, `TcpConnectionServerExceptionEvent` instances are published whenever an unexpected exception occurs on a server socket (such as a `BindException` when the server socket is in use).
These events have a reference to the connection factory and the cause.
Starting with version 4.2, `TcpConnectionFailedCorrelationEvent` instances are published whenever an endpoint (inbound gateway or
collaborating outbound channel adapter) receives a message that cannot be routed to a connection because the
`ip_connectionId` header is invalid.
Starting with version 4.2, `TcpConnectionFailedCorrelationEvent` instances are published whenever an endpoint (inbound gateway or collaborating outbound channel adapter) receives a message that cannot be routed to a connection because the `ip_connectionId` header is invalid.
Outbound gateways also publish this event when a late reply is received (the sender thread has timed out).
The event contains the connection ID as well as an exception in the `cause` property, which contains the failed message.
@@ -740,15 +736,15 @@ In this case, the connection factory must be of type `client` and must have `sin
Two additional attributes support this mechanism.
The `retry-interval` specifies (in milliseconds) how often the framework attempts to reconnect after a connection failure.
`scheduler` supplies a `TaskScheduler` to schedule the connection attempts and to test that the connection is still active.
The `scheduler` supplies a `TaskScheduler` to schedule the connection attempts and to test that the connection is still active.
If you don't provide a scheduler, the framework's default <<namespace-taskscheduler, taskScheduler>> bean is used.
For an outbound adapter, the connection is normally established when the first message is sent.
`client-mode="true"` on an outbound adapter causes the connection to be established when the adapter is started.
The `client-mode="true"` on an outbound adapter causes the connection to be established when the adapter is started.
By default, adapters are automatically started.
Again, the connection factory must be of type `client` and have `single-use="false"`.
`retry-interval` and `scheduler` are also supported.
A `retry-interval` and `scheduler` are also supported.
If a connection fails, it is re-established either by the scheduler or when the next message is sent.
For both inbound and outbound, if the adapter is started, you can force the adapter to establish a connection by sending a `<control-bus />` command: `@adapter_id.retryConnection()`.
@@ -952,11 +948,11 @@ A message sent with the preceding configuration, with a payload of 'something' w
----
====
[[note_nio]]
[[note-nio]]
=== About Non-blocking I/O (NIO)
Using NIO (see `using-nio` in <<ip-endpoint-reference>>) avoids dedicating a thread to read from each socket.
For a small number of sockets, you are likely to find that not using NIO, together with an asynchronous handoff (such as to a `QueueChannel`), performs as well as or better than using NIO.
For a small number of sockets, you are likely to find that not using NIO, together with an asynchronous hand-off (such as to a `QueueChannel`), performs as well as or better than using NIO.
You should consider using NIO when handling a large number of connections.
However, the use of NIO has some other ramifications.
@@ -968,7 +964,7 @@ Strict ordering of the messages arriving on the socket is not maintained.
For some applications, this is not an issue.
For others, it is a problem.
If you require strict ordering, consider setting `using-nio` to `false` and using an asynchronous handoff.
If you require strict ordering, consider setting `using-nio` to `false` and using an asynchronous hand-off.
Alternatively, you can insert a resequencer downstream of the inbound endpoint to return the messages to their proper sequence.
If you set `apply-sequence` to `true` on the connection factory, messages arriving on a TCP connection have `sequenceNumber` and `correlationId` headers set.
@@ -1113,7 +1109,7 @@ The default implementations of these interfaces provide for the simplest way to
Regardless of whether you use NIO, you need to configure the `ssl-context-support` attribute on the connection factory.
This attribute references a <bean/> definition that describes the location and passwords for the required key stores.
SSL/TLS peers require two keystores each:
SSL/TLS peers require two key stores each:
* A keystore that contains private and public key pairs to identify the peer
* A truststore that contains the public keys for peers that are trusted.
@@ -1150,7 +1146,7 @@ The following example configures an SSL connection:
----
====
The `DefaulTcpSSLContextSupport` class also has an optional `protocol` property, which can be `SSL` or `TLS` (the default).
The `DefaultTcpSSLContextSupport` class also has an optional `protocol` property, which can be `SSL` or `TLS` (the default).
The keystore file names (the first two constructor arguments) use the Spring `Resource` abstraction.
By default, the files are located on the classpath, but you can override this by using the `file:` prefix (to find the files on the filesystem instead).
@@ -1304,7 +1300,7 @@ public interface TcpNetConnectionSupport {
====
This interface is invoked to create objects of type `TcpNetConnection` (or its subclasses).
The framework provides a single implementation (`DefatulTcpNetConnectionSupport`), which, by default, creates simple `TcpNetConnection` objects.
The framework provides a single implementation (`DefaultTcpNetConnectionSupport`), which, by default, creates simple `TcpNetConnection` objects.
It has two properties: `pushbackCapable` and `pushbackBufferSize`.
When push back is enabled, the implementation returns a subclass that wraps the connection's `InputStream` in a `PushbackInputStream`.
Aligned with the `PushbackInputStream` default, the buffer size defaults to 1.
@@ -1778,8 +1774,7 @@ One thread is dedicated to handling acknowledgments (if the `acknowledge` option
| `destination-expression`
| SpEL expression
| A SpEL expression to be evaluated to determine which `SocketAddress` to use as a destination address for the
outgoing UDP packets.
| A SpEL expression to be evaluated to determine which `SocketAddress` to use as a destination address for the outgoing UDP packets.
| `socket-expression`
| SpEL expression
@@ -2023,18 +2018,16 @@ Described after this table.
Note that, unlike the other header constants, this constant is in the `MessageHeaders` class, not the `IpHeaders` class.
|===
For inbound messages, `ip_hostname`, `ip_address`, `ip_tcp_remotePort`, and `ip_connectionId` are mapped by the default
`TcpHeaderMapper`.
For inbound messages, `ip_hostname`, `ip_address`, `ip_tcp_remotePort`, and `ip_connectionId` are mapped by the default `TcpHeaderMapper`.
If you set the mapper's `addContentTypeHeader` property to `true`, the mapper sets the `contentType` header (`application/octet-stream;charset="UTF-8"`, by default).
You can change the default by setting the `contentType` property.
You can add additional headers by subclassing `TcpHeaderMapper` and overriding the `supplyCustomHeaders` method.
For example, when you use SSL, you can add properties of the `SSLSession` by obtaining the session object from the
`TcpConnection` object, which is provided as an argument to the `supplyCustomHeaders` method.
For example, when you use SSL, you can add properties of the `SSLSession` by obtaining the session object from the `TcpConnection` object, which is provided as an argument to the `supplyCustomHeaders` method.
For outbound messages, `String` payloads are converted to `byte[]` with the default (`UTF-8`) charset.
Set the `charset` property to change the default.
When customizing the mapper properties or subclassing, declare the mapper as a bean and provide an instance to the connection factory by using the `mapper` property
When customizing the mapper properties or subclassing, declare the mapper as a bean and provide an instance to the connection factory by using the `mapper` property.
[[ip-annotation]]
=== Annotation-Based Configuration

View File

@@ -31,7 +31,7 @@ See <<scripting>> for more information.
The `JsonToObjectTransformer` now supports generics for the target object to deserialize into.
See <<json-transformers>> for more information.
RThe `splitter` now supports a `discardChannel` configuration option.
The `splitter` now supports a `discardChannel` configuration option.
See <<splitter>> for more information.
[[x5.2-amqp]]