[Mojolicious] Forward-streaming a streaming HTTP resource ("processing proxy")
Dear all,
basically what I want to achieve is this:
1. App gets an "EventSource" javascript request with some query param
from client
2. App sends a HTTP request to a backend server with that query
3. Backend server sends blocks of data in a streaming, long-running
response (HTTP 1.0; currently not "chunked transfer")
4. App retrieves data fragments until it has aggredated a complete block
5. App parses data block, sends transformed data as "Server sent Event"
to client
6. GOTO 4 unless backend server finishes its response
My idea was to create a transaction
my $tx = $ua->build_tx( GET => '...');
then have a "progress" event handler to aggregate the response chunks
my $chunk;
$tx->res->on("progress" => sub {
# add new data to chunk
# test if chunk contains complete block
# if no: return from sub
# if yes: process block, then $c->write( "event: block\ndata:
$data\n\n" );
}
and a finish handler to clean up
$tx->res->on("finish" => sub {
# check $chunk for leftovers
$c->write( "event: resultend\ndata: -\n\n");
$c->finish;
});
And finally to start the backend transaction:
$ua->start($tx);
This worked in so far as that the events shown above were processed, but
the client only ever received a reponse after the backend transaction was
closed.
I then realised that that´s because the backend transaction is called in a
blocking way.
My - maybe naive - idea then was to remove the "finish" handler for the
backend transaction and move it´s functionality to the callback for "start":
$tx->res->on("progress" => sub {
my $res = shift;
warn "progress event: " . $res->body_size; # never seen on STDERR
});
$ua->start( $tx => sub {
my ($ua, $tx) = @_;
warn $tx->is_finished; # always 1
$c->write( "event: resultend\ndata: -\n\n");
$c->finish;
});
But now the "progress" handler no longer gets called while on the other
hand the callback to "start" is called apparently immediately and the
transaction is marked as "finished".
Could somebody please tell me
a) if what I want to achieve is possible at all and
b) provide some hints of what I´m missing and how it could be done?
If it´s not possible with a http server backend, could it be a solution to
hand of the http backend communication to a different process (Minion
perhaps) which would update a Redis queue and then have my app read from
the redis queue and send the data from there to the client?
Or are there even better solutions?
Thanks!
Heiko
--
You received this message because you are subscribed to the Google Groups
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: Forward-streaming a streaming HTTP resource ("processing proxy")
Am Montag, 21. September 2015 18:27:49 UTC+2 schrieb sri: > > This might be helpful. > > > http://mojolicio.us/perldoc/Mojolicious/Guides/Cookbook#Streaming-response > I´m afraid it isn´t. Unless I´m just acting blockheaded and miss something glaringly obvious, that is the part of the problem I considered solved. Hopefully I simply failed at describing the problematic part, so let´s try this again. I created a gist with some code which hopefully helps to explain the situation. https://gist.github.com/heikojansen/b3598e5747a38a084ac9 There´s a backend server and two apps which show my approaches for creating the middleware app. First start the backend server, then start one of the "proxies" and run curl 'http://127.0.0.1:3000/backend' -H 'Accept: text/event-stream' in your shell or point your browser to http://127.0.0.1:3000/page Upon request "proxy1.pl" opens a connection to the backend server, retrieves the data in a series of "read" events and sends the data to the client (browser). Unfortunately, the transformed results shows in the browser only after the final part of the backend server response has been received and processed and not almost immediately after the data processing in the proxy, as desired. "proxy2.pl" only writes start() callback; tx finished? 1 to STDERR and immediately finishes processing without even sending a request to the backend. Currently I have no idea, what I should change or which other approach I should take to get the desired immediate forwarding of the transformed result. Thanks again for any hint Heiko -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at http://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: Forward-streaming a streaming HTTP resource ("processing proxy")
Am Montag, 21. September 2015 22:56:52 UTC+2 schrieb sri:
>
> Just replace "$tx = $ua->start($tx);" with "$ua->start($tx => sub { my
> ($ua, $tx) = @_; ... });" and buffer incoming bytes.
>
That´s what I thought I did in "proxy2.pl".
Am Montag, 21. September 2015 23:01:06 UTC+2 schrieb sri:
>
> Your $ua might also be going out of scope.
>
Ouch. And that´s the obvious thing I missed.
Moving the line
my $ua = Mojo::UserAgent->new();
out of the scope of the sub fixed the problem neatly.
Thanks!
Heiko
--
You received this message because you are subscribed to the Google Groups
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Request-ID logging possible with asynchronous request handling?
I believe this question has been asked before and the person who asked was told that what he wanted wasn´t feasible - but I cannot right now find the conversation. Also, maybe some influencing factor has changed so perhaps nowadays there is a solution possible for what follows? Our HTTP front end (nginx with mod_txid) generates unique IDs for incoming requests. We pass this request ID onward to our main app and to a few back end systems who all include it in their log messages. Combining this with high resolution time stamps we´re able to trace a request through all systems and can, e.g., easily find out for error messages in back end systems what the user input in the corresponding HTTP request was. Logging is done via Log4perl and the request id is included in every log message through the MDC singleton in Log4perl. Unfortunately this does not work when we make use of asynchronous request handling features in Mojolicious. The MDC store is process-global, but there are multiple requests being worked on in the same process. We could include the request ID manually in every log message we create, but that´s cumbersome and it still wouldn´t get the id in any message that´s generated directly by Mojolicious. Since the log calls are method calls on the App instance and not on the controller there is apparently no way to access the request context even if we monkey-patch the log method in the app. Still, it would come in really handy if what I´ve tried to describe could be made to work in Mojolicious. Is there anything we´ve missed? If not, are there any plans for changing Mojolicious internals which could enable us to get it to work? Thx! Heiko -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at http://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: Mojolicious::Lite websocket connection problem
According to
https://metacpan.org/diff/file?target=SRI%2FMojolicious-6.23%2F&source=SRI%2FMojolicious-6.22%2F#lib/Mojo/Transaction/WebSocket.pm
up to v6.22 an incoming protocol selection ("Sec-WebSocket-Protocol"
header, 3rd argument to "new WebSocket()" in your client) was automatically
copied to the response headers.
That´s no longer the case and I assume your client automatically closes the
connection if the subprotocol negotiation fails.
Apparently you have to manually select the appropriate subprotocol your
server supports and add that to your response (which makes sense, since
it´s an application specific decision and nothing Mojolicious can / should
do for you generically).
HTH
Heiko
--
You received this message because you are subscribed to the Google Groups
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: Mojo::Lite + AJAX exception handling / exception design pattern
Throwing the exception leads to a response code "500" for the ajax request; since code 500 signals an error the "fail" handler for the ajax request get´s triggered. That of course does not mean that the content returned from the mojo server is rendered in your page; it was an ajax request after all, so rendering any content in the browser would be the responsibility of your javascript code in myapp_fail. By the way: blindly rendering the response from the server to your user imho does not make much sense: something unexpected may have gone wrong server side so you cannot be sure what kind of error you got and if it was one you triggered on purpose like in your code show above. If you add "location.href='/exception';" in the myapp_fail function then this happens: 0) You make your ajax request to the server 1) the exception template is rendered because of your "throw" 2) your server sends a code 500 response with the content from the exception template 3) your javascript library receives a response with a status code indicating a server side processing error and calls the fail handler 4) your ajax fail handler receives the rendered output of the exception template and does something with it (or not) 5) you modify "location.href" 6) the browser now makes a regular (non-ajax) request to the new URL in location.href which happens to be "/exception" 7) your server receives the request 8) something goes wrong and the exception template is rendered because of some internal error 9) the browser receives the output and displays it Of course the response your browser receives in step 9 is in no way connected to the exception you threw in step 0. After step 7 I´m not completely sure what happens; apparently you did create a callback for the route "/exception" (at least I believe so, because of the "in /exception" debug log message) but I don´t think that there´s any automatic connection between a route of that name and the internal exeception handling template. That´s probably the reason why the server generates a "501 Not Implemented" response. In the end I believe the problem is less with using mojolicious but more so with some lack of understanding how ajax works and about the statelessnes of HTTP. Hope I could point you in the right direction - heiko -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at https://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: Mojo::Lite + AJAX exception handling / exception design pattern
Am Mittwoch, 23. März 2016 15:57:32 UTC+1 schrieb ddal...@gmail.com: > A more general question, is this a good way to handle exceptions caught in > mojo callback functions? An alternative would be to not throw an > exception and instead, render error data that gets returned to the .ajax > .done handler (200 response code). The .done handler is then responsible > to detect the error values and display an error message to the user. This > would not generate the 500 response code which could still be thrown by the > http server. > Oh my, I´m always struggling with that question myself. :-] I honestly don´t know if there´s a "correct" answer to that question. There´s those - especially with a REST background - who say that you should use the HTTP status codes for signalling application state. And then there´s those who tell you that if your code handled the situation then you should go with a HTTP status code indicating success and put error codes in app specific data structures; leaving HTTP status codes and especially error codes for those situations where your server side code didn´t cope with the situation. Of course you could also use a HTTP error status _and_ return a data structure with additional information. The answer may even depend on wether you´re talking about an API or a user interface. Maybe it´s just again a case of "select one option and stick with it". Or maybe someone in this group with more experience can chime in and give some better advice... I would be interested in hearing it, too. - Heiko -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at https://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: Mojo::Lite + AJAX exception handling / exception design pattern
Am Mittwoch, 23. März 2016 15:57:32 UTC+1 schrieb ddal...@gmail.com:
>
>
> 1) In the Mojo callback function (/price route), invoking
> Mojo::Exception->throw(message) triggers the rendering of the
> exception.development.html.ep template from the __DATA__ section. In the
> template, the thrown message can be accessed as <%= $exception->message %>.
> 2) The rendered exception html (with the thrown message) is returned (with
> a 500 response code) to the javascript / jquery script, caught by the.ajax.
> fail handler, and accessable in the jqXHR object as jqXHR.responseText
>
Some more thoughts on this:
1) Remember that once you switch to production mode a different template
("exception.production.html.ep") is used.
2) Also, if you modify the default exception template and an unexpected (by
you) failure occurs during a regular request from a user, then the user
will get to see a response based on the modified template. Since you
intended that to be consumed by your javascript code it won´t make much
sense for the user.
3) I´d suggest having a look
at
http://mojolicious.org/perldoc/Mojolicious/Guides/Rendering#Rendering-exception-and-not_found-pages.
Maybe explicitly selecting the appropriate template (and manually setting
the response status code) is a more robust approach than relying on the
standard exception templates.
- Heiko
--
You received this message because you are subscribed to the Google Groups
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: Validation before posting to an external site
Am Dienstag, 5. April 2016 18:42:03 UTC+2 schrieb Stuart Dodds: > > However, once the validation has passed, I am not sure how to then issue > the original POST request to the external site as well as redirecting the > user along with the request. Is there a way I can do this? > 1) You could send a HTTP 307 redirect to your user with the URL of the external site; since all data from the form will be re-send by the browser, the external site will also receive the captcha info - which may or may not cause problems. 2) Depending on the external site you could also make the POST request to the external site yourself and forward the response to your user; obviously that will not work if the external site requires a cookie or some other authentication from the user or if there are additional interactions to be performed by the user after receiving the result. If the external site responds to the POST request with a GET redirect you can send your user there by re-using the URL for your own HTTP 303 redirect. 3) A more fragile approach would be you returning a page with the verified and cleaned-up data in a HTML form plus some JavaScript to automatically submit that form to the external site once it loads in the browser of your user. Of course, since with solutions 1 and 3 the data exchange happens directly between your user and the external site any validation and sanitation you perform is essentially moot since there´s nothing preventing a malicious user from tinkering with it even after it was checked by you. HTH - Heiko -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at https://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: Validation before posting to an external site
Am Mittwoch, 6. April 2016 12:18:01 UTC+2 schrieb Stuart Dodds: > > First of all, it never even crossed my mind to try to change the form > method to GET until you mentioned it in your second point. So I tried it > out and it worked! Now I can build the url after the successful validation > and use the redirect_to method to send the user off to paypal with the > required parameters...thanks for the suggestion! > To be precise, I actually never mentioned transforming the _submission_ of the form to a GET request (or a redirect employing a GET request)! Requests changing server-side state should be POST-Requests plus you don´t want to have the parameters show up in the URL field of the browser, webserver logs etc. _IF_ you could send the POST request from your server to the external site (no authentication issues etc.) and _IF_ the external site used a Redirect-after-POST strategy, _THEN_ you could have re-send the redirect URL received from the external site (as answer to your POST request) onwards to your user. That´s what I tried to describe in strategy 2 - so there´s quite a few preconditions to meet to make strategy 2) a viable solution... Heiko -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at https://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: Using IO::Loop on websocket connection
Am Montag, 2. Mai 2016 17:20:47 UTC+2 schrieb Matija Papec:
>
>
> I want to read from redis in non-blocking way and delay() looks like first
> choice for this kind of task (event callbacks are closures to session
> related variables).
>
Using delay() for non-blocking handling of requests (or more specifically
websocket messages) is fine;
the question was why you try to define the event handlers inside some delay
step.
I´d suggest re-reading the relevant docs
(http://mojolicious.org/perldoc/Mojolicious/Guides/Tutorial#WebSockets and
http://mojolicious.org/perldoc/Mojolicious/Guides/Cookbook#WebSocket-web-service).
Haven´t use websockets myself, yet, but something like this should be ok
(untested!):
websocket '/ws/:sessid' => sub {
my ($c) = @_;
my $sessid = $c->stash('sessid');
$c->on(finish => sub { warn "disconnect\n" });
$c->on(json => sub {
my ($c, $msg) = @_;
warn "incoming ws json for session $sessid\n";
$c->delay(
sub { my $delay = shift; ... read from redis, pass it to delay
... },
sub { my ( $delay, $data_from_redis ) = @_; ... do something
with data ... },
);
});
};
If that´s nonsense, somebody please correct me...
--
You received this message because you are subscribed to the Google Groups
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
Re: [Mojolicious] How to send a websocket message from a post?
Am Montag, 9. Mai 2016 04:58:21 UTC+2 schrieb Lachlan Deck: > If I do need multi-threaded support in future, where would I look? > Be aware that there´s usually no "multi-threading" in the context of Mojolicious, but asynchronous processing in multiple processes. The solution given should work with, e.g., Morbo, where a single process handles all connections. IMHO, it won´t work in a production environment with Hypnotoad, because there you have a bunch of server processes and there´s no guarantee that the POST request will be handled by the same server process which controls the open websocket connection. >From the incoming POST request you could transfer some data to an external service and in every server process you could start a loop looking for new data there for those websocket connections managed by the respective hypnotoad process (maybe use https://metacpan.org/pod/Mojo::Redis2#Pub-sub here). - heiko -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at https://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: Basic non-Lite WebSocket Application
Am Sonntag, 15. Mai 2016 18:17:47 UTC+2 schrieb john: > > I have written mojo lite based websocket applications but am having > problems with my first attempt at a full application: > > https://github.com/john-/mojo_inotifier > Try changing Actions.pm, L13 from my $self => shift; to my $self = shift; ? -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at https://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: translate curl command to Mojo::UserAgent
Am Donnerstag, 19. Mai 2016 20:46:20 UTC+2 schrieb Jim Hall: > > > It looks like the following line is useless: > IO::Socket::SSL::set_defaults(SSL_verify_mode => 'VERIFY_NONE'); > I´m pretty sure VERIFY_NONE should be a constant, not a string?! - Heiko -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at https://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: Mojolicious flow
Don´t really understand from your description what happens where and which component logged what - but since that logging output does not look as if it was written by Mojolocious my first question would be: could there be any reverse proxy involved, rewriting incoming requests for an upstream Mojolicious server? - Heiko -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at https://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: Keeping Route Logic Alive
Am Dienstag, 24. Mai 2016 13:51:42 UTC+2 schrieb john: > > What confuses me is that I was previously using Mojo::Pg::PubSub and > this works: > I think it works like this: https://metacpan.org/source/SRI/Mojo-Pg-2.27/lib/Mojo/Pg/PubSub.pm#L14 keeps a reference to the callback inside the Mojo::Pg::PubSub object. And the Mojo::Pg::PubSub object is referenced from Mojolicious. So the reference counter of the callback does not reach 0. In your Inotifier code nothing outside wsinit() retains a reference to the callback once wsinit() is left (the Inotifier::Model::FileWatch theoretically might, but that object also gets destroyed when leaving wsinit()). -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at https://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
[Mojolicious] "Premature connection close" errors with final Mango request in IOLoop delay
I´m trying to chain a bunch of requests to a MongoDB server by utilizing Mojo::IOLoop->delay; unfortunately the last Mango command (and only the last one) always returns the error "Premature connection close". With MANGO_DEBUG=1 I can see that the last command gets written to the MongoDB connection and in the the mongod output I can also see that it is retrieved and executed. But Mango never logs the response data. Apparently it does not matter which command is used as the last one. I tried to provide a minimal test case with dummy commands here: https://gist.github.com/heikojansen/3aec5349e7fcc009a420a69a3f8271eb I don´t know if it´s a bug in Mango or if I´m lacking some vital understanding how the event loop works... Thx in advance for any hints and suggestions! - Heiko -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at https://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: "Premature connection close" errors with final Mango request in IOLoop delay
Am Mittwoch, 6. Juli 2016 13:23:28 UTC+2 schrieb Alexey Stavrov: > > Your local variable $m destroyed in third step of delay. Add something > like "$c->stash(m => $m);" before IO::Loop->delay; > Damn. Again. ;-( Well, the demo in the gist can be fixed by pulling "my $m = Mango->new();" out of the anonymous sub so it´ll survive the request. Given that I get the same error within the real app code it´s quite probably the same problem. Since the code there is a bit more complicated it´s not quite as obvious where things go wrong so I´ll have to dig in and see what variable goes out of scope where. But now that I know what I´m looking for... Thanks for the hint! - Heiko -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at https://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: Mojo::Reactor::Poll: I/O watcher failed: Can't call method "build_tx" on an undefined value at C:/Perl64/site/lib/Mojo/Server.pm line 23.
Am Freitag, 7. Oktober 2016 21:52:26 UTC+2 schrieb petra:
>
> [...]
> And do instruction from this page
> http://mojolicious.org/perldoc/Mojolicious/Guides/Growing
>
> But after section *Simplified application script *and running test, I got
> such error:
>
> t/login.t .. Mojo::Reactor::Poll: I/O watcher failed: Can't call method
> "build_tx" on an undefined value at C:/Perl64/site/lib/Mojo/Server.pm line
> 23.
> # Premature connection close
>
> # Failed test 'GET /'
> # at t/login.t line 21.
>
As far as I understand it, the problem is that "myapp.pl" at this step no
longer implements the app by itself, but loads it from a module by its name.
The test file still expects to have access to the app by "require"ing the
start script, but that no longer works.
In order to have the tests succeed again you have to tell Test::Mojo which
app to load.
In other words:
Line 9 in login.t still reads:
my $t = Test::Mojo->new();
But you have to add the name of the app, so it reads:
my $t = Test::Mojo->new('MyApp');
HTH
- Heiko
--
You received this message because you are subscribed to the Google Groups
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: writing chunks in non-blocking mode
I´m not sure if I understand your workflow correctly but how about this: for every row processed send a small JSON documents to the browser which contains information on the worksheet, row and row status and then have some JavaScript code in the browser assemble and update the correct HTML table (inserting another row)? I´d probably render a skeleton HTML page as response to the upload of the Excel file, then start a new AJAX request from that page which triggers the processing of the spreadsheet uploaded previously and receives the processing status as "server-sent events" (cf. http://www.w3.org/TR/eventsource/). Heiko -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at https://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: writing chunks in non-blocking mode
Am Freitag, 14. Oktober 2016 01:06:57 UTC+2 schrieb Steve Barnsley: > > I tried 'wrapping' the list of calls to the various templates in a > $c->delay(@list); structure, this causes the first template (table) to > execute in its entirety but it never starts the second entry in the list > (even though I see the result from the very last statement in the sub in > $list[0].) Is there some magic that I need to invoke to make delay start > the next item in the list? > Without any deeper knowledge of your code that´s a tough question. @list is a list of subroutine references, right? You do call $delay->begin in every callback in that list, don´t you? Otherwise, like https://metacpan.org/pod/Mojo::IOLoop::Delay#steps says: "This chain will continue until ... a callback does not increment the event counter ..." -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at https://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
Re: [Mojolicious] Nginx and Hypnotoad proxy correct config
Did not try to verify this, but if I understand your example config correctly it may be related to the way nginx processes "location" directives. To quote http://nginx.org/en/docs/http/request_processing.html nginx first searches for the most specific prefix location given by literal > strings regardless of the listed order. In the configuration above the only > prefix location is “/” and since it matches any request it will be used > as a last resort. Then nginx checks locations given by regular expression > in the order listed in the configuration file. The first matching > expression stops the search and nginx will use this location. If no regular > expression matches a request, then nginx uses the most specific prefix > location found earlier. HTH - Heiko -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at https://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: Incorrect originating IP from $c->tx->remote_address() on requests via nginx reverse proxy
As far as I understand it, this is what happens:
Step 1:
http://nginx.org/en/docs/http/ngx_http_realip_module.html#real_ip_header =>
"Defines the request header field whose value will be used to replace the
client address."
So in your config you tell nginx to treat the value of the header "
X-Forwarded-For" from the incoming client request as the "real ip".
Step 2:
Then with "proxy_set_header X-Real-IP $remote_addr;" you tell nginx to send
the "fake real ip" from "Step 1" as the value of the header "X-Real-IP" to
your Mojo app.
Unless you have another reverse proxy in front of your nginx I´d say you
should simply remove the "real_ip_header" and "real_ip_recursive"
directives from your nginx config and everything should work as expected
(as long as you tell your Mojo server that it sits behind a reverse proxy).
In any case "$controller->req->headers->header('X-Real-IP')" should now
give you the original client IP.
HTH
- Heiko
--
You received this message because you are subscribed to the Google Groups
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: Incorrect originating IP from $c->tx->remote_address() on requests via nginx reverse proxy
Hmmm.
I have "proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;" in my
nginx conf and apparently no other related directives.
Starting the Mojo server via
MOJO_REVERSE_PROXY=1 carton exec -- morbo script/app
and having these statements in my code:
warn " remote addr: " . $c->tx->remote_address . "\n";
warn "original remote addr: " . $c->tx->original_remote_address . "\n";
warn " x-forwarded-for: " .
$c->tx->req->headers->header('X-Forwarded-For') . "\n";
I get this:
remote addr: 10.1.0.40
original remote addr: 127.0.0.1
x-forwarded-for: 10.1.0.40
The nginx runs on the same host as the mojo app and 10.1.0.40 is my desktop
pc accessing the nginx.
There´s no other proxy between me and the nginx so having only one ip in
"X-Forwarded-For" is what is to be expected.
So everything looks good to me:
$c->tx->remote_address respects the "running behind proxy" setting and
gives me the ip of the client.
$c->tx->original_remote_address gives me the ip from the original (proxy)
request to the Mojolicious server.
If I omit MOJO_REVERSE_PROXY=1 I get:
remote addr: 127.0.0.1
original remote addr: 127.0.0.1
x-forwarded-for: 10.1.0.40
Maybe you misunderstood what "original" in "original_remote_address" means?
It´s not about the client request to the proxy but about the original
request to Mojolicious without Mojolicious helpfully interfering to protect
any code using "remote_address()" from changes by being deployed either
behind a reverse proxy or not.
Best,
Heiko
--
You received this message because you are subscribed to the Google Groups
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Updating config object when config database is updated
Hi *,
we're working on an app with some extensive config data which also needs
some preprocessing (merging defaults etc.) to become usable.
We use a plugin ("register" method) to initialise a config object on app
start and keep it around, as recreating the config on every incoming
request would be to costly.
However, the config data - held in a few MongoDB documents - might be
updated anytime via scripts and/or a web admin GUI and it would be expected
that these changes take effect immediately (or at least within a short time
frame).
On the other hand the number of updates is expected to be fairly low;
perhaps 50 times per day.
So we need to find an effective way to trigger a recreation of the config
object in all Hypnotoad child processes.
I can see a few options for that; e.g.
- simply restarting the hypnotoad, or
- adding a periodic timer to the IOLoop which checks for an updated config
databases or
- starting a MongoDB (Mango) query on app start which uses a tailable
cursor and thus returns once the databases is updated.
And there's probably a ton of other options I did not mention, too.
I'm especially interested in recommendations based on real life
experience...
Thanks!
Heiko
--
You received this message because you are subscribed to the Google Groups
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: Mojo::Test to follow redirect?
According to the example at https://metacpan.org/pod/Test::Mojo#ua I´d say you´re doing it right. I wonder, however, how uncommenting that line of code can lead to this error message: "Can't connect: nodename nor servname provided, or not known" - which is apparently not part of Mojolicious itself; cf. https://grep.metacpan.org/search?q=nodename+nor+servname&qd=&qft= Hmmm, where does the redirect URL point to? Sure that it´s "localhost"? - heiko -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at https://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: Mojo::Test to follow redirect?
Am Sonntag, 28. Mai 2017 19:34:11 UTC+2 schrieb iaw4:
>
>
> my app redirects to http://auth.localhost:3000/index ,
>
Well, on my OpenSUSE box neither the "host" nor the "nslookup" (or "dig")
commands return an IP address for "auth.localhost" (they do, of course, for
"localhost"), so I´d say that explains the "Can't connect: nodename nor
servname provided, or not known" error message in your initial post.
The new demo code shows a different error:
and the output is
> # Connection refused
>
AFAIK, you should _not_ provide a hostname and port as parameter to
get_ok().
So I'd say a corrected test file should look like this:
use Test::More;
use Test::Mojo;
use FindBin;
require "$FindBin::Bin/../myapp.pl";
my $t = Test::Mojo->new;
$t->ua->max_redirects(100);
$t->get_ok('/')->status_is(200); # ->content_like( qr{abc});
done_testing();
If I test this with your server code (running "perl myapp.pl test -v t/t.pl
") I once again get the "Can't connect: nodename nor servname provided, or
not known" error message.
My browser follows without problems. I am guessing the Mojo Test daemon
> does not...
>
I´d say that the Chrome browser you use shows some non-standard behavior
here since I believe that localhost isn't a proper domain that could take
subdomains.
But I cannot provide an authoritative source for that right now.
Try using a different browser like Firefox for a start.
- Heiko
--
You received this message because you are subscribed to the Google Groups
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: Mojo::Test to follow redirect?
Am Montag, 29. Mai 2017 01:25:13 UTC+2 schrieb iaw4: > so here is one solution, although this one does not work in chrome: Add > 'localhost.test' and 'auth.localhost.test' at the end of 127.0.0.1 > localhost in /etc/hosts and `# morbo -v appname -l > http//localhost.test:3000`. now, http://localhost.test:3000/ works just > fine with safari, firefox, and the Mojolicious test agent (but not chrome). > Using dnsmasq is often an elegant solution for use-cases like this. Make sure that the DNS server provided by dnsmasq on localhost is the primary DNS server on your computer (e.g., by editing /etc/resolv.conf and prepending "nameserver 127.0.0.1"). Then, add an entry like "address=/sylspace.dev/127.0.0.1" to " /etc/dnsmasq.conf" and every host / subdomain in that domain is automatically resolved to localhost. heiko -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at https://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
[Mojolicious] url_for() and URI-escaping chars in placeholder values
I need to generate links within an app based on data from an external data
source. It contains data for a list of categories, and the category names
may contain almost any character including slashes.
Given this minimal example app:
#!/usr/bin/env perl
use Mojolicious::Lite;
get '/:cat' => sub {
my $c = shift;
$c->render(
text =>
"stash cat:" . $c->stash('cat')
. "\nurl_for: " . $c->url_for('category', { cat => "foo / bar"
})
. "\nurl_for esc: " . $c->url_for('category', { cat => "foo %2F
bar" })
. "\n"
);
} => 'category';
app->start;
and invoking it like this,
carton exec -- perl app.pl get -v /foo
I see this result:
stash cat: foo
url_for: /foo%20/%20bar
url_for esc: /foo%20/%20bar
So "url_for" interpolates the data for the placeholder and uri-escapes the
spaces but not the slash and also unescapes a pre-escaped slash.
I might get away with this using a wildcard placeholder (routes for the app
are not completely decided upon, yet) or I might evade the problem by
sending it as a query param.
But I´d still like to know if there is a way to force uri-escaping the
slash or if that is intentionally not the case.
Other reserved (as in RFC 3986) chars apparently *are* uri-escaped (e.g.
'#').
Maybe for slashes the placeholder type could be used to decide if a "/" has
to be converted to "%2F" ("no" for wildcard placeholders, "yes" for
standard and relaxed placeholders)?
Curious
- heiko
--
You received this message because you are subscribed to the Google Groups
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Question regarding Mojolicious v7.49 changes to M:I:Delay
Mojolicious v7.49 took us by surprise because of the changes to
Mojo::IOLoop::Delay.
We have a fairly large code base dealing extensively with gathering data
from a wide variety of back end systems (for displaying in a web portal).
Replacing the catch() method with the new one which does not receive the
delay object as first param appears to be mostly just an inconvenience, as
it requires some manual effort to adapt the existing code but no
modification of the abstract workflow logic.
The deprecation of "data" and "remaining" on the other hand could be a real
problem for us.
We have a bunch of classes for different back end systems, a starting point
and a defined end point.
The classes for the different back ends define the steps needed to gather
all necessary data from the respective back end to reach the generic end
point. The steps (callbacks) retrieved are then inserted in our M:I:Delay
object.
Only the input the respective step callback specifically needs is passed as
explicit parameters to it; everything else travels by in delay->data.
When retrieving the starting point data from a back end it sometimes
includes references to other objects.
We keep most of the response data around in the "data" attribute of the
delay and start harvesting the referenced data, which we need to have
around before continuing to the original second step.
For this we prepend new steps like this:
$delay->steps( @new, @{$delay->remaining} );
The final step can be quite generic, taking everything it needs out of the
$delay->data, processing it as required and passing it back to the main
application.
When implementing M:I:Delay::data and M:I:Delay::remaining something like
this must have been the intended use case.
Now we wonder if someone could describe the recommended way for
re-implementing these use cases without "data" and "remaining".
Thx
Heiko
--
You received this message because you are subscribed to the Google Groups
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Documentation "bug"
Hi, just saw that POD in Mojo::Template says: <%= Perl expression, replaced with result %> <%== Perl expression, replaced with XML escaped result %> while POD in Mojolicious::Guides::Rendering says: <%= Perl expression, replaced with XML escaped result %> <%== Perl expression, replaced with result %> So the description in Mojo::Template needs to be corrected, doesn't it? Best - Heiko -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at https://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
Re: [Mojolicious] Documentation "bug"
Am Mittwoch, 22. November 2017 17:27:51 UTC+1 schrieb Dan Book: > > When the auto_escape option is set on Mojo::Template, it reverses this > behavior; auto_escape is set by default for the EPRenderer template > handler, which the rendering guide is referring to. I agree it is a bit > confusing but I'm not sure the best way to clarify things. > Ah, OK. So it boils down to me not reading the rest of the text carefully enough... I simply considered the example block as a duplicated short reference. I also consider the auto-escaping behavior for the shorter tag-start variant (as activated in M:P:EPRenderer ) the saner approach so it never really occurred to me that the base implementation might be the other way round. Thanks for reminding me that assumptions != understanding ;-) Heiko -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at https://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
Re: [Mojolicious] Re: Mojo::UserAgent and large files
Hmm, there's no access to the controller ($c) and no reference to it kept in the fullfillment or rejection callbacks. I'd guess it is therefore garbage collected once you leave "welcome" and the client connection thus closed immediately. hth, heiko -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at https://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
Re: [Mojolicious] Re: Mojo::UserAgent URL with caret '^' not encoded
I do not know of a non-ugly way either but if you are okay with a hacky and
possibly fragile solution you might get away with adding:
$ua->on(start => sub {
my ($ua, $tx) = @_;
$tx->req->{'start_buffer'} =~ s/([&?]s=)%5E/$1^/o;
});
Poking into internals usually means one day you'll get what you asked for,
but if there is no other way...
--
You received this message because you are subscribed to the Google Groups
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: max_message_size
Am Montag, 3. Dezember 2018 10:29:49 UTC+1 schrieb Mikhail: > > I try to set *$c->req->max_message_size(0) *per ONE route/action. > > This is not work. How to upload big data but not whole APP for? > Can't actually answer your question outright, but maybe have two ideas for things you could try: 1) Some methods called on the request require the request to be parsed and cache the parsed data. So if you call any of those methods (in your controller or in any hook callback like 'around_dispatch') *before* increasing the limit it may already be to late for the latter. 2) I do not know how the relationship between the controller attribute "max_request_size" and the "max_message_size" request attribute looks like. That is: does Controller->max_request_size(0) actually raise the limit for every request or is it just needed to actually *be allowed* to raise the "max_message_size" limit for the individual request? Maybe some experimentation will help you here. HTH - Heiko -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at https://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: Event driven based on syslog messages
Bit late to the party, but anyhow If you tell rsyslogd to send output to a socket (using omuxsock), you can then use Mojo::IOLoop::Client to connect() to a socket via the "path" argument. Afterwards you can make use of the IOLoop to process events for reading from the socket. That's what you want? -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at https://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: program locked up upon Mojo::Reactor::EV: Timer failed
Admittedly more of a guess, but https://metacpan.org/pod/Mojo::Transaction#result is documented to "die" on connection errors, so maybe wrap that in an "eval" or otherwise modify the order of "error" / "is_success" checks? -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at https://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: Event driven based on syslog messages
Sorry, completely missed your follow-up...
I'd say the synopsis of Mojo::IOLoop mostly shows what to do. Never tried
it myself, but something along these lines should work:
use Mojo::IOLoop;
my $id = Mojo::IOLoop->client({ path => '/tmp/myapp.sock' } => sub {
my ($loop, $err, $stream) = @_;
$stream->on(read => sub {
my ($stream, $bytes) = @_;
# Process input
say "Input: $bytes";
});
});
# Start event loop if necessary
Mojo::IOLoop->start unless Mojo::IOLoop->is_running;
There may be other ways to achieve what you want, but this seems the
easiest solution to me.
Of course there's no guarantee that your "read" callback is called exactly
once for one complete new syslog entry. You may receive only parts of one
log entry or a whole bunch of log entries at once and you have to parse and
split them yourself, sometimes waiting for the rest of an entry to bee
provided in the next call of your callback...
--
You received this message because you are subscribed to the Google Groups
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
To view this discussion on the web visit
https://groups.google.com/d/msgid/mojolicious/5bd488c5-b97a-4140-9554-216805eca7c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Mojolicious] Set correct rights to unix socket with Mojo::Server::Daemon
What about simply running your Mojo app under the same user or a user with the same user group as used for nginx? Otherwise, what about using Perl's "umask" builtin in your app start script to set the appropriate value and probably reset it after the app started? -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at https://groups.google.com/group/mojolicious. To view this discussion on the web visit https://groups.google.com/d/msgid/mojolicious/d9577fd9-e39d-4edb-95f5-bd9b10c77339%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: With Mojo::IOLoop's delay, timer, and recurring, can I use them in a promises's "then" clause?
I actually don't know about any pitfalls when using Mojo::IOLoop's delay
etc. methods within "then" clauses, but
from my (limited) experience I'd suggest to avoid mixing traditional IOLoop
methods and promises if only
because it makes it even harder to follow the code flow.
To me it looks like you're just trying to kill some time when you using
the Mojo::IOLoop->delay() construct in the
snippet in your first post?
If so, I believe something along these lines should work (note: I just
typed that here and did not test it):
print STDERR qq{Get the job out ...\n};
return Mojo::Promise->timer(3);
} )->then( sub {
print STDERR '3 seconds';
return Mojo::Promise->timer(3);
} )->then( sub {
print STDERR '6 seconds';
return Mojo::Promise->timer(3);
} )->then( sub {
print STDERR '9 seconds';
$t->ua->get_p( $retrieve_enqueued_job_url => $header )
} )->then(
sub ($tx) {
print STDERR qq{ the job RESULTS : }
. Dumper( $tx->result->body );
}
);
Declaration of the variables $retrieve_enqueued_job_url and $header would
have to be lifted outside the
first "then" clause, of course, to be available in the later ones.
I hope that actually works and helps you move forward... ;-)
Gordon Dollarnanda schrieb am Freitag, 25. September 2020 um 09:15:48 UTC+2:
> Apologies- i hit the "send" button a bit too quickly.
>
> The test script works this way:
>
> 1. enqueue a new job by calling a given endpoint api. A Test::Mojo
> instance is instantiated. Assume the port is 51611. This is done with a
> promise using $t->ua->post_p(...) where $t is a Test::Mojo.
> 2. the job will be picked up by a minion service running in the
> background. The newly enqueued job's id is recorded.
> 3. this is when i need a delay or a recurring loop because the job's
> argument will have another endpoint url (with the same port currently used
> by my current Test::Mojo instance) which uses the same port , 51611
> 4. after the job runs, the results of the run is going to be stored in the
> Minion's job under results (ie $minion->info->{'result'}).
> 5. a call to another API endpoint to retrieve the results of the job (of
> the job id in step 2).
> 6. Will test for the job result's values against my expected values (part
> of Test::More).
>
> Step 3 is the reason for me to want to plant a delay in the 'then()'
> section of the promise in step 1.
>
>
>
>
> On Friday, 25 September 2020 at 17:08:01 UTC+10 Gordon Dollarnanda wrote:
>
>> hi, guys,
>>
>> Been reading up
>> https://docs.mojolicious.org/Mojo/IOLoop/Delay
>> https://docs.mojolicious.org/Mojolicious/Guides/Cookbook
>> and a few threads in the group.
>>
>> Apologies if i had missed this in advance but with Mojo::IOLoop's delay,
>> timer, and recurring, can I use them in a promises's "then" clause?
>> I am trying to do that to no avail.
>>
>> For example, in the following code snippet, the test runs very quickly
>> and doesn't delay at all.
>>
>> *Output:*
>>
>> [16:50:12] anexiole:server git:(bugfix/ET750-asyncTests*) $ prove -v
>> t/api/fwm/job/up.t
>> t/api/fwm/job/up.t ..
>> [info] Setting log level to: debug
>> [info] Manager started: MG EMU: Mojo::Server::Daemon
>> [info] Worker started: MG EMU: [27346]
>> [info] Manager started: MG EMU: Mojo::Server::Daemon
>> [info] Worker started: MG EMU: [27346]
>> Current port of t is 50016
>> RESULTS : $VAR1 = '{"jobId":2530,"task":"upgrade"}';
>> job id is 2530
>> Get the job out ...
>> IOLOoP is active
>> After the ioloop...
>> 1..0
>> skipped: (no reason given)
>>
>>
>>
>> *Snippet:*
>>
>>
>>
>>my $data = from_json( $test_scenario->{contents}->{data} );
>>
>> my $enqueue_job = Mojo::URL->new($url);
>>
>> $enqueue_job->query(
>> Mojo::Parameters->new(
>> 'format' =>
>> $test_scenario->{'contents'}->{'format'},
>> 'scope' => $scope,
>> 'deviceType' => $data->{'deviceType'},
>> 'data' =>
>> $test_scenario->{'contents'}->{'data'},
>> )
>> );
>> print STDERR qq{ Current port of t is }
>> . $t->ua->server->url->port . qq{\n};
>>
>> $t->ua->post_p( $enqueue_job => $header )->then(
>> sub ($tx) {
>> print STDERR qq{ RESULTS : }
>> . Dumper( $tx->result->body );
>> my $job_id = from_json( $tx->result->body
>> )->{'jobId'};
>> print STDERR qq{job id is $job_id\n};
>>
>> # Grab the report of the job out
>> my $retrieve_enqueued_job_url
>> =
>> Mojo::URL->new(qq{/myTestApp/api/job/v12/result/$job_id});
>> $retrieve_enqueued_job_url->query(
>> Mojo::Parameters->new( 'format' => q{json}, ),
>> );
>> print
