I want to delete all of a user's inserts in a collection when they stop watching a change stream from a React client. I'm using the Realm Web SDK for this.
Here's a summary of my code with what I want to do at the end of it:
import * as Realm from "realm-web";
const realmApp: Realm.App = new Realm.App({ id: realmAppId });
const credentials = Realm.Credentials.anonymous();
const user: Realm.User = await realmApp.logIn(credentials);
const mongodb = realmApp?.currentUser?.mongoClient("mongodb-atlas");
const users = mongodb?.db("users").collection("users");
const changeStream = users.watch();
for await (const change of changeStream) {
switch (change.operationType) {
case "insert": {
...
break;
}
case ...
}
}
// This pseudo-code shows what I want to do
changeStream.on("close", () => // delete all user's inserts)
changeStream.on("timeout", () => // delete all user's inserts)
changeStream.on("user closes app thus also closing stream", () => ... )
Realm Web SDK patterns seem rather different from the NodeJS ones and do not seem to include a method for closing a stream or for running a callback when it closes. In any case, they don't fit my use case.
These MongoDB Realm Web docs lead to more docs about Realm. Unless I'm missing it, both sets don't talk about how to monitor for closing and timing out of a change stream watcher instantiated from the Realm Web SDK, and how to do something when it happens.
I thought another way to do this would be in Realm's Triggers. But it doesn't seem likely from their docs.
Can this even be done from a front end client? Is there a way to do this on MongoDB itself in a "serverless" way?
If you want to delete the inserts specifically when a (client-)listener of a change-stream stops listening you have to implement some logic on client side. There is currently no way to get notified of such even within Mongodb Realm.
Sice a watcher could be closed because the app / browser is closed I would recommend against running the deletion logic on your client. Instead notify a server (or call a Mongodb Realm function / http endpoint) to make the deletions.
You can use the Beacon API to reliably send a request to trigger the delete, even when the window unloads.
Client side
const inserts = [];
for await (const change of changeStream) {
switch (change.operationType) {
case 'insert': inserts.push(change);
}
}
// This point is only reached if the generator returns / stream closes
navigator.sendBeacon('url/to/endpoint', JSON.stringify(inserts));
// Might also add a handler to catch users closing the app.
window.addEventListener('unload', sendBeacon);
Note that the unload event is not reliable MDN. But there are some alternatives which maybe be good enough for your use case.
Inside a realm function you could delete the documents.
That being said, maybe there is a better way to do what you want to achieve. Is it really the timeout of the change stream listener that has to trigger the delete or some other userevent?
I have a perl-cgi script through which I am trying to log in.
When the UserName and password are valid, I create a session and redirect a cookie to another page.
However, after the session expires(I have set the expiration time), I do not see it get deleted from the /tmp/sessions folder in this case. I have used the command to delete the session as well.
Can someone help me to delete the session once it expires? Also, does the cookie expire once the session is deleted?
use CGI::Session;
use CGI::Session::Tutorial;
use CGI::Session::Driver::file;
use CGI::Cookie;
my $session = new CGI::Session("driver:File", undef, {Directory=>"/tmp/sessions"});
my $sid = $session->id();
#my $cookie = $query->cookie(CGISESSID => $session->id);
my $cookie = $query->cookie(-name=>"CGISESSID",
-value=>$session->id,
-domain=>'abc.com',
-expires=>"+5m",
-path=>"/");
print $query->redirect(-uri => 'http://abc.cgi', -cookie => $cookie);
$session->param("UserName", $loginUserName);
$query->hidden( 'UserName', $loginUserName );
$session->expire("UserName",'1m');
$session->expire('+5m');
$session->delete();
To avoid confusion with ->delete, I'm going to use the word "remove" instead of "delete" to refer to the removal of the session from storage.
Can someone help me to delete the session once it expires?
The removal doesn't happen when the session expires. That would require having a continually running process. Furthermore, at no point does CGI::Session scan storage for expired sessions; that would take too long since it would require loading each and every session. Instead, CGI::Session only removes expired sessions when you try to load them.
#!/usr/bin/perl
use strict;
use warnings qw( all );
use feature qw( say );
use CGI::Session qw( );
use CGI::Session::Driver::file qw( );
my $session_id; # This represents the browser's cookie.
# These represent requests made the by the browser.
for my $request_num (1..3) {
my $session = CGI::Session->new("driver:file", $session_id, { Directory => "/tmp/sessions" });
$session->expire("1s");
$session_id = $session->id; # This represents setting the browser's cookie.
say "$request_num: ", $session->id;
say "$request_num: ", $session->param("foo") // "[undef]";
$session->param("foo" => "bar");
# This represents time passing by before the third request.
if ($request_num == 2) {
say "Letting session expire...";
sleep(2);
}
}
Output:
$ ./a
1: c57ab28952c6ed422c15f1a223f4b45d
1: [undef]
2: c57ab28952c6ed422c15f1a223f4b45d
2: bar
Letting session expire...
3: df8ba3b66f23a9a2a652520fa6b4c30b
3: [undef]
$ ls -1 /tmp/sessions
cgisess_df8ba3b66f23a9a2a652520fa6b4c30b
If you want to prevent files from accumulating on your drive, create a cron job that deletes old files.
find /tmp/sessions -mindepth 1 -maxdepth 1 -mtime 7 -delete
Also, does the cookie expire once the session is deleted?
No, the cookie expires when you tell it to expire. The thing is, it doesn't matter if the browser's cookie expires or not. For the second argument of new, there's no difference between passing undef, passing the id of a deleted session and passing the id of an expired session; you'll get a new session in all three cases. If anything, it's actually better if it doesn't expire as soon as the session expires because this allows the session to be removed (as demonstrated above).
How to delete a session in cgi-perl?
$session->delete is indeed the way to go, but the actual removal only happens when you would save (flush) the session.
$session->delete();
$session->flush(); # Or let `$session` get destroyed.
As the documentation notes
delete()
Sets the objects status to be "deleted". Subsequent read/write requests on the same object will fail. To physically delete it from the data store you need to call flush(). CGI::Session attempts to do this automatically when the object is being destroyed (usually as the script exits), but see "A Warning about Auto-flushing". (emphases mine)
You go on to ask:
Also, does the cookie expire once the session is deleted?
Of course not. You already sent a cookie to the user's browser with an expiration time of five minutes in the future. The cookie will expire then.
If, in the mean time, you have forced the expiration of the session on the server, the user's browser will still send the previously received cookie. Your application will just not find a session corresponding to the session identifier stored in the cookie.
You really need to understand the HTTP request/response cycle before taking one more step.
Per the CGI::Session documentation, deleteing a session "Sets the objects status to be "deleted". Subsequent read/write requests on the same object will fail. To physically delete it from the data store you need to call flush()." (emphasis mine)
Also, per the CGI::Session::Tutorial, "Expiring a session is the same as deleting it via delete(), but deletion takes place automatically." It is not necessary (or useful) to delete a session after it has expired.
I've been battling this question for a while, as surely many Catalyst programmers did as well. Now we see some examples from John about nonblocking applications running with Twiggy.
But I think Twiggy is not the best option to run my whole application. So clearly I want to decouple it and run my app on nginx for example and forward my comet traffic to the Twiggy.
The main problem I see is the authentication. There are several possible options here, that I see:
move authentication to a front-end server
move authentication to a separate catalyst app
use session ids when communicationg with a Twiggy
?? Using Plack sessions ??
First option is not really good, because it does not give me flexibility when changing a front-end server. The second one has also considerable expenses. And the third one I think is the easiest one, taking into account that the Catalyst::Plugin::Session::Store::DBI is used as a session backend.
These are the options that came to my mind. Surely I miss something. So maybe someone encountered the same problems? I would be grateful to anyone who can give me a hint or expand my view on this problematic. It will be also helpful to see pros and contras about each option, as well as some hints about them.
Catalyst and long-polling (comet) applications
Overview
When in the middle of 2013 I decided to incorporate support of reverse AJAX ( further Comet ) functionality into my Catalyst application I found surprisingly little information about it on the Web. So I started to collect the information piece by piece, which forced me to plunge down deeper into the understanding of the Catalyst framework. Then there appeared some good examples of non-blocking code from John Napiorkowski (current maintaner of Catalyst), which have clarified a lot about this topic. So I wrote a simple server, running on Twiggy and providing long-living websockets connections for clients. This solution does not pretend to be the best or even a good one. It is just a working solution. The code has not been refactored and is provided as is. It can be used as a basis for building more robust and reliable comet applications. It can be also improved in many ways. So if you see some mistakes or suggestions for improvement, please let me know.
Introduction
In this section I would like to outline the background for this code.
I have a Catalyst application implementing social networking functionality. It uses mostly AJAX-requests to get data from server. Every minute it makes an AJAX-request to get data updates for a logged-in user. If session has expired, user will be logged out and redirected to the log-in page. For a logged in user there is a part of my application, where a user needs to get periodic updates of data. It is not critical to use comet on this page, I could easily use AJAX (an easier option, but related with network latency and bandwidth and with unnecessary requests sent), but I decided to experiment a bit.
If you run your Catalyst app on a preforking server, you will have a number of servers which serve your clients. If you want to have a long-living connection in your Catalyst app, it means that you will block one instance of your app while keeping this connection open. If you are going to have only a few clients and a lot of hardware resources you may be able to prefork your app. However, if you want to have hundreds, let alone thousands of concurrent connections, this solution may not be suitable for you, because you run out of resorces very fast. This means that either your Catalyst application must run on a nonblocking server, or your client (browser) should communicate with another server, which does not consume much hardware resources and can allocate an instance of itself for each client, while keeping the connection open. Or the client can be connected to a server which runs in an event loop and responds to new data for user in a asynchronous way.
The only nonblocking server for my Catalyst app I was able to find was Twiggy. This server is based on AnyEvent. AnyEvent is a framework for event-driven programming model in Perl and it makes it possible for Twiggy server to serve clients in a nonblocking asynchronous way. It is good for example for requests where it takes some time to get data for user. The server does not block and wait for data to be available for user, but instead it continues to listen to new incoming requests and as soon as data for some user is ready it will be sent to appropriate user.It is probably not the best idea to run your whole Catalyst app on Twiggy. One may want to use some robust, well-tested server (nginx or Apache or whatever) and run your Catalyst app behind those front-end server as FastCGI processes, for instance (the option I chose). So I decided to run Twiggy instance and direct Comet traffic to it (I tried to use Twiggy behind nginx proxy for websockets connection but it didn't work somehow, so I dropped it without further investigation). The first problem was authentication. Because it is done in the Catalyst app and not on the front-end server, it means that my Comet app must somehow know if user is authenticated.
Authentication
Catalyst's module for authentication is Catalyst::Plugin::Authentication. It takes care of authentication and authorization of a user in your app. You most certainly use session module Catalyst::Plugin::Session together with it. This allows to preserve application data across HTTP-requests (including that the user is authenticated). This session module is split into two parts: state and store. The first one allows to choose HOW you preserve app's state across different HTTP-requests (most probably with cookies). The second one allows you to choose WHERE you want to store user's data for his session.So I use Session::State::Cookie for the state and Session::Store::FastMmap for the store. This means that when user is being authenticated, he gets a session id, a secret string, which he will send in a HTTP-header in every HTTP-request to a server. This session id will be valid for some time and as long as it is valid, it is uniquely assigned to some user. Then on every incoming request user's data will be restored from a mmap'ed file through Session::Store::FastMmap. This file acts as a shared memory interprocess cache. This solution (FastMap) is good if your whole app runs on a single server, but if you do load-balancing, for example, you may want to use another solution ( like Catalyst::Plugin::Session::Store::DBI ).So I decided to hack on this session data. In my Comet app I can access this session data and check if user is authenticated. This is done in the following sub.
sub _check_session {
my ($sid, $this_user_id) = #_;
my $return = 0;
my $user_session = $session->get("session:$sid");
if ( $user_session ) {
## Check user realm existence
return $return unless ( $user_session->{__user_realm} );
## Check user presence
return $return unless ( $user_session->{__user} );
## Check session expiration time
my $session_expires_time = $session->get("expires:$sid");
my $now = time();
if ( $now > $session_expires_time ) {
return $return;
}
## Check if it is still the same user
if ( $this_user_id && ($this_user_id ne $user_session->{__user}->{id} ) ) {
return $return;
}
else {
$return = $user_session->{__user};
}
}
return $return;
}
Looking through Catalyst::Plugin::Session and Catalyst::Plugin::Authentication I concluded that it is necessary to check at least the following keys in the session data:
__user_realm: if user is authenticated in at least one realm, this key is present in the session hash
__user: if user is authenticated, this key represents user data ( which comes from the ::Store part of the Authentication module, most probably from DBIx)
"expires:$sid" represents a timestamp when the session expires
$session is an object allowing access to our mmap'ed file:
my $session = Cache::FastMmap->new( raw_values => 0, share_file => ('/tmp/myapp/session_data') );
We are interested in two pieces of data which can be looked up in the session file: "session:$sid" is a key for the session data and "expires:$sid" is a timestamp of session expiration.So now, when a browser tries to establish a websocket connection with our Comet app, we have to call this sub. If a user is authenticated, a websocket connection will be established with the server. While my application automatically closes websocket connection when user logs out or navigates away from the Comet app in his browser, I nevertheless decide to check session id every $interval seconds. So if a malicious user opens a websocket connection on his own, he will get no use of this. For the case when user A logs out and user B logs in using the same session id as user A and all this happens before the next session check, the session will be still active but will relate to another user. In this case we have to check if the session corresponds to the user who initially established the websocket connection:
if ( $this_user_id && ($this_user_id ne $user_session->{__user}->{id} ) ) {
return $return;
}
else {
$return = $user_session->{__user};
}
PSGI, Plack::Builder, Plack::Request
It was a natural choice to implement my Comet app as a PSGI application. I assume you are familiar with this specification.Say you want your app to map different URLs to different applications, for example when you have several areas in your website each requiring it's own comet logic. You can achieve this by using Plack::Builder:
use Plack::Builder;
...
## 1st app entrance point
my $psgi_app = sub {
my $env = shift;
...
}
...
builder {
## mount 1st app
mount "/comet/first_app" => $psgi_app;
}
Now you can mount as many applications as you want each corresponding to a different path (URL).As you know first argument to a PSGI app is $env, which is an environment variable, a hash containing different keys pertaining to a HTTP-request and keys which have to do with the PSGI specification. Using it we can create a Plack request object, which allows us to access different request data and cookies. One of the cookies will contain a session id, which is a starting point for authentication check.
## Request object
my $req = Plack::Request->new($env);
## session id
my $sid = $req->cookies->{myapp_session};
## HTTP origin header
my $req_base = $env->{HTTP_ORIGIN};
Delayed and streaming response
As you know a PSGI app should return a tuple (HTTP-status, HTTP-header and HTTP Body Data). But to enable a server push, an app should return a callback as its response. This callback will then be executed by the underlying server. You can now utilize an event loop in your app to stream data to client.To be able to implement a websocket server one has to use a PSGI extension psgix.io which gives access to a raw internet socket, so that one has a full access over streaming data. Because in the websocket specification one has to do an upgrade from HTTP to the ws protocol during an initial handshake connection, the low-level access to the socket is required.
my $psgi_app = sub {
my $env = shift;
my $fh = $env->{'psgix.io'} or return [500, [], []];
## Create websocket handshake
my $hs = Protocol::WebSocket::Handshake::Server->new_from_psgi($env);
$hs->parse($fh) or return [400, [], [$hs->error]];
return sub {
my $responder = shift;
...
}
}
So we create an object which takes care of data format of messages for the websocket protocol, which are exchanged between client and server. This object is initialized with our raw internet socket so that it can fulfil the HTTP upgrade. And afterwards we return a callback which will be our delayed response.
The comet app, server-side
So here is the whole comet psgi app:
use Plack::Builder;
use Plack::Request;
use AnyEvent;
use Protocol::WebSocket::Handshake::Server;
use Cache::FastMmap;
use JSON;
use Template;
use Log::Dispatch;
use Data::Dumper;
use DateTime;
use FindBin qw($Bin);
use lib "$Bin/../lib";
use myapp::Schema;
use warnings;
use strict;
## Session data
my $interval = 3;
my $session = Cache::FastMmap->new( raw_values => 0, share_file => ('/tmp/myapp/session_data') );
## Database connection, for example with a Postgres DB
my $db_schema = myapp::Schema->connect( {
dsn => 'dbi:Pg:dbname=myapp_test',
user => 'my_login',
password => 'my_passwd',
pg_enable_utf8 => 1
} );
## Logging object
my $log = Log::Dispatch->new( outputs => [ [ 'File', min_level => 'debug', filename => '/var/log/myapp_test/comet' ] ] );
## Adjust this sub correspondingly if Session::Store has been changed.
sub _check_session {
my ($sid, $this_user_id) = #_;
my $return = 0;
my $user_session = $session->get("session:$sid");
## Check if the sid and the user email match
if ( $user_session ) {
## Check user realm existence
return $return unless ( $user_session->{__user_realm} );
## Check user presence
return $return unless ( $user_session->{__user} );
## Check session expiration time
my $session_expires_time = $session->get("expires:$sid");
my $now = time();
if ( $now > $session_expires_time ) {
return $return;
}
## Check if it is still the same user
if ( $this_user_id && ($this_user_id ne $user_session->{__user}->{id} ) ) {
return $return;
}
else {
$return = $user_session->{__user};
}
}
return $return;
}
## 1st app entrance point
my $psgi_app = sub {
my $env = shift;
my $fh = $env->{'psgix.io'} or return [500, [], []];
## Create websocket handshake
my $hs = Protocol::WebSocket::Handshake::Server->new_from_psgi($env);
$hs->parse($fh) or return [400, [], [$hs->error]];
return sub {
my $responder = shift;
## App data
my ($w, $hd, $input_params, $req, $sid, $user_id, $ret, $time_lapsed, $req_base);
## Clean up the websocket local environment
my $clean_up = sub {
$log->debug("\nCleaning up...\n");
## Destroy websocket
$hd->destroy;
## Remove timer from event loop
undef $w;
};
$hd = AnyEvent::Handle->new(
fh => $fh,
on_error => sub {
my ($hd, $fatal, $msg) = #_;
$clean_up->();
}
);
## Send server websocket handshake
$hd->push_write($hs->to_string);
## Websockets connection is initialized and is ready for data to be sent
#$hd->push_write( $hs->build_frame( buffer => encode_json( { 'status' => "Connection init..." } ) )->to_bytes );
## Get request data
$req = Plack::Request->new($env);
$sid = $req->cookies->{myapp_session};
$req_base = $env->{HTTP_ORIGIN};
## Check if user is authenticated
unless ( $ret = _check_session($sid, undef) ) {
$clean_up->();
}
else {
$user_id = $ret->{id};
}
$time_lapsed = 0;
## Template toolkit
my $template = Template->new({
INCLUDE_PATH => "$Bin/../root/templates",
VARIABLES => {
req_base => $req_base,
user_id => $user_id,
user_lang => $ret->{language}
},
ENCODING => 'utf8',
});
## Input parameters and recieve user's data.
$hd->on_read(sub {
(my $frame = $hs->build_frame)->append($_[0]->rbuf);
while (my $message = $frame->next) {
my $decoded_data = eval { decode_json $message };
## If it's not a valid json - exit
if ($#) {
$clean_up->();
}
else {
## New connection
if ( $decoded_data->{is_new} ) {
$input_params = $decoded_data;
$stash = {
template_data => "some data"
};
my $tt_output;
$template->process( "template_path", $stash, \$tt_output );
$hd->push_write( $hs->build_frame( buffer => encode_json( { 'init_data' => $tt_output } ), max_payload_size => 200000 )->to_bytes );
}
## Else - additional data are sent from the client
else {
}
}
}
});
## THIS APP'S MAIN LOGIC
## As an example, let's track if user has changed his/her name and return a message to the browser
my $app_logic = sub {
my $this_params = shift;
if ( $user_id ) {
my $rs = $db_schema->resultset('User')->search( { id => $user_id } )->single;
if ( $rs->first_name ne $ret->{first_name}) {
$hd->push_write( $hs->build_frame( buffer => encode_json( { 'data' => "User changed his name!" } ) )->to_bytes );
}
}
};
## Any event logic
$w = AnyEvent->timer (
interval => $interval,
after => $interval,
cb => sub {
## Check every half a minute if the user is still authenticated
if ( $time_lapsed > 30 ) {
$time_lapsed = 0;
unless ( $ret = _check_session($sid, $user_id) ) {
$clean_up->();
}
else {
## Check if user' object has been changed (e.g. his language etc.)
}
}
## Execute main logic
$app_logic->($input_params);
$time_lapsed += $interval;
}
);
};
};
builder {
## mount 1st app
mount "/comet/myapp" => $psgi_app;
}
So we start the program with initializing some common objects like database handle and session object.When a websocket connection is terminated we don't want to respond to events pertaining to it, so we remove them from the event loop. That is what is done in the sub reference $clean_up. Then we define an AnyEvent::Handle object and listen to it's on_read() callback which is fired up every time new data arrives from the client.Because I want to be able to use the same template for generating HTML both for my Catalyst app and for my comet app, I create a Template object and initialize it with variables which must be the same in the Catalyst counterpart. First time the on_read() callback is called is when a client opens a websocket connection. In the javascript part we define a special key for this and send the client initial data on new request (in my case it ís the data for which later I get comet updates).Additionally, we create an AnyEvent timer object which will periodically execute our main logic app $app_logic. It will also check if the user is still authenticated and is granted to get the data update from the server.Don't forget, if you change some user data in your database through a Catalyst controller and this change must be reflected in the session hash, you have to persist it by calling
$c->persist_user();
The comet app, client-side
I use module pattern for javascript modules to create a separate namespace for every javascript module. Here is one to handle communication with the comet server.
var myapp = (function() {
// Context data, private
var data_loaded = false;
var this_page = true;
return {
init: function() {
data_loaded = false;
this_page = true;
// No websockets in safari, somehow they don't work there
if ( navigator.userAgent.indexOf('Safari') != -1 && navigator.userAgent.indexOf('Chrome') == -1 ) {
myapp.myapp_load_ajax();
}
else {
// Create a websocket
websockets["myapp_socket"] = new WebSocket('ws://my-domain-name:5000/comet/myapp');
var input_hash = {};
input_hash["is_new"] = 1;
websockets["myapp_socket"].addEventListener("open", function(e) {
websockets["myapp_socket"].send(JSON.stringify(input_hash));
data_loaded = true;
});
websockets["myapp_socket"].addEventListener("message", function(e) {
var this_obj = JSON.parse(e.data);
// Connection is initialized
if ( this_obj.init_data ) {
// Make necessary initializations
myapp.init_after_loading();
}
// Websockets data update from server
else if ( this_obj.data ) {
// Do something meaningful on data update
}
});
websockets["myapp_socket"].addEventListener("close", function(e) {
//Connection has been closed
});
// In case when a websocket cannot be created, fall back to an AJAX request
websockets["myapp_socket"].addEventListener("error", function(e) {
// Unless the data have already been loaded, load it here for the first time, because
// this method will be also invoked when connection is dropped.
if ( !data_loaded && this_page ) {
myapp.myapp_load_ajax();
}
});
}
},
myapp_load_ajax: function() {
jQuery.ajax({
type: "POST",
url: "my_catalyst_app_load_ajax_data_path",
dataType: "json",
cache: false,
complete: function (xhr, textStatus) {
if ( xhr.responseText ) {
var this_data = jQuery.parseJSON(xhr.responseText);
if ( !this_data ) {
// An error happened
}
else {
// Make necessary initializations after your data has been inserted into the DOM
myapp.init_after_loading();
}
}
}
});
},
init_after_loading: function() {
// If you insert some data into DOM, initialize it here
},
close_socket: function() {
if ( websockets["myapp_socket"] ) {
websockets["myapp_socket"].close();
delete websockets["myapp_socket"];
}
},
};
})();
You can read about module pattern in details elsewhere on Internet. In short, it makes an object out of your javascript module and your methods will be accessible as this object's properties. This allows you to create a separate namespace for your module and to define private variables.In order to be able to access my websocket from another module, which may be necessary, I declare an object which holds it as a global one.What we have to do is to define event handlers for our websocket which include "open", "close" etc. If for some reason we cannot establish a websocket connection to our comet server (server is down, it does not accept new connections etc.), we fall back to AJAX. Additionally, if safari tries to create a websocket-connection with a dead server, it doesn't handle this case in an "error" event, so we just prohibit websockets in safari.So, we start by creating a new websocket connection for the URL that we have mounted in the plack builder in the comet server. Then we use websocket's event "open" to take care of new connection, signifying the server about new client connection. Event "message" is used to send messages to the comet server; "close" is called whenever a connection with the server is closed; "error" is called in case of problems with connection, for instance it cannot be established or it has been broken or the server has closed the connection or died. And that's it. Now we will get data updates from our comet server.
Starting comet server
Now what is left is to start our server. The current server's code assumes that it will run on the same machine as your Catalyst app. Some other possibilities will be discussed in the final notes section.We use command line utility plackup to start our server:
TWIGGY_DEBUG=1 plackup -s Twiggy comet.psgi
I use TWIGGY_DEBUG env var to see debug info from the Twiggy server.
Final notes
First thing to remember is that Twiggy server will exit as soon as a die statement will be executed. It means that you have to program it safely and to intercept every statement that can lead to this with an eval block.The premise for current comet server is that it runs on the same machine as your Catalyst app. If you are planning to do load balancing and to run it on another machine you have to take care of some things. First, you have to change your session plugin to Session::Store::DBI or something suited for distributing across several machines (and afterwards to adjust _check_session() to get data not from a file but from the database). Then change the dsn for the database connection to include a hostname and a port number.Another thing to note is that our main logic in the server checks every N seconds if user's name has been changed. So, it is inefficient to query a database so often if your server has many clients. Instead, there are some better solutions for this. First option is that if you run a Catalyt app and a comet server on a single machine, you can use the Cache::FastMmap file as a mediator between your Catalyst app and your comet server for getting notifications that some new data is available for the server and only then querying database to get the data update. In this case you make database queries only to get the new data. It means that in your Catalyst controller you have to write into the cache file to inform the comet server to check data every time when you make changes through you controller to the data that you get updates to in your comet server. For example you have a User controller and a User model. Whenever a user changes his name, User controller is called which in turn calls User model to change user'd data. So in the controller User you additionally write into the cache file that this is the case. Then the comet server will know when to get data updates from the database. The similar approach you can use if you do load balancing and your Catalyst and comet app run on different machines. But in this case you have to use your database as a mediator. You can, for example, create a new table which will be periodically queried by the comet server. Each column of the table could correspond to some application domain of your comet server. The column can be of type timestamp and to mark the time of last change of the data that you trace. In you Catalyst controller you write into corresponding column every time whenever the data in question has been changed and then you check this column in the comet server and you know then whether to query the database for the data updates or not. Thus you will avoid a lot of unnecessary data queires. But the better choice, however more complicated, would involve sockets. In this case when a user logs in we create a new socket for him and we write all data updates that we want to track directly into the socket. In the comet app instead of using an Anyevent timer, we define another AnyEvent::Handle which we initialize with the user's socket. And by using the on_read() method we get updates when they come and then return them immediately to the user. In this case we bypass data queries and it should work really fast. But this solution will require a lot of additional work in the Catalyst controller.Another thing to note is that current comet server does not support secure websockets (wss) protocol while Twiggy does not support TLS/SSL. The solution would be to use a SSL tunnel in front of your server which will transparently encrypt/decrypt messages (take a look at https://github.com/vti/app-tlsme).And the final note: I have tried to run a front-end proxy nginx in front of my comet server. But somehow nginx could not propagate messages to the Twiggy. So the client's browser communicates directly with the comet server. If you plan to have thousands and thousands of users then a websocket load balancing is a topic to think about.If you find any mistakes or have any improvements ideas please comment or write me an email (dhyana1981#yahoo.de).
I think the better option is 3 or 4.
Setup your nginx to server distinct location points for Catalyst-app and Twiggy-app.
And, if you are using Twiggy you may want speed, so instead of using DBI, I suggest to you save/restore/check sessions via a memory-based application, like Memcached or Redis, so you can scale up this later if you go to AWS or something like that.
You can do the job with Catalyst::Plugin::Session::Store::Memcached::Fast or Catalyst::Plugin::Session::Store::Cache and others, but if you known how to create a secure session token and how to keep/restore, you can do this by yourself, so you will known how to restore in Twiggy, Catalyst or anything else (even other languages)
Have a good day!
I have a mod_perl2.0.4 / Apache2.2 web app running on CentOS 6.4 with PostgreSQL 9.0.
Until recently, I had this setup: Apache::DBI and DBI->connect_cached for all connections, which was starting to give FATAL: sorry, too many clients already even in my development area where I'm the only user.
In an effort to debug this, I have removed all references to Apache::DBI, upgraded to the latest DBI, and replaced all occurrences of connect_cached with plain DBI->connect. It seems to me now that somewhat less connections are made and then left <IDLE>. However, I realize that I haven't been calling disconnect() on all of my statement handles, because it had sounded like under Apache::DBI it wouldn't have made a difference.
My connections currently connect all as the same user, then lower their privileges based on which user it is via SET SESSION AUTHORIZATION. I do it this way because some other apps that use the database allow for a passworded login, which can pass the credentials directly to the database, but this particular web app uses an honour system login screen whereby you just click your name to log in. So it's future-security-ready but convenience-enabled at the moment. Also, database triggers for history and such rely on the session user being set correctly to track who did what.
Because I was concerned about a database handle being reused with the wrong session user, I pass { private_user_login => $login_role_name, PrintError => 0, RaiseError => 1, AutoCommit => 1} to connect_cached to differentiate each connection by user. But since I always set the session authorization immediately after connecting, I suppose that all the private_user_login hash does is make it so that for a given Apache process, there might be at least as many DB connections created and left idle as there are users, if eventually every user manages to randomly use a given Apache process. Meanwhile, because I don't disconnect any handles, they eventually get used up.
My question is, is it safe to take out the private_user_login to make all the connection handles look the same, to cut down on the number of connections left open, or is it possible that a connection handle could be re-used in the middle of a script (after setting the session user) by a different user, thus creating a race condition? Also, although Apache::DBI's docs say I needn't remove disconnect() calls, should I still have such a call at the end of every one of my scripts so that Apache::DBI can decide whether to disconnect?
In other words, without my private connection variable, do SET SESSION AUTHORIZATION's effects persist when the next Apache::DBI->connect() reuses the existing connection? If so, is it ever possible that a connection is re-used by another request while one request is currently executing but not currently using the database handle?
I recommend a somewhat different tack, if you can.
Keep it simple in Apache. Use private sessions per user, if that's what's easiest to make safe and reliable.
Then put a PgBouncer between the PostgreSQL server and your Apache instance. Set it to transaction pooling mode. It'll happily multiplex your connections, and it'll take care of calling DISCARD ALL whenever a connection switches between users.
I think you can still use SET SESSION AUTHORIZATION on connections made via PgBouncer.
It seems safe. To "verify" you can make an artificial race condition like this:
use Apache2::RequestUtil;
use Apache2::RequestRec;
my $r = Apache2::RequestUtil->request;
$r->headers_out->add('Cache-control' => "must-revalidate, no-cache, no-store");
require Apache2::Request;
my $req = Apache2::Request->new($r);
$r->content_type("text/html");
my $login_role_name = $req->param('u');
$r->print($u);
$r->print('<br>' . $$);
use DBI;
my $dbh = DBI->connect_cached("dbi:Pg:dbname=......,{ RaiseError => 1, AutoCommit => 1});
$dbh->do("set session authorization ?; ", undef, $login_role_name);
{
use warnings NONFATAL => 'all';
my $rows = $dbh->selectall_arrayref('select pg_backend_pid(), current_user::text');
warn "pg ${$$rows[0]}[0] mp $$ auth: ${$$rows[0]}[1] original auth: $login_role_name";
sleep 10;
$rows = $dbh->selectall_arrayref('select pg_backend_pid(), current_user::text');
warn "pg ${$$rows[0]}[0] mp $$ auth: ${$$rows[0]}[1] original auth: $login_role_name";
}
...and then hit it with two different '?u=...' URLs. The auth will always match the original auth, because the dbh is not available to be given away while it's still in a script that's executing.
How can I write or update session data before a request ends in Perl MVC Catalyst Framework.
I am using Session::State::Cookie and Session::Store::FastMap
I need to ensure that the data is available before the long-running request completes
This is what worked for me.
To ensure the information is updated at the time it is set in the long running request, I do a $c->finalize_session just after updating some importante information related to the session:
$c->session->{important_info} = "new value";
$c->finalize_session;
I verified that the other requests are gathering the right value after that.
I did not observed any side effects calling $c->finalize_session many times during a request just to ensure the session data to be updated, but I am not certained about this.
One of the informations that I am setting in this way is a counter to update a progress bar to feedback the user (because this task takes a long time). I do not know if it is the best way to do that, I will appreciate any suggestion.
You can do some last-second processing just before a request is completed and the response sent to the client by overriding the handle_request method in your application's main module or a plugin.
sub handle_request {
my ($c, #args) = #_;
my $status = $c->next::method(#args);
# Do some last minute processing before the request is completed.
return $status;
}
I've overridden this method before to collect stats about a request or restart a worker process if it uses too much memory. Let me know if this is helpful or if you have more questions about it.