JPPF Issue Tracker
Please log in to bookmark issues
CLOSED  Feature request JPPF-453  -  Network communication interceptors
Posted Jun 05, 2016 - updated Jul 13, 2016
icon_info.png This issue has been closed with status "Closed" and resolution "RESOLVED".
Issue details
  • Type of issue
    Feature request
  • Status
  • Assigned to
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
  • Owned by
    Not owned by anyone
  • Category
  • Resolution
  • Priority
  • Targetted for
    icon_milestones.png JPPF 5.2
Issue description
From this forum discussion.

We propose to add a way to run user-defined code right after a socket/socket channel connection is acepted or connected in a JPPF server, node, client and in JMX connector server or client.

This could be used fr instance for authentication and authorization purposes.

Comment posted by
Jun 05, 08:47
I made a small POC that I applied to communications between servers, nodes and clients and that is working nicely. Interceptors are dicovered wia SPI and are implementations of this interface:
public interface NetworkConnectionInterceptor {
  // Called when a {@link Socket} is accepted by a {@link ServerSocket}
  boolean onAccept(Socket acceptedSocket);
  // Called when a {@link SocketChannel} is accepted by a {@link ServerSocketChannel}
  boolean onAccept(SocketChannel acceptedSocket);
  // Called when a {@link Socket} is connected
  boolean onConnect(Socket connectedSocket);
What remains to do:
  • apply to server to server channels
  • apply to JMX connections. Given the dependencies between modules, it will be necessary to use reflection to invoke the interceptors
  • proper error handling, in particular when an interceptor invocation raises an exception, and when it gets stuck forever (e.g. on network I/O operations)
Comment posted by
Jun 18, 21:42
Implemented in trunk revision 4075
Comment posted by
Jun 19, 12:41
forgot to commit the tests: trunk revision 4076
Comment posted by
Jun 28, 10:48
Added access tot he list of loaded interceptors: trunk revision 4102

Comment posted by
Jul 13, 11:46
From this forum post:
It would make sense for AbstractNetworkConnectionInterceptor to keep the Socket overloads abstract and just implement the SocketChannel overloads with onX(channel.socket()), rather than having both sets of methods call new IS/OS methods.

The issue was updated with the following change(s):
  • The status has been updated, from Closed to New.
  • This issue has been reopened
  • The resolution has been updated, from RESOLVED to Not determined.
Comment posted by
Jul 13, 20:24
Done in trunk revision 4150