[
https://issues.apache.org/jira/browse/OPENJPA-3072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18142731#comment-18142731
]
ASF subversion and git services commented on OPENJPA-3072:
----------------------------------------------------------
Commit 21dbd6c41ee77a0d566639ec2af0a6d3b1d80f3d in openjpa's branch
refs/heads/master from Richard Zowalla
[ https://gitbox.apache.org/repos/asf?p=openjpa.git;h=21dbd6c41 ]
[OPENJPA-3072] TCPRemoteCommitProvider: only accept connections from the
configured peers and limit receiving connections (#293)
* [OPENJPA-3072] TCPRemoteCommitProvider: only accept connections from the
configured peers and limit receiving connections
The TCP listener accepted connections from any host, started one receiver
thread per connection without a limit and never removed finished receiver
threads.
- Accept incoming connections only from the configured Addresses and from
this host (loopback and local interface addresses). The new
RestrictToPeers property (default true) turns this off.
- Limit the number of simultaneously receiving connections with the new
MaxReceiveConnections property (default 100, 0 or less means no limit).
- Rejected connections are closed and logged without stopping the accept loop.
- Receiver threads are kept in a concurrent set and remove themselves when
they finish.
- The listener is shared per port, so a connection is accepted if any
registered provider accepts it and the highest limit applies. A new
listener registers its provider before it starts accepting.
- The peer check reads the current addresses, so it follows address updates
of DynamicTCPRemoteCommitProvider, which additionally refreshes its
addresses (at most once per second) before rejecting an unknown host, so
newly started peers are not rejected until the next periodic refresh.
- Document the new properties in the reference guide.
* [OPENJPA-3072] Keep the peer check off the send lock and the accept thread,
use TCP keep-alive
- The listener checks incoming connections against a snapshot of the peer
addresses instead of taking the lock of the addresses, which is held while
sending to the peers, possibly for a long time while connecting to a peer
that is not reachable. Code that changes the addresses calls
addressesChanged() to update the snapshot.
- DynamicTCPRemoteCommitProvider no longer refreshes its addresses on the
accept thread. A connection from an unknown host is handed to a receiver
thread, counted against MaxReceiveConnections, which refreshes the
addresses before reading anything and closes the connection if the host
is still unknown. Refreshes run one at a time and at most once per second,
and one refresh covers all connections accepted before it started.
- KubernetesTCPRemoteCommitProvider defaults RestrictToPeers to false, as it
only knows ready pods as peers, while pods that are not ready yet can
already send events.
- Receiving connections use TCP keep-alive, so connections of peers that
went away without closing them are eventually released and do not hold a
receiving connection forever.
- Document both in the reference guide.
* [OPENJPA-3072] Register a provider with the listener once, copy the providers
with List.copyOf, explain the loopback check and the clock
> TCPRemoteCommitProvider: only accept connections from the configured peers
> and limit receiving connections
> ----------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-3072
> URL: https://issues.apache.org/jira/browse/OPENJPA-3072
> Project: OpenJPA
> Issue Type: Improvement
> Reporter: Richard Zowalla
> Assignee: Richard Zowalla
> Priority: Major
> Fix For: 4.2.0
>
>
> The TCP remote commit provider accepts connections from any host and starts
> one thread per connection without a limit, and finished receiver threads are
> never removed from the listener. Accept only connections from the configured
> Addresses (and this host), with an option to turn this off, limit the number
> of receiving connections, and remove finished threads.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
