| Author |
Message |
< Yaws mailing list ~ Forwarding Arg#arg to another YAWS node |
| Guest |
 Posted: Mon May 26, 2008 12:25 pm |
 |
|
|
Guest
|
Recently I had to create some sort of CGI load balancing. The request
would come to some YAWS instance, validated against certain criteria,
and then go to an appropriate node where _that_ YAWS instance would
execute a CGI.
I tried doing it by creating a .yaws file on one node invoking
rpc:call() to forward the incoming Arg#arg to another node's out()
routine, which does CGI execution.
I thought it would not work, but I wondered why. No surprise, it didn't
work this way. Some "yaws workers" with particular indexes
weren't found on the remote node, so the whole request would collapse.
I ended up creating a revproxy=[] configuration to "attach" a remote
node to the specific HTTP prefix, and then generate an internal
redirect using {page, "/prefix/" ++ Arg#arg.querydata}.
However, this is ugly. I would rather utilize some sort of Erlang'ish
trick to ask a remote node to do work for me, rather than using
a revproxy thing which doesn't even tell me when such forwarding
terminates abnormally. I could get this with rpc:call() if not
for that workers' problem.
The question is, is there a particular reason why Args couldn't
be forwarded to another system? Is there a compelling reason to
keep them this way? Wouldn't it be better if yaws instances
weren't dependent on some indexes into worker pool (as I understand
it) and instead used some intra-node pids?
--
Lev Walkin
vlm@lionet.info
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Erlyaws-list mailing list
Erlyaws-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/erlyaws-list
Post received from mailinglist |
|
|
| Back to top |
|
| tobbe |
| Posted: Mon May 26, 2008 12:52 pm |
|
|
|
User
Joined: 19 Jan 2005
Posts: 274
Location: Stockholm, Sweden
|
Lev Walkin wrote:
>
> Recently I had to create some sort of CGI load balancing. The request
> would come to some YAWS instance, validated against certain criteria,
> and then go to an appropriate node where _that_ YAWS instance would
> execute a CGI.
>
> I tried doing it by creating a .yaws file on one node invoking
> rpc:call() to forward the incoming Arg#arg to another node's out()
> routine, which does CGI execution.
Hm...that's a little bit boring.
It seems however that in: A#arg.state
you'll find: {cgistate, Worker}
where Worker just is a Pid.
So when you do your dispatch in your master node you could look
at this state entry. If it countains this cgistate-tuple, dispatch
to: node(Worker)
Totally untested though...
Cheers, Tobbe
>
> I thought it would not work, but I wondered why. No surprise, it didn't
> work this way. Some "yaws workers" with particular indexes
> weren't found on the remote node, so the whole request would collapse.
>
> I ended up creating a revproxy=[] configuration to "attach" a remote
> node to the specific HTTP prefix, and then generate an internal
> redirect using {page, "/prefix/" ++ Arg#arg.querydata}.
>
> However, this is ugly. I would rather utilize some sort of Erlang'ish
> trick to ask a remote node to do work for me, rather than using
> a revproxy thing which doesn't even tell me when such forwarding
> terminates abnormally. I could get this with rpc:call() if not
> for that workers' problem.
>
> The question is, is there a particular reason why Args couldn't
> be forwarded to another system? Is there a compelling reason to
> keep them this way? Wouldn't it be better if yaws instances
> weren't dependent on some indexes into worker pool (as I understand
> it) and instead used some intra-node pids?
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Erlyaws-list mailing list
Erlyaws-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/erlyaws-list
Post received from mailinglist |
|
|
| Back to top |
   
