[
https://issues.apache.org/jira/browse/IGNITE-29256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-29256:
--------------------------------------
Description:
IGNITE-29209 lets a factory replace its cached SSL context. Outgoing
communication already obtains that context for each connection. Discovery,
incoming communication, the client connector and binary REST retain the startup
context, so replacing the factory cache does not change the keys or trust used
by their new connections.
Make these transports use the replacement. The administrator command follows in
IGNITE-29210; this ticket verifies reload through the factory API.
h3. What to change
# For {{AbstractSslContextFactory}}, obtain its current context for every new
connection. Cover both directions of discovery and communication, plus the
client connector and binary REST.
# Keep established connections open. During loading and after a failed reload,
new connections must still use the previous context. Preserve server mode,
client authentication, handshake timeouts, protocols, cipher suites and startup
validation.
# Use one discovery socket path for all factory types. Other factory types keep
their startup context for discovery and incoming connections; outgoing
communication keeps calling their factory for each connection.
# If context lookup or TLS setup fails on an accepted discovery socket, close
that socket and keep accepting connections. In NIO, a context lookup failure
must close only the affected session and leave the worker running.
h3. Custom factories and compatibility
Document that Ignite calls {{AbstractSslContextFactory.create()}} for every new
connection, including on NIO threads. Custom discovery contexts must support
engine creation for startup checks, TLS wrapping of an accepted socket and
server mode. Settings supplied only by a custom server socket factory no longer
affect discovery connections.
Remove the protected {{TcpDiscoverySpi.sslSockFactory}} and
{{sslSrvSockFactory}} fields; connections no longer use them. This breaks
source and binary compatibility for subclasses that access them. Those
subclasses must be adapted and rebuilt.
h3. Done when
* A test reloads a running node's factory, then confirms replacement keys and
trust on every TCP transport, including both directions of discovery and
communication.
* Established connections stay usable. New connections use the old material
during loading and after a failed load.
* A shared factory and an ordinary factory work through the same discovery
path. After an injected lookup or socket-setup failure, discovery accepts the
next connection; an NIO lookup failure leaves the worker usable.
Depends on IGNITE-29209. The command, scheduling and HTTP REST are separate
tickets.
[Implementation plan in PR #13795|https://github.com/apache/ignite/pull/13795]
was:
IGNITE-29209 lets a factory replace its cached SSL context. Outgoing
communication already obtains that context for each connection. Discovery,
incoming communication, the client connector and binary REST retain the startup
context, so replacing the factory cache does not change the keys or trust used
by their new connections.
Make these transports use the replacement. The administrator command follows in
IGNITE-29210; this ticket verifies reload through the factory API.
h3. What to change
# For {{AbstractSslContextFactory}}, obtain its current context for every new
connection. Cover both directions of discovery and communication, plus the
client connector and binary REST.
# Keep established connections open. During loading and after a failed reload,
new connections must still use the previous context. Preserve server mode,
client authentication, handshake timeouts, protocols, cipher suites and startup
validation.
# Use one discovery socket path for all factory types. Other factory types keep
their startup context for discovery and incoming connections; outgoing
communication keeps calling their factory for each connection.
# If context lookup or TLS setup fails on an accepted discovery socket, close
that socket and keep accepting connections. In NIO, a context lookup failure
must close only the affected session and leave the worker running.
h3. Custom factories and compatibility
Document that Ignite calls {{AbstractSslContextFactory.create()}} for every new
connection, including on NIO threads. Custom discovery contexts must support
engine creation for startup checks, TLS wrapping of an accepted socket and
server mode. Settings supplied only by a custom server socket factory no longer
affect discovery connections.
Keep {{TcpDiscoverySpi.sslSockFactory}} and {{sslSrvSockFactory}} as deprecated
protected fields so subclasses can still reference them. They retain their
startup values. Reload does not update them, and assigning them no longer
changes connections. State both limits in their Javadoc.
h3. Done when
* A test reloads a running node's factory, then confirms replacement keys and
trust on every TCP transport, including both directions of discovery and
communication.
* Established connections stay usable. New connections use the old material
during loading and after a failed load.
* A shared factory and an ordinary factory work through the same discovery
path. After an injected lookup or socket-setup failure, discovery accepts the
next connection; an NIO lookup failure leaves the worker usable.
Depends on IGNITE-29209. The command, scheduling and HTTP REST are separate
tickets.
[Implementation plan in PR #13795|https://github.com/apache/ignite/pull/13795]
> Use the factory's current SSL context for new TCP connections
> -------------------------------------------------------------
>
> Key: IGNITE-29256
> URL: https://issues.apache.org/jira/browse/IGNITE-29256
> Project: Ignite
> Issue Type: Sub-task
> Reporter: Anton Vinogradov
> Assignee: Anton Vinogradov
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> IGNITE-29209 lets a factory replace its cached SSL context. Outgoing
> communication already obtains that context for each connection. Discovery,
> incoming communication, the client connector and binary REST retain the
> startup context, so replacing the factory cache does not change the keys or
> trust used by their new connections.
> Make these transports use the replacement. The administrator command follows
> in IGNITE-29210; this ticket verifies reload through the factory API.
> h3. What to change
> # For {{AbstractSslContextFactory}}, obtain its current context for every new
> connection. Cover both directions of discovery and communication, plus the
> client connector and binary REST.
> # Keep established connections open. During loading and after a failed
> reload, new connections must still use the previous context. Preserve server
> mode, client authentication, handshake timeouts, protocols, cipher suites and
> startup validation.
> # Use one discovery socket path for all factory types. Other factory types
> keep their startup context for discovery and incoming connections; outgoing
> communication keeps calling their factory for each connection.
> # If context lookup or TLS setup fails on an accepted discovery socket, close
> that socket and keep accepting connections. In NIO, a context lookup failure
> must close only the affected session and leave the worker running.
> h3. Custom factories and compatibility
> Document that Ignite calls {{AbstractSslContextFactory.create()}} for every
> new connection, including on NIO threads. Custom discovery contexts must
> support engine creation for startup checks, TLS wrapping of an accepted
> socket and server mode. Settings supplied only by a custom server socket
> factory no longer affect discovery connections.
> Remove the protected {{TcpDiscoverySpi.sslSockFactory}} and
> {{sslSrvSockFactory}} fields; connections no longer use them. This breaks
> source and binary compatibility for subclasses that access them. Those
> subclasses must be adapted and rebuilt.
> h3. Done when
> * A test reloads a running node's factory, then confirms replacement keys and
> trust on every TCP transport, including both directions of discovery and
> communication.
> * Established connections stay usable. New connections use the old material
> during loading and after a failed load.
> * A shared factory and an ordinary factory work through the same discovery
> path. After an injected lookup or socket-setup failure, discovery accepts the
> next connection; an NIO lookup failure leaves the worker usable.
> Depends on IGNITE-29209. The command, scheduling and HTTP REST are separate
> tickets.
> [Implementation plan in PR #13795|https://github.com/apache/ignite/pull/13795]
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
