|
Home > Archive > Perlbal > December 2006 > Patch: Selector Additions
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Patch: Selector Additions
|
|
| Matt Mankins 2006-12-16, 1:11 pm |
| Hi.
We were having an issue where we wanted to use a selector with a
service whose role was not one of "web_server" or "reverse_proxy".
Attached is the patch (against 1.47) we use to let this happen,
rather than giving a 500 server error.
Now in the load() of your Plugin:
Perlbal::Service::add_role(
'xmpp_binder',
\& Perlbal::Plugin::XMPP_Binder::Client::ne
w,
->
\& Perlbal::Plugin::XMPP_Binder::Client::ne
w_from_base
);
Let us know if there was a better way to do this and we'll do it that
way.
Best,
Matt Mankins
Lorem Ipsum Books
http://www.SaveTheBookstoreSaveTheWorld.com/
| |
| Brad Fitzpatrick 2006-12-17, 1:11 pm |
| Rather than having the selector_creator stuff, can you just register a
classname, so this code:
if ($self->{'role'} eq "web_server") {
Perlbal::ClientHTTP->new_from_base($cb);
return;
} elsif ($self->{'role'} eq "reverse_proxy") {
Perlbal::ClientProxy->new_from_base($cb);
return;
} else {
$cb->_simple_response(500, "Can't map to service type $self->{'role'}");
}
Could just be something like:
my $sub_class = sub_class_of($self->{role});
if ($sub_class) {
$sub_class->new_from_base($cb);
return;
} else {
$cb->_simple_response(500, "Can't map to service type $self->{'role'}");
}
And then sub_class_of looks at the registered role->class?
Would simplify it a bit.
But I'm more interested in this XMPP stuff you're doing ... care to share? 
On Sat, 16 Dec 2006, Matt Mankins wrote:
> Hi.
>
> We were having an issue where we wanted to use a selector with a
> service whose role was not one of "web_server" or "reverse_proxy".
> Attached is the patch (against 1.47) we use to let this happen,
> rather than giving a 500 server error.
>
> Now in the load() of your Plugin:
>
> Perlbal::Service::add_role(
> 'xmpp_binder',
>
> \& Perlbal::Plugin::XMPP_Binder::Client::ne
w,
> ->
> \& Perlbal::Plugin::XMPP_Binder::Client::ne
w_from_base
> );
>
> Let us know if there was a better way to do this and we'll do it that
> way.
>
> Best,
> Matt Mankins
> Lorem Ipsum Books
> http://www.SaveTheBookstoreSaveTheWorld.com/
>
>
>
| |
| Matt Mankins 2006-12-17, 1:11 pm |
|
On Dec 17, 2006, at 2:49 PM, Brad Fitzpatrick wrote:
> Rather than having the selector_creator stuff, can you just register a
> classname,
> Could just be something like:
>
> my $sub_class = sub_class_of($self->{role});
> if ($sub_class) {
> $sub_class->new_from_base($cb);
> return;
> } else {
> $cb->_simple_response(500, "Can't map to service type $self-
> }
>
> And then sub_class_of looks at the registered role->class?
>
> Would simplify it a bit.
That is nice. Great.
> But I'm more interested in this XMPP stuff you're doing ... care to
> share? 
I'm implementing XEP-124, HTTP Binding, with Perlbal.
http://www.xmpp.org/extensions/xep-0124.html
It's quite rough, but seems to mostly work. I didn't quite get how
everything fit together when first designing--especially the
fields--, so it could probably use a revamp.
Web Client -> Perlbal -> XMPP Binder Maintains a Flock of DJabberd
Connections -> DJabberd
For /xmpp urls we use a long-poll style connection that waits for
DJabberd chatter.
Also routing between multiple Perlbals isn't figured out. I haven't
decided if I should reproxy to the Perlbal where the DJabberd
connection is open, or throw memcache in the middle somewhere or
something else.
In our system we've modified it so that /files goes to a Mogile
handler, /xmpp to the XMPP Binder, and everything else gets reproxied
to the app server.
Let me know if you want to know more.
Matt
| |
| Brad Fitzpatrick 2006-12-17, 1:11 pm |
| On Sun, 17 Dec 2006, Matt Mankins wrote:
>
> I'm implementing XEP-124, HTTP Binding, with Perlbal.
>
> http://www.xmpp.org/extensions/xep-0124.html
>
> It's quite rough, but seems to mostly work. I didn't quite get how
> everything fit together when first designing--especially the
> fields--, so it could probably use a revamp.
>
> Web Client -> Perlbal -> XMPP Binder Maintains a Flock of DJabberd
> Connections -> DJabberd
>
> For /xmpp urls we use a long-poll style connection that waits for
> DJabberd chatter.
>
> Also routing between multiple Perlbals isn't figured out. I haven't
> decided if I should reproxy to the Perlbal where the DJabberd
> connection is open, or throw memcache in the middle somewhere or
> something else.
>
> In our system we've modified it so that /files goes to a Mogile
> handler, /xmpp to the XMPP Binder, and everything else gets reproxied
> to the app server.
>
> Let me know if you want to know more.
Wonderful! That's what I hoped you were implementing (sounded like it).
Somebody else has been mailing me, asking about HTTP Binding, so it'd be
great if you could Open Source this. I'm sure we could collectively work
out any kinks.
As for multiple Perlbals, if the client hit a Perlbal that didn't own that
session ID, you could just send out a discovery query to the local
network, asking which Perlbal owns that session (several ideas on how to
do this easily), then just use Perlbal's normal HTTP proxying stuff (in
particular the stuff used for X-Reproxy-URL, where no service is needed),
to proxy that HTTP request to the Perlbal which doesown that backend
DJabberd connection.
- Brad
| |
| Matt Mankins 2006-12-24, 1:11 pm |
| > Somebody else has been mailing me, asking about HTTP Binding, so
> it'd be
> great if you could Open Source this. I'm sure we could
> collectively work
> out any kinks.
I put the XMPP code which implements XEP 124* into subversion today:
svn://code.loremlabs.com/xmpp-binder/
It's quite rough and does not have the ability to spread load over
multiple Perlbals, but keeps a connection open and works well enough
to make JSJaC work. I suspect there's quite a bit of cleanup/rework
to be done before it's efficient.
> As for multiple Perlbals, if the client hit a Perlbal that didn't
> own that
> session ID, you could just send out a discovery query to the local
> network, asking which Perlbal owns that session (several ideas on
> how to
> do this easily), then just use Perlbal's normal HTTP proxying stuff
> (in
> particular the stuff used for X-Reproxy-URL, where no service is
> needed),
> to proxy that HTTP request to the Perlbal which doesown that backend
> DJabberd connection.
I'll have to try that.
Thanks,
Matt Mankins
Lorem Ipsum Books
http://www.savethebookstoresavetheworld.com
* - http://www.xmpp.org/extensions/xep-0124.html
|
|
|
|
|