Using WResource Request URL Params in addition to waitForMoreData/haveMoreData not supported?
Added by d3fault d3fault over 9 years ago
Public resources (not the session-specific kind):
I can serve up custom content based on the request's url parameters (ex: /resource?x=1), but it doesn't appear to be possible when used in conjunction with waitForMoreData/haveMoreData. The underlying reason appears to be because haveMoreData is a method of WResource (and when haveMoreData is called, the resource then tells EVERY continuation (regardless of what the request parameters were) to continue). The fix would be to make haveMoreData a method of ResponseContinuation (but maybe this isn't possible for other reasons not clear to me).
Is calling haveMoreData from a user thread the correct way to do it? I read all of http://redmine.webtoolkit.eu/boards/2/topics/6658?r=7380 , but the answer didn't jump out at me. I use WServer::post to get back to Wt's thread pool for WApplication stuff, but what's the proper way to get back to the thread that WResource::handleRequest was originally called in (in order to call haveMoreData() there!)?
I can't have one public resource per custom response (ex: /resource1, /resource2, etc), because I can't know in advance all the possible values of "x".
Thanks,
d3fault
Replies (4)
RE: Using WResource Request URL Params in addition to waitForMoreData/haveMoreData not supported? - Added by Wim Dumon over 9 years ago
Hello,
This is already fixed in the git version of Wt: a response continuation does have a haveMoreData method.
Best regards,
Wim.
RE: Using WResource Request URL Params in addition to waitForMoreData/haveMoreData not supported? - Added by d3fault d3fault over 9 years ago
Sweet, thanks! The git version has lots of stuff I want :-S (cough time to whip those test monkeys cough)
I just looked at the impl. While it does appear to be threadsafe, there doesn't appear to be anything with relation to getting back to the thread that the resource was initially handled from. I suppose I could spawn an intermediate thread to at least keep the db thread from having to serve http requests (xD), but getting back to the resource's initial thread[pool] is desireable.
RE: Using WResource Request URL Params in addition to waitForMoreData/haveMoreData not supported? - Added by Koen Deforche over 9 years ago
W.r.t. release, thanks for the heads up and indeed we can't have it dragging on much longer.
As to going back to the same thread, what we're doing for the resource (continuation) is the same as for a Wt application event: there is no thread affinity and incoming requests are handled by whatever thread available in the thread pool.
Regards,
koen
RE: Using WResource Request URL Params in addition to waitForMoreData/haveMoreData not supported? - Added by d3fault d3fault over 9 years ago
Indeed, but I've passed the response continuation over to a database thread. Something like WServer::post is needed, but for [static public] resource response continuations.
d3fault