Naming a CPAN module that watches for closed sockets

[NERDVANA]

So, at work we recently embarked on a quest to kill off long-running database queries by web worker processes whose clients have closed their browser tab, or likewise clicked a cancel button attached to their AJAX request. The main problem was that the whole backend is blocking-style, using a preforked Plack server, and there was no way to monitor for events on the socket while the database query was in progress. (nor did the Plack server even provide access to the socket) While the correct way is to use nonblocking queries and an event-loop webserver, that scale of a rewrite is not practical. Another possible option is to alter an existing plack server with fancy hooks to kill a query, but again, the single-threaded nature of the code prevents a lot of this.

Well, believe it or not, we actually managed to accomplish this feat with the existing app and Plack server using an Inline::C pthread and PadWalker and shelling out to run mysql -e 'kill $conn_id' and some other insanity, but IT WORKS!

To celebrate this achievement, I would like to bundle it up in a CPAN module. The main goal is to abort/kill/cancel everything a single-threaded web worker is doing (in a highly configurable manner, of course) whenever we lose the ability to reply to the requestor. The best name I have so far is IO::SocketStatusSignaler IO::SocketStatusTrigger IO::SocketAlarm. Anyone have other ideas?

I'm also happy to entertain conversations about less-insane methods for solving this problem.

Update:

API Preview:

  # When the client goes away, terminate the current process
  # and also kill the mysql query that is running on the server.
  my $watch= watch_socket(
    socket => $socket,
    event => EVENT_EOF|EVENT_EPIPE,
    actions => [
      [ run => 'mysql', -e => "kill $id" ],
      [ kill => $$, SIGKILL ],
    ]
  );

[talexb]

Maybe just IO::SocketWatcher?

[NERDVANA]

I agree simpler is better, but I was trying to differentiate this from yet another event loop. I mean, it is an event loop, just not one that the user uses directly.

But, that gave me the idea of IO::SocketAlarm, which plays off the alarm() syscall concept.

[Danny]

ZombieQueryKiller or OrphanQueryKiller

[NERDVANA]

Appropriate to the goal, but the module is just going to give you the tools you need to write query-killing features, rather than actually doing it for you. Every application is going to have unique circumstances about how to connect to the database, so I'm not sure how I could build that into the module.

So, as it stands, it is just the piece that watches for the socket to get disconnected, and "does stuff" that you tell it to do, like send signals, close connections to hosts, or exec external commands.

[Discipulus]

Hello NERDVANA,

> ..watches for the socket to get disconnected, and "does stuff"

so why not something IO::Socket::ManageDisconnected or IO::Socket::GetDisconnected ?

Or if you wont something with more humor.. in Czechia they have a small troll in houses that eats sockets unpairing them.. ask choroba for the name

L*

[Danny]

OrphanSocketSniffer?