clsql store thread safety
Jan Rychter
that the only way for them to happen is if something got seriously
corrupted.
Am I correct in understanding that the current weblocks with clsql store
will crash and burn because it isn't threadsafe?
(all it took in my case was one googlebot and me clicking in the app)
Since I'm lazy, I figured I'd check here for quick advice -- if I pull
this:
https://www.bitbucket.org/S11001001/weblocks-clsql-fluid/changeset/e453eb9183bf/
will I be fine? Or is there more to it?
--J.
Stephen Compall
> Since I'm lazy, I figured I'd check here for quick advice -- if I pull
> this:
> https://www.bitbucket.org/S11001001/weblocks-clsql-fluid/changeset/e453eb9183bf/
>
> will I be fine? Or is there more to it?
See this thread:
http://groups.google.com/group/weblocks/browse_thread/thread/4082b437543fa262
As well as bug #61.
Problem reports should probably be appended to #61. hfsbo.com has been
running it for a few days and all seems well.
--
Sorry but you say Nibiru is a Hoax? Doesnt Exist? So maybe The
Sumerian people doesnt exist also! --Anonymous by way of SkI
Jan Rychter
> Jan Rychter <j...@rychter.com> writes:
>> Since I'm lazy, I figured I'd check here for quick advice -- if I pull
>> this:
>> https://www.bitbucket.org/S11001001/weblocks-clsql-fluid/changeset/e453eb9183bf/
>>
>> will I be fine? Or is there more to it?
>
> See this thread:
>
> http://groups.google.com/group/weblocks/browse_thread/thread/4082b437543fa262
Oops, I seem to have missed it. Thanks!
> As well as bug #61.
>
> Problem reports should probably be appended to #61. hfsbo.com has been
> running it for a few days and all seems well.
Thanks. I will start using it immediately.
I am rather appalled at the fact that weblocks with clsql is broken out
of the box. I think this very clearly marks it as very experimental
software, and issues such as backwards compatibility become moot. We
still have a long way to go.
--J.
Stephen Compall
> I am rather appalled at the fact that weblocks with clsql is broken
> out of the box. I think this very clearly marks it as very
> experimental software, and issues such as backwards compatibility
> become moot. We still have a long way to go.
The only reason I didn't merge the branch already is that I wanted to
give some existing users a chance to try it out before forcing all CLSQL
users to add Bordeaux-Threads and CLSQL-Fluid to their systems.
Note that this applies also to Elephant users; see that thread I linked.
Considering that this particular bug is only really observable after
deployment, and the fix to Weblocks code itself is so minor, I don't
think this particular bug says much about the quality of the code
itself; just that deployment on the CLSQL backend is new. Which it is;
as far as I know hfsbo.com is the first.
Leslie P. Polzer
> I am rather appalled at the fact that weblocks with clsql is broken out
> of the box. I think this very clearly marks it as very experimental
> software, and issues such as backwards compatibility become moot. We
> still have a long way to go.
You can't take an arbitrary part of a large system and use it to judge
the whole system.
For example I don't use CLSQL at all, and Slava probably didn't
test it very thoroughly either. I believe only recently people
(you, Yarek, Stephen) have started using it for real-world
apps.
Not so with other parts: I have used views extensively enough
to fix some serious problems with them (although not on the
design level), for example.
Jan Rychter
> Jan Rychter <j...@rychter.com> writes:
>> Since I'm lazy, I figured I'd check here for quick advice -- if I pull
>> this:
>> https://www.bitbucket.org/S11001001/weblocks-clsql-fluid/changeset/e453eb9183bf/
>>
>> will I be fine? Or is there more to it?
>
> See this thread:
>
> http://groups.google.com/group/weblocks/browse_thread/thread/4082b437543fa262
>
> As well as bug #61.
>
> Problem reports should probably be appended to #61. hfsbo.com has been
> running it for a few days and all seems well.
Stephen,
Where do I find your bordeaux-threads changes? They haven't been
integrated into the bordeaux-threads devel tree yet.
--J.
Stephen Compall
> Where do I find your bordeaux-threads changes? They haven't been
> integrated into the bordeaux-threads devel tree yet.
--
You know...
Jan Rychter
Argh, I missed that. Sorry.
You wrote:
About clsql:default-database: weblocks-clsql doesn't call clsql:connect
anymore, so default-database doesn't get set to the resulting
database. I think this change is good, because relying on it is a good
way to break one of two DB-backed webapps when they run together. If you
use it (as I do), it's easy to bind it in an :around-method on
handle-client-request; anyway, if there are serious objections to this,
I'll add the old behavior back.
Would you be willing to provide an example of such an :around method?
I'm sorry, but I've been trying to understand just how to get from a
*default-store* which is an instance of fluid-database to working select
statements (e.g. *default-database*) and I figured I'd rather ask you
rather than hunt around trying to understand exactly how clsql works.
Should I call clsql:connect on every request? But then connect expect a
connspec...
--J.
Stephen Compall
> Would you be willing to provide an example of such an :around method?
(defmethod handle-client-request :around ((app my-app))
(let ((clsql:*default-database* *my-app-store*))
(call-next-method)))
> I'm sorry, but I've been trying to understand just how to get from a
> *default-store* which is an instance of fluid-database to working select
> statements (e.g. *default-database*)
API. The above is all you need to do select calls with the implied
database argument.
--
You know...
Jan Rychter
Thanks, I didn't realize it was that simple.
It seems to work well so far, no problems encountered yet, and the
corruption I was seeing seems to be gone. But, it's too early to tell.
I would like to stress-test the app, but ab won't follow redirects, and
weblocks insists on the following sequence:
[22:53] tnuctip:/tmp>wget http://localhost:8080/
--2009-01-11 22:53:42-- http://localhost:8080/
Resolving localhost... 127.0.0.1, ::1
Connecting to localhost|127.0.0.1|:8080... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: http://localhost:8080/?weblocks-g1295=7200%3A81B0BBBE07A6F69F284A01DB31BD6F81 [following]
--2009-01-11 22:53:42-- http://localhost:8080/?weblocks-g1295=7200%3A81B0BBBE07A6F69F284A01DB31BD6F81
Connecting to localhost|127.0.0.1|:8080... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: http://localhost:8080/ [following]
--2009-01-11 22:53:42-- http://localhost:8080/
Connecting to localhost|127.0.0.1|:8080... connected.
HTTP request sent, awaiting response... 200 OK
Length: 14573 (14K) [text/html]
Saving to: `index.html'
100%[================================================================================>] 14,573 --.-K/s in 0s
2009-01-11 22:53:42 (366 MB/s) - `index.html' saved [14573/14573]
[22:53] tnuctip:/tmp>
... which I think is rather strange and merits looking into on its own.
Many thanks for your work on clsql-fluid!
--J.
Stephen Compall
> Many thanks for your work on clsql-fluid!
Thanks, this is now merged into dev.
All users of dev and the CLSQL store: loading weblocks-clsql will fail
if you don't have clsql-fluid, from either the Git branch or the Darcs
standalone repo, in your ASDF systems. Both versions now include the
bordeaux-threads fluids, so you don't need the bordeaux-threads patch.
See http://www.cliki.net/clsql-fluid
Leslie P. Polzer
> I would like to stress-test the app, but ab won't follow redirects, and
> weblocks insists on the following sequence:
Both curl-loader (or plain curl) and siege will do for testing
Weblocks apps.