JPPF Issue Tracker
star_faded.png
Please log in to bookmark issues
feature_request_small.png
CLOSED  Feature request JPPF-453  -  Network communication interceptors
Posted Jun 05, 2016 - updated Jul 13, 2016
action_vote_minus_faded.png
0
Votes
action_vote_plus_faded.png
icon_info.png This issue has been closed with status "Closed" and resolution "RESOLVED".
Issue details
  • Type of issue
    Feature request
  • Status
     
    Closed
  • Assigned to
     lolo4j
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
     lolo4j
  • Owned by
    Not owned by anyone
  • Category
    Networking
  • Resolution
    RESOLVED
  • Priority
    Normal
  • 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.


#1
Comment posted by
 lolo4j
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)
#3
Comment posted by
 lolo4j
Jun 18, 21:42
Implemented in trunk revision 4075
#5
Comment posted by
 lolo4j
Jun 19, 12:41
forgot to commit the tests: trunk revision 4076
#6
Comment posted by
 lolo4j
Jun 28, 10:48
Added access tot he list of loaded interceptors: trunk revision 4102

#7
Comment posted by
 lolo4j
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.
#8
Comment posted by
 lolo4j
Jul 13, 20:24
Done in trunk revision 4150