I just wanted to consult what's the best strategy for using multiple hunchentoot applications. Is it better to use one *dispatch-table* and insert multiple handlers for different application in this table or have many servers listening on different ports? I'd like to go with multiple hunchentoot:start-server, does it have any disadvantages?
Thank you, Andrew
I am not sure if there are advantages with multiple hunchentoot:start-server. However, multi-core CPUs are so common these days you might want to start two lisp images with each running a separate web application.
Most lisps support threading but cannot take advantage of multiple cores in one image.
Correct me if I'm wrong.
Regards, -- Mac
On 4/12/07, Andrei Stebakov lispercat@gmail.com wrote:
I just wanted to consult what's the best strategy for using multiple hunchentoot applications. Is it better to use one *dispatch-table* and insert multiple handlers for different application in this table or have many servers listening on different ports? I'd like to go with multiple hunchentoot:start-server, does it have any disadvantages?
Thank you, Andrew
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
My Web PC is really modest, PIII 600 MHz so it probably won't benefit from running multiple images. Basically, my question is if starting multiple hunchentoot server is a good idea here. I need some logical separations for different web applications so I am wondering what's the best way to achieve it.
Andrew
On 4/12/07, Mac Chan emailmac@gmail.com wrote:
I am not sure if there are advantages with multiple hunchentoot:start-server. However, multi-core CPUs are so common these days you might want to start two lisp images with each running a separate web application.
Most lisps support threading but cannot take advantage of multiple cores in one image.
Correct me if I'm wrong.
Regards, -- Mac
On 4/12/07, Andrei Stebakov lispercat@gmail.com wrote:
I just wanted to consult what's the best strategy for using multiple hunchentoot applications. Is it better to use one *dispatch-table* and insert multiple handlers for different application in this table or have many servers listening on different ports? I'd like to go with multiple hunchentoot:start-server, does it have any disadvantages?
Thank you, Andrew
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Thu, 12 Apr 2007 13:47:17 -0400, "Andrei Stebakov" lispercat@gmail.com wrote:
Basically, my question is if starting multiple hunchentoot server is a good idea here. I need some logical separations for different web applications so I am wondering what's the best way to achieve it.
If the two servers are doing more or less different things, I'd say it's better to have them in different Lisp images. That's certainly easier to maintain. I would only be tempted to run mutiple servers in one image if they shared a lot of code and/or data.
On Thu, 12 Apr 2007 10:34:55 -0700, "Mac Chan" emailmac@gmail.com wrote:
Most lisps support threading but cannot take advantage of multiple cores in one image.
Correct me if I'm wrong.
I think you're right. AFAIK the current exceptions are Scieneer, Corman, OpenMCL, and (on some platforms) SBCL.
In my case if I run multiple images it would be harder to maintain it because each image would use the swank, almost the same set of libraries and I'd have to think how to connect to each image via slime using different port. To me it's a bit complicated. On the other hand, if running multiple hunchentoot servers is OK in one image I would keep separate *dispatch-table* per each server and it would make a perfect logical separation for different apps. Do you think it's a reasonable approach?
Andrew
On 4/12/07, Edi Weitz edi@agharta.de wrote:
On Thu, 12 Apr 2007 10:34:55 -0700, "Mac Chan" emailmac@gmail.com wrote:
Most lisps support threading but cannot take advantage of multiple cores in one image.
Correct me if I'm wrong.
I think you're right. AFAIK the current exceptions are Scieneer, Corman, OpenMCL, and (on some platforms) SBCL. _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Thu, 12 Apr 2007 15:45:39 -0400, "Andrei Stebakov" lispercat@gmail.com wrote:
On the other hand, if running multiple hunchentoot servers is OK in one image I would keep separate *dispatch-table* per each server and it would make a perfect logical separation for different apps. Do you think it's a reasonable approach?
Yes, you'd use *META-DISPATCHER* then. Note that there are some parts of Hunchentoot (for example logging and error handling) that are currently controlled by global variables which should actually be per-server switches. You'll find some discussions related to this in the mailing list archive. This is a remnant of Hunchentoot's heritage from a single-server library (TBNL). Several users have announced to send patches to fix this but haven't sent anything yet. I'll probably clean this up one day, but it's not a big issue for me as I virtually never use multiple servers in one image.
So I need to keep track of all servers that I start and for each one return it's dispatch-table something like this?: (defvar *server1* (start-server :port 3001....) (defvar *server2* (start-server :port 3002....) (setq *meta-dispatcher* (lambda (server) (declare (ignore server)) (if (eql server *server1*) *dispatch-table1* *dispatch-table2*)))
Why can't start-server take a dispatch-table as a parameter?
Andrew
On 4/12/07, Edi Weitz edi@agharta.de wrote:
On Thu, 12 Apr 2007 15:45:39 -0400, "Andrei Stebakov" lispercat@gmail.com wrote:
On the other hand, if running multiple hunchentoot servers is OK in one image I would keep separate *dispatch-table* per each server and it would make a perfect logical separation for different apps. Do you think it's a reasonable approach?
Yes, you'd use *META-DISPATCHER* then. Note that there are some parts of Hunchentoot (for example logging and error handling) that are currently controlled by global variables which should actually be per-server switches. You'll find some discussions related to this in the mailing list archive. This is a remnant of Hunchentoot's heritage from a single-server library (TBNL). Several users have announced to send patches to fix this but haven't sent anything yet. I'll probably clean this up one day, but it's not a big issue for me as I virtually never use multiple servers in one image. _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Thu, 12 Apr 2007 16:13:20 -0400, "Andrei Stebakov" lispercat@gmail.com wrote:
So I need to keep track of all servers that I start and for each one return it's dispatch-table something like this?: (defvar *server1* (start-server :port 3001....) (defvar *server2* (start-server :port 3002....) (setq *meta-dispatcher* (lambda (server) (declare (ignore server)) (if (eql server *server1*) *dispatch-table1* *dispatch-table2*)))
No, you don't have to do it like this. There are certainly more intelligent ways to do it. I'd use something like
(lambda (server) (case (server-local-port server) (3001 *dispatch-table1*) (3002 *dispatch-table2*)))
Why can't start-server take a dispatch-table as a parameter?
Did you read my last reply?
If there's a feature in an open source project you want to have that's not provided, you can hack it yourself and send a patch, or you can pay someone else to do it, or you can complain about it on the mailing list. You can try to figure out yourself which of these alternatives is the most promising.
I am sorry I gave an impression that I was complaining. I just thought it was logical to do so if every server has its own dispatch-table. There is probably a reason why it's done differently so I wanted to understand why. I am sure, if I come up with something useful I'll make a patch and send it to the list. Currently I am just a beginner trying to learn lisp and you guys are awesome in what you do for the community and for me personally.
Thank you, Andrew
On 4/12/07, Edi Weitz edi@agharta.de wrote:
On Thu, 12 Apr 2007 16:13:20 -0400, "Andrei Stebakov" lispercat@gmail.com wrote:
So I need to keep track of all servers that I start and for each one return it's dispatch-table something like this?: (defvar *server1* (start-server :port 3001....) (defvar *server2* (start-server :port 3002....) (setq *meta-dispatcher* (lambda (server) (declare (ignore server)) (if (eql server *server1*) *dispatch-table1*
*dispatch-table2*)))
No, you don't have to do it like this. There are certainly more intelligent ways to do it. I'd use something like
(lambda (server) (case (server-local-port server) (3001 *dispatch-table1*) (3002 *dispatch-table2*)))
Why can't start-server take a dispatch-table as a parameter?
Did you read my last reply?
If there's a feature in an open source project you want to have that's not provided, you can hack it yourself and send a patch, or you can pay someone else to do it, or you can complain about it on the mailing list. You can try to figure out yourself which of these alternatives is the most promising. _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On 4/12/07, Andrei Stebakov lispercat@gmail.com wrote:
So I need to keep track of all servers that I start and for each one return it's dispatch-table something like this?: (defvar *server1* (start-server :port 3001....) (defvar *server2* (start-server :port 3002....) (setq *meta-dispatcher* (lambda (server) (declare (ignore server)) (if (eql server *server1*) *dispatch-table1* *dispatch-table2*)))
This is more or less exactly the approach I've been taking. The advantage, of course, is largely in memory usage, the disadvantage is in the trouble involved in keeping track of it all. You can, if you like, put different sites in different packages, then just do site1:*dispatch-table*, site2:*dispatch-table* etc. in the above, the advantage being that you can then easily develop and test each site in its own package. Rob
Yes, Robert, this is exactly the way I am going now. So far looks good and doesn't seem to promise any maintenance problems.
Thank you, Andrew
On 4/12/07, Robert Synnott rsynnott@gmail.com wrote:
On 4/12/07, Andrei Stebakov lispercat@gmail.com wrote:
So I need to keep track of all servers that I start and for each one
return
it's dispatch-table something like this?: (defvar *server1* (start-server :port 3001....) (defvar *server2* (start-server :port 3002....) (setq *meta-dispatcher* (lambda (server) (declare (ignore server)) (if (eql server *server1*) *dispatch-table1* *dispatch-table2*)))
This is more or less exactly the approach I've been taking. The advantage, of course, is largely in memory usage, the disadvantage is in the trouble involved in keeping track of it all. You can, if you like, put different sites in different packages, then just do site1:*dispatch-table*, site2:*dispatch-table* etc. in the above, the advantage being that you can then easily develop and test each site in its own package. Rob _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Scribit Andrei Stebakov dies 12/04/2007 hora 16:13:
So I need to keep track of all servers that I start and for each one return it's dispatch-table something like this?:
I suppose you could take advantage of the fact the global variables are dynamic ones:
(defvar *dispatch-table1* ...) (defvar *dispatch-table2* ...)
(let ((*dispatch-table* *dispatch-table1*)) (start-server :port 8001))
(let ((*dispatch-table* *dispatch-table2*)) (start-server :port 8002))
I didn't try this code, though, it's just what seemed natural to me for this use.
Quickly, Pierre
On Fri, 13 Apr 2007 12:50:34 +0200, Pierre THIERRY nowhere.man@levallois.eu.org wrote:
I suppose you could take advantage of the fact the global variables are dynamic ones:
(defvar *dispatch-table1* ...) (defvar *dispatch-table2* ...)
(let ((*dispatch-table* *dispatch-table1*)) (start-server :port 8001))
(let ((*dispatch-table* *dispatch-table2*)) (start-server :port 8002))
I didn't try this code, though, it's just what seemed natural to me for this use.
That won't work because of MP. You'd have to use implementation-specific facilities like this one:
http://www.lispworks.com/documentation/lw50/LWRM/html/lwref-399.htm
I've been using up to several separate Hunchentoot images per server with no problems. I usually run them with a script (without swank) and gnu screen.
The only thing I have ever had issues with is being careless with RAM, but that was my application's fault entirely.
-
Andrei Stebakov -
Edi Weitz -
Mac Chan -
Pierre THIERRY -
Robert Synnott -
Yoni Rabkin Katzenell