|
| Guest |
| Posted: Mon May 26, 2008 1:08 pm |
|
|
|
Guest
|
Torbjorn Tornkvist wrote:
> Lev Walkin wrote:
>> Recently I had to create some sort of CGI load balancing. The request
>> would come to some YAWS instance, validated against certain criteria,
>> and then go to an appropriate node where _that_ YAWS instance would
>> execute a CGI.
>>
>> I tried doing it by creating a .yaws file on one node invoking
>> rpc:call() to forward the incoming Arg#arg to another node's out()
>> routine, which does CGI execution.
>
> Hm...that's a little bit boring.
>
> It seems however that in: A#arg.state
> you'll find: {cgistate, Worker}
> where Worker just is a Pid.
>
> So when you do your dispatch in your master node you could look
> at this state entry. If it countains this cgistate-tuple, dispatch
> to: node(Worker)
Torbjorn,
am I understanding it right that "when you do your dispatch" is
something pertaining to YAWS code, not the .yaws script's one?
The problem is that I need the code to be executed on the remote
node, so dispatching it back to node(Worker) while being on my
master node does not make any sense to me.
> Totally untested though...
>
> Cheers, Tobbe
>
>> I thought it would not work, but I wondered why. No surprise, it didn't
>> work this way. Some "yaws workers" with particular indexes
>> weren't found on the remote node, so the whole request would collapse.
>>
>> I ended up creating a revproxy=[] configuration to "attach" a remote
>> node to the specific HTTP prefix, and then generate an internal
>> redirect using {page, "/prefix/" ++ Arg#arg.querydata}.
>>
>> However, this is ugly. I would rather utilize some sort of Erlang'ish
>> trick to ask a remote node to do work for me, rather than using
>> a revproxy thing which doesn't even tell me when such forwarding
>> terminates abnormally. I could get this with rpc:call() if not
>> for that workers' problem.
>>
>> The question is, is there a particular reason why Args couldn't
>> be forwarded to another system? Is there a compelling reason to
>> keep them this way? Wouldn't it be better if yaws instances
>> weren't dependent on some indexes into worker pool (as I understand
>> it) and instead used some intra-node pids?
>>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Erlyaws-list mailing list
> Erlyaws-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/erlyaws-list
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Erlyaws-list mailing list
Erlyaws-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/erlyaws-list
Post received from mailinglist |
|
|
| Back to top |
|
| tobbe |
| Posted: Mon May 26, 2008 1:31 pm |
|
|
|
User
Joined: 19 Jan 2005
Posts: 274
Location: Stockholm, Sweden
|
Lev Walkin wrote:
> Torbjorn Tornkvist wrote:
>> Lev Walkin wrote:
>>> Recently I had to create some sort of CGI load balancing. The request
>>> would come to some YAWS instance, validated against certain criteria,
>>> and then go to an appropriate node where _that_ YAWS instance would
>>> execute a CGI.
>>>
>>> I tried doing it by creating a .yaws file on one node invoking
>>> rpc:call() to forward the incoming Arg#arg to another node's out()
>>> routine, which does CGI execution.
>> Hm...that's a little bit boring.
>>
>> It seems however that in: A#arg.state
>> you'll find: {cgistate, Worker}
>> where Worker just is a Pid.
>>
>> So when you do your dispatch in your master node you could look
>> at this state entry. If it countains this cgistate-tuple, dispatch
>> to: node(Worker)
>
> Torbjorn,
>
> am I understanding it right that "when you do your dispatch" is
> something pertaining to YAWS code, not the .yaws script's one?
>
> The problem is that I need the code to be executed on the remote
> node, so dispatching it back to node(Worker) while being on my
> master node does not make any sense to me.
Hm...I just assumed that the Worker concept meant that successive
request should go to the same node (the Worker node). But perhaps
there are other dependencies that put constraints on the executing
context. I don't know that much about this code. Perhaps Klacke
can propose a solution or a fix for it.
--Tobbe
>
>> Totally untested though...
>>
>> Cheers, Tobbe
>>
>>> I thought it would not work, but I wondered why. No surprise, it didn't
>>> work this way. Some "yaws workers" with particular indexes
>>> weren't found on the remote node, so the whole request would collapse.
>>>
>>> I ended up creating a revproxy=[] configuration to "attach" a remote
>>> node to the specific HTTP prefix, and then generate an internal
>>> redirect using {page, "/prefix/" ++ Arg#arg.querydata}.
>>>
>>> However, this is ugly. I would rather utilize some sort of Erlang'ish
>>> trick to ask a remote node to do work for me, rather than using
>>> a revproxy thing which doesn't even tell me when such forwarding
>>> terminates abnormally. I could get this with rpc:call() if not
>>> for that workers' problem.
>>>
>>> The question is, is there a particular reason why Args couldn't
>>> be forwarded to another system? Is there a compelling reason to
>>> keep them this way? Wouldn't it be better if yaws instances
>>> weren't dependent on some indexes into worker pool (as I understand
>>> it) and instead used some intra-node pids?
>>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Erlyaws-list mailing list
>> Erlyaws-list@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/erlyaws-list
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Erlyaws-list mailing list
Erlyaws-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/erlyaws-list
Post received from mailinglist |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
