Re: [Catalyst] Mocking PSGI layers in Test WWW Mechanize Catalyst

[Toby Corkindale]

On 1 November 2013 12:29, Kieren Diment  wrote:
> On 01/11/2013, at 12:26 PM, Toby Corkindale wrote:
>> On 1 November 2013 12:01, Kieren Diment  wrote:
>>> You mean you want two apps interacting with each other in the same script 
>>> using WWW::MEchanize?  Eden and I were working some docs up on that topic 
>>> until real life intervened.
>>>
>>> This was the start of it:
>>>
>>> http://paste.scsys.co.uk/273844
>>
>> Not exactly -- in this case I have a PSGI layer that is supposed to
>> inject some extra information into the env for consumption by the
>> application.
>>
>> A simple example would be if you had a PSGI layer providing, say,
>> Basic HTTP auth, and setting the REMOTE_USER variable.
>> Although in my case, there's a bit more to it than that.
>>
>> T
>
> Does the paste set you in the right direction?

It's helpful for showing how to build a test-www-mechanize-psgi :)

-- 
Turning and turning in the widening gyre
The falcon cannot hear the falconer
Things fall apart; the center cannot hold
Mere anarchy is loosed upon the world

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Mocking PSGI layers in Test WWW Mechanize Catalyst

[Kieren Diment]

On 01/11/2013, at 12:26 PM, Toby Corkindale wrote:

> On 1 November 2013 12:01, Kieren Diment  wrote:
>> You mean you want two apps interacting with each other in the same script 
>> using WWW::MEchanize?  Eden and I were working some docs up on that topic 
>> until real life intervened.
>> 
>> This was the start of it:
>> 
>> http://paste.scsys.co.uk/273844
> 
> Not exactly -- in this case I have a PSGI layer that is supposed to
> inject some extra information into the env for consumption by the
> application.
> 
> A simple example would be if you had a PSGI layer providing, say,
> Basic HTTP auth, and setting the REMOTE_USER variable.
> Although in my case, there's a bit more to it than that.
> 
> T

Does the paste set you in the right direction?
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Mocking PSGI layers in Test WWW Mechanize Catalyst

[Toby Corkindale]

On 1 November 2013 12:01, Kieren Diment  wrote:
> You mean you want two apps interacting with each other in the same script 
> using WWW::MEchanize?  Eden and I were working some docs up on that topic 
> until real life intervened.
>
> This was the start of it:
>
> http://paste.scsys.co.uk/273844

Not exactly -- in this case I have a PSGI layer that is supposed to
inject some extra information into the env for consumption by the
application.

A simple example would be if you had a PSGI layer providing, say,
Basic HTTP auth, and setting the REMOTE_USER variable.
Although in my case, there's a bit more to it than that.

T

> On 01/11/2013, at 11:39 AM, Toby Corkindale wrote:
>
>> Umm, not that I know of.
>>
>> I suppose another way to phrase the question is: Is there a way to
>> manipulate the $c->engine->env in the Catalyst application, from
>> within unit tests neatly?
>>
>> On 1 November 2013 08:35, John Napiorkowski  wrote:
>>> Not sure what you mean, is there an example in another framework you can
>>> point to?
>>>
>>> johnn
>>>
>>>
>>> On Thursday, October 31, 2013 12:55 AM, Toby Corkindale 
>>> wrote:
>>> Hi,
>>> I wondered if there's any prior art around on inserting (mocked) PSGI
>>> layers into Test::WWW::Mechanize:Catalyst?
>>>
>>> Cheers,
>>> Toby
>>>
>>> --
>>> Turning and turning in the widening gyre
>>> The falcon cannot hear the falconer
>>> Things fall apart; the center cannot hold
>>> Mere anarchy is loosed upon the world
>>>
>>> ___
>>> List: Catalyst@lists.scsys.co.uk
>>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>>> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
>>> Dev site: http://dev.catalyst.perl.org/
>>>
>>>
>>>
>>> ___
>>> List: Catalyst@lists.scsys.co.uk
>>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>>> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
>>> Dev site: http://dev.catalyst.perl.org/
>>>
>>
>>
>>
>> --
>> Turning and turning in the widening gyre
>> The falcon cannot hear the falconer
>> Things fall apart; the center cannot hold
>> Mere anarchy is loosed upon the world
>>
>> ___
>> List: Catalyst@lists.scsys.co.uk
>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
>> Dev site: http://dev.catalyst.perl.org/
>
>
> ___
> List: Catalyst@lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/



-- 
Turning and turning in the widening gyre
The falcon cannot hear the falconer
Things fall apart; the center cannot hold
Mere anarchy is loosed upon the world

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Mocking PSGI layers in Test WWW Mechanize Catalyst

[Toby Corkindale]

It looks like there is an undocumented feature in Catalyst::Test, a
callback to let you modify the request.
$args->{mangle_request}->($request) if $args->{mangle_request};
Or alternatively I can subclass the module and extend
_customize_request() to add more to the PSGI environment.


On 1 November 2013 11:39, Toby Corkindale  wrote:
> Umm, not that I know of.
>
> I suppose another way to phrase the question is: Is there a way to
> manipulate the $c->engine->env in the Catalyst application, from
> within unit tests neatly?
>
> On 1 November 2013 08:35, John Napiorkowski  wrote:
>> Not sure what you mean, is there an example in another framework you can
>> point to?
>>
>> johnn
>>
>>
>> On Thursday, October 31, 2013 12:55 AM, Toby Corkindale 
>> wrote:
>> Hi,
>> I wondered if there's any prior art around on inserting (mocked) PSGI
>> layers into Test::WWW::Mechanize:Catalyst?
>>
>> Cheers,
>> Toby
>>
>> --
>> Turning and turning in the widening gyre
>> The falcon cannot hear the falconer
>> Things fall apart; the center cannot hold
>> Mere anarchy is loosed upon the world
>>
>> ___
>> List: Catalyst@lists.scsys.co.uk
>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
>> Dev site: http://dev.catalyst.perl.org/
>>
>>
>>
>> ___
>> List: Catalyst@lists.scsys.co.uk
>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
>> Dev site: http://dev.catalyst.perl.org/
>>
>
>
>
> --
> Turning and turning in the widening gyre
> The falcon cannot hear the falconer
> Things fall apart; the center cannot hold
> Mere anarchy is loosed upon the world



-- 
Turning and turning in the widening gyre
The falcon cannot hear the falconer
Things fall apart; the center cannot hold
Mere anarchy is loosed upon the world

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Mocking PSGI layers in Test WWW Mechanize Catalyst

[Kieren Diment]

You mean you want two apps interacting with each other in the same script using 
WWW::MEchanize?  Eden and I were working some docs up on that topic until real 
life intervened.

This was the start of it:

http://paste.scsys.co.uk/273844

On 01/11/2013, at 11:39 AM, Toby Corkindale wrote:

> Umm, not that I know of.
> 
> I suppose another way to phrase the question is: Is there a way to
> manipulate the $c->engine->env in the Catalyst application, from
> within unit tests neatly?
> 
> On 1 November 2013 08:35, John Napiorkowski  wrote:
>> Not sure what you mean, is there an example in another framework you can
>> point to?
>> 
>> johnn
>> 
>> 
>> On Thursday, October 31, 2013 12:55 AM, Toby Corkindale 
>> wrote:
>> Hi,
>> I wondered if there's any prior art around on inserting (mocked) PSGI
>> layers into Test::WWW::Mechanize:Catalyst?
>> 
>> Cheers,
>> Toby
>> 
>> --
>> Turning and turning in the widening gyre
>> The falcon cannot hear the falconer
>> Things fall apart; the center cannot hold
>> Mere anarchy is loosed upon the world
>> 
>> ___
>> List: Catalyst@lists.scsys.co.uk
>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
>> Dev site: http://dev.catalyst.perl.org/
>> 
>> 
>> 
>> ___
>> List: Catalyst@lists.scsys.co.uk
>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
>> Dev site: http://dev.catalyst.perl.org/
>> 
> 
> 
> 
> -- 
> Turning and turning in the widening gyre
> The falcon cannot hear the falconer
> Things fall apart; the center cannot hold
> Mere anarchy is loosed upon the world
> 
> ___
> List: Catalyst@lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Mocking PSGI layers in Test WWW Mechanize Catalyst

[Toby Corkindale]

Umm, not that I know of.

I suppose another way to phrase the question is: Is there a way to
manipulate the $c->engine->env in the Catalyst application, from
within unit tests neatly?

On 1 November 2013 08:35, John Napiorkowski  wrote:
> Not sure what you mean, is there an example in another framework you can
> point to?
>
> johnn
>
>
> On Thursday, October 31, 2013 12:55 AM, Toby Corkindale 
> wrote:
> Hi,
> I wondered if there's any prior art around on inserting (mocked) PSGI
> layers into Test::WWW::Mechanize:Catalyst?
>
> Cheers,
> Toby
>
> --
> Turning and turning in the widening gyre
> The falcon cannot hear the falconer
> Things fall apart; the center cannot hold
> Mere anarchy is loosed upon the world
>
> ___
> List: Catalyst@lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
>
>
>
> ___
> List: Catalyst@lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
>



-- 
Turning and turning in the widening gyre
The falcon cannot hear the falconer
Things fall apart; the center cannot hold
Mere anarchy is loosed upon the world

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: Response traits.

[Bill Moseley]

On Thu, Oct 31, 2013 at 2:34 PM, John Napiorkowski wrote:

> I'm currently recommending people take advantage of native PSGI support in
> the newer Catalyst and use Middleware for when you need to munge and or
> alter the response (if its being done globally).  The interface is more
> straightforward.
>

Do you think that Catalyst::Response should validate the location provided
to redirect()?

The issue that came up was a newline was ending up in the location provided
which resulted in a split
response.
   I was thinking of doing something like:

$self->location( URI->new( $location )->as_string );

But with perhaps a bit more error handling.






>
> johnn
>
>
>On Thursday, October 31, 2013 11:33 AM, Bill Moseley 
> wrote:
>
> On Thu, Oct 31, 2013 at 12:51 AM, Aristotle Pagaltzis wrote:
>
> CatalystX::RoleApplicator
>
>
> Thanks.  That was what I was looking for.   Just missed it when looking.
>
>
> --
> Bill Moseley
> mose...@hank.org
>
> ___
> List: Catalyst@lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
>
>
>
> ___
> List: Catalyst@lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
>
>


-- 
Bill Moseley
mose...@hank.org
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Have exceeded the maximum number of attempts (1000) to open temp file/dir

[Bill Moseley]

On Thu, Oct 31, 2013 at 2:44 PM, John Napiorkowski wrote:

>
> am calling ->cleanup(1) when we create the HTTP::Body.  is that not enough
> to cleanup tmp files ?
>

I haven't look at this in a while, but I think it's described here:

https://rt.cpan.org/Public/Bug/Display.html?id=84004

HTTP::Body assumes $self->{upload} exists before deleting, and that might
not be created yet.

I have my own version for handling 'multipart/form-data' that sets UNLINK
=> 1.


Now, the application/octet-stream handling is another issue.  There
HTTP::Body uses the default File::Temp (e.g. UNLINK => 1), but I'm still
finding a large number of those files left around.

In my dev environment I have not been able to make it leave files on /tmp.
 On production I can run watch 'ls /tmp | wc -l' and see the counts
increase and decrease so I know files are being deleted, but every once in
a while a file gets left behind.   I don't see segfaults in the logs, and
I've tested with Apache's MaxRequestPerChild low (so recycling child
processes often) and not seeing that leave files behind.

I'm going to update our copy of HTTP::Body and put the process ID in the
temp file template to essentially namespace and use cron to keep /tmp
cleaner.  But, I still have yet to figure out why those are left behind.
With UNLINK => 1 they should not be left there.   File::Temp doesn't appear
to check the return value from unlink.

They come and go but some stick around:

$ for i in $(seq 10); do ls /tmp | wc -l; sleep 2; done
23861
23865
23863
23864
23862
23862
23865
23865
23864
23866

$ ls -lt /tmp | head -2
total 95492
-rw--- 1 tii-rest tii-rest   14 Oct 31 16:40 Nudjp9WDNy

$ ls -lt /tmp | tail -2
-rw--- 1 tii-rest tii-rest   16 Oct 28 13:36 NWwxOhwhRW
-rw--- 1 tii-rest tii-rest   16 Oct 28 13:35 Ll1Ze0TNPL





>
> regarding the tmp file thing, wow I have no idea, but I hope you find out
> and report it to us!
>
> Johnn
>
>
>On Friday, October 25, 2013 8:53 AM, Bill Moseley 
> wrote:
>   I have an API where requests can include JSON.  HTTP::Body saves those
> off to temp files.
>
> Yesterday got a very large number of errors:
>
> [ERROR] "Caught exception in engine "Error in tempfile() using
> /tmp/XX: Have exceeded the maximum number of attempts (1000) to
> open temp file/dir
>
> The File::Temp docs say:
>
> If you are forking many processes in parallel that are all creating
> temporary files, you may need to reset the random number seed using
> srand(EXPR) in each child else all the children will attempt to walk
> through the same set of random file names and may well cause
> themselves to give up if they exceed the number of retry attempts.
>
>
> We are running under mod_perl.   Could it be as simple as the procs all
> were in sync?   I'm just surprised this has not happened before.   Is there
> another explanation?
>
> Where would you suggest to call srand()?
>
>
> Another problem, and one I've 
> commentedon before, is 
> that HTTP::Body doesn't use File::Temp's unlink feature and
> depends on Catalyst cleaning up.  This results in orphaned files left on
> temp disk.
>
>
>
>
>
> --
> Bill Moseley
> mose...@hank.org
>
> ___
> List: Catalyst@lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
>
>
>
> ___
> List: Catalyst@lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
>
>


-- 
Bill Moseley
mose...@hank.org
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

[Catalyst] One more thing on the state of Async IO on Catalyst Dev5

[John Napiorkowski]

One thing that was noted in the changlog is we have added experimental support 
of IO:Async based event loops, to compliment Anyevent.  The Async examples on 
github have been updated to include a IOAsync version of the streaming, web 
socket echo and web socket chat examples.

Async IO support in Catalyst is still experimental overall, but the feature is 
there and worth playing with if you are interested in learning about it.  

Have Fun!

https://github.com/jjn1056/Perl-Catalyst-AsyncExample


Jnap

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

[Catalyst] Development 5 Release of Catalyst 'Hamburg' on CPAN

[John Napiorkowski]

Hey All,

Catalyst 5.90049_005 is on CPAN, please check it out!

This is the fifth and likely last development release of Catalyst in this 
current series.  Assuming no serious problems show up on CPAN testers, and 
nobody shouts out, I will make this as stable sometime in the next few days.

In general the development releases have gone over well with CPAN testers and I 
feel the release is pretty solid.  That being said there are a lot of changes 
and features so it is well worth testing your code on this release.  Its just a 

    cpanm --dev Catalyst

Away from being on your box!

Here's the most recent changes:

  - NEW FEATURE:  New Controller action attribute 'Consumes', which allows you
to specify the content type of the incoming request.  This makes it easier
to create actions that only handle certain content type POST or PUT, such
as actions that only handle JSON or actions that only understand classic
HTML forms.
  - NEW FEATURE: Request->body_data is now also populated from classic HTML 
Forms using CGI::Struct to support nested data.  For non nested data you
should use the classic ->body_parameters method.
  - Removed PSGI $env keys that are added on the 'plack.request.*' namespace
since after discussion it was clear those keys are not part of the public
API.  Keys removed: 'plack.request.query', 'plack.request.body', 
'plack.request.merged' and 'plack.request.http.body'. Altered some test
cases to reflect this change.

Cheers!

Johnn

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Have exceeded the maximum number of attempts (1000) to open temp file/dir

[John Napiorkowski]

Bill,

I see over here (latest release)

https://metacpan.org/source/JJNAPIORK/Catalyst-Runtime-5.90049_005/lib/Catalyst/Request.pm#L260


am calling ->cleanup(1) when we create the HTTP::Body.  is that not enough to 
cleanup tmp files ?

regarding the tmp file thing, wow I have no idea, but I hope you find out and 
report it to us!

Johnn



On Friday, October 25, 2013 8:53 AM, Bill Moseley  wrote:
 
I have an API where requests can include JSON.  HTTP::Body saves those off to 
temp files.

Yesterday got a very large number of errors:

[ERROR] "Caught exception in engine "Error in tempfile() using /tmp/XX: 
Have exceeded the maximum number of attempts (1000) to open temp file/dir

The File::Temp docs say:

If you are forking many processes in parallel that are all creating
>temporary files, you may need to reset the random number seed using
>srand(EXPR) in each child else all the children will attempt to walk
>through the same set of random file names and may well cause
>themselves to give up if they exceed the number of retry attempts.

We are running under mod_perl.   Could it be as simple as the procs all were in 
sync?   I'm just surprised this has not happened before.   Is there another 
explanation?

Where would you suggest to call srand()?


Another problem, and one I've commented on before, is that HTTP::Body doesn't 
use File::Temp's unlink feature and depends on Catalyst cleaning up.  This 
results in orphaned files left on temp disk.




-- 
Bill Moseley
mose...@hank.org 
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Mocking PSGI layers in Test WWW Mechanize Catalyst

[John Napiorkowski]

Not sure what you mean, is there an example in another framework you can point 
to?

johnn



On Thursday, October 31, 2013 12:55 AM, Toby Corkindale  wrote:
 
Hi,
I wondered if there's any prior art around on inserting (mocked) PSGI
layers into Test::WWW::Mechanize:Catalyst?

Cheers,
Toby

-- 
Turning and turning in the widening gyre
The falcon cannot hear the falconer
Things fall apart; the center cannot hold
Mere anarchy is loosed upon the world

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: Response traits.

[John Napiorkowski]

I'm currently recommending people take advantage of native PSGI support in the 
newer Catalyst and use Middleware for when you need to munge and or alter the 
response (if its being done globally).  The interface is more straightforward.

johnn



On Thursday, October 31, 2013 11:33 AM, Bill Moseley  wrote:
 


On Thu, Oct 31, 2013 at 12:51 AM, Aristotle Pagaltzis  wrote:

CatalystX::RoleApplicator
Thanks.  That was what I was looking for.   Just missed it when looking.


-- 
Bill Moseley
mose...@hank.org 

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] $c->write() buffering?

[John Napiorkowski]

Recent releases of Catalyst makes it possible to stream write, although you 
need to be careful when using a blocking web server (long stream will of course 
block the available listener).

Older versions of Catalyst had similar ability with the write method, I never 
used it, and would be happen to get patches or test cases to make it work as 
we'd like.

Here's a link to an example, this one assume AnyEvent as a loop, but you could 
use a similar technique with any web server, as long as you don't mind blocking:

https://metacpan.org/pod/release/JJNAPIORK/Catalyst-Runtime-5.90049_005/lib/Catalyst/Response.pm#res-write_fh


If you follow that, you will see stuff 'stream' as you wish unless there is 
some buffering going on at some other level of the stack.

Johnn



On Thursday, October 31, 2013 4:22 PM, Daniel J. Luke  
wrote:
 
I replicated this today outside of Catalyst (just a small 
FCGI/FCGI::ProcManager test script). If anyone else has seen this/fixed it, I'd 
appreciate a pointer. I'll report back to the list if/when I get it resolved so 
that there's an answer in the list archives for future people to google 
otherwise.


On Oct 31, 2013, at 10:12 AM, Daniel J. Luke  wrote:
> We're actually running Catalyst::Runtime 5.80031 (currently), so I believe 
> it's using Catalyst::Engine::FastCGI which just does *STDOUT->syswrite()
> 
> I guess I try to do some testing with newer Catalyst (and maybe alternate 
> deployment methods), to see if that changes anything. Looking through the 
> Changelog, I didn't see anything specifically related to this, though 
> (although I imagine the Plack stuff makes it somewhat different in the more 
> recent releases). 
> 
> On Oct 30, 2013, at 11:03 PM, Hailin Hu  wrote:
>> It is an engine relevant stuff.
>> Find which engine you are using ( for example, Plack::Handler::FCGI )
>> and look around codes around write(r), you may find something.
>> Good luck :)
>> 
>> On Wed, Oct 30, 2013 at 9:51 AM, Daniel J. Luke  wrote:
>>> I've got some legacy CGI code that does a bunch of processing and uses the 
>>> old hack of $| = 1; print "foo\n"; do_work(); print "foo done\n"; etc. 
>>> (solution #1 from http://wiki.catalystframework.org/wiki/longcomputations)
>>> 
>>> While I'll eventually convert it to a job queue, I'd like to create an 
>>> output-identical implementation first with Catalyst, however it seems like 
>>> I'm getting output buffering when I don't want it.
>>> 
>>> As a very simple test, I've set up apache 2.2, mod_fastcgi 
>>> (FastCgiExternalServer with -flush and without -flush) and a method like 
>>> this:
>>> 
>>> sub test: Local {
>>>   my ($self, $c) = @_;
>>> 
>>>   $c->res->body('');
>>>   $c->response->content_type( 'text/plain; charset=utf-8' );
>>>   $c->finalize_headers;
>>> 
>>>   my $i;
>>>   for($i=1;$i<8;$i++) {
>>>       $c->write("$i: foo bar baz\n");
>>>       sleep(1);
>>>   }
>>> }
>>> 
>>> I see all the data at once in my browser instead of a line every second, 
>>> and with tcpdump, can see that all of the data is coming back in one packet 
>>> and not in 8+ smaller packets like I expect. If I make the string that gets 
>>> passed to write longer, I get several packets, but all at once (and not 
>>> with each iteration through the for loop).
>>> 
>>> Am I missing something obvious? Is there some way to get the behavior I'm 
>>> expecting?

--
Daniel J. Luke                                                                  
++                      
  
| * dl...@geeklair.net * |                      
    
| *-- http://www.geeklair.net -* |                      
    
++                      
  
|   Opinions expressed are mine and do not necessarily   |                      
    
|          reflect the opinions of my employer.          |                      
    
++




___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] $c->write() buffering?

[John Napiorkowski]

Also, check out 

https://github.com/jjn1056/Perl-Catalyst-AsyncExample


which has a few examples related.  Those are more about async IO but the 
approach is the same, just more simple since you don't need to run a lot of 
callbacks.

Basically post PSGI Catalyst returns a deferred response to the underlying 
server, so streaming and all that is straightforward.

Johnn



On , John Napiorkowski  wrote:
 
Recent releases of Catalyst makes it possible to stream write, although you 
need to be careful when using a blocking web server (long stream will of course 
block the available listener).

Older versions of Catalyst had similar ability with the write method, I never 
used it, and would be happen to get patches or test cases to make it work as 
we'd like.

Here's a link to an example, this one assume AnyEvent as a loop, but you could 
use a similar technique with any web server, as long as you don't mind blocking:

https://metacpan.org/pod/release/JJNAPIORK/Catalyst-Runtime-5.90049_005/lib/Catalyst/Response.pm#res-write_fh


If you follow that, you will see stuff 'stream' as you wish unless there is 
some buffering going on at some other level of the stack.

Johnn



On Thursday, October 31, 2013 4:22 PM, Daniel J. Luke  
wrote:
 
I replicated this today outside of Catalyst (just a small 
FCGI/FCGI::ProcManager test script). If anyone else has seen this/fixed it, I'd 
appreciate a pointer. I'll report back to the list if/when I get it resolved so 
that there's an answer in the list archives for future people to google 
otherwise.


On Oct 31, 2013, at 10:12 AM, Daniel J. Luke  wrote:
> We're actually running Catalyst::Runtime 5.80031 (currently), so I believe 
> it's using Catalyst::Engine::FastCGI which just does *STDOUT->syswrite()
> 
> I guess I try to do some testing with newer Catalyst (and maybe alternate 
> deployment methods), to see if that changes anything. Looking through the 
> Changelog, I didn't see anything specifically related to this, though 
> (although I imagine the Plack stuff makes it somewhat different in the more 
> recent releases). 
> 
> On Oct 30, 2013, at 11:03 PM, Hailin Hu  wrote:
>> It is an engine relevant stuff.
>> Find which engine you are using ( for example, Plack::Handler::FCGI )
>> and look around codes around write(r), you may find something.
>> Good luck :)
>> 
>> On Wed, Oct 30, 2013 at 9:51 AM, Daniel J. Luke  wrote:
>>> I've got some legacy CGI code that does a bunch of processing and uses the 
>>> old hack of $| = 1; print "foo\n"; do_work(); print "foo done\n"; etc. 
>>> (solution #1 from http://wiki.catalystframework.org/wiki/longcomputations)
>>> 
>>> While I'll eventually convert it to a job queue, I'd like to create an 
>>> output-identical implementation first with Catalyst, however it seems like 
>>> I'm getting output buffering when I don't want it.
>>> 
>>> As a very simple test, I've set up apache 2.2, mod_fastcgi 
>>> (FastCgiExternalServer with -flush and without -flush) and a method like 
>>> this:
>>> 
>>> sub test: Local {
>>>   my ($self, $c) = @_;
>>> 
>>>   $c->res->body('');
>>>   $c->response->content_type( 'text/plain; charset=utf-8' );
>>>   $c->finalize_headers;
>>> 
>>>   my $i;
>>>   for($i=1;$i<8;$i++) {
>>>       $c->write("$i: foo bar baz\n");
>>>       sleep(1);
>>>   }
>>> }
>>> 
>>> I see all the data at once in my browser instead of a line every second, 
>>> and with tcpdump, can see that all of the data is coming back in one packet 
>>> and not in 8+ smaller packets like I expect. If I make the string that gets 
>>> passed to write longer, I get several packets, but all at once (and not 
>>> with each iteration through the for loop).
>>> 
>>> Am I missing something obvious? Is there some way to get the behavior I'm 
>>> expecting?

--
Daniel J. Luke                                         
                         
++                      
  
| * dl...@geeklair.net * |                      
    
| *-- http://www.geeklair.net -* |                      
    
++                      
  
|   Opinions expressed are mine and do not
 necessarily   |                          
|          reflect the opinions of my employer.          |                      
    
++




___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] $c->write() buffering?

[Daniel J. Luke]

I replicated this today outside of Catalyst (just a small 
FCGI/FCGI::ProcManager test script). If anyone else has seen this/fixed it, I'd 
appreciate a pointer. I'll report back to the list if/when I get it resolved so 
that there's an answer in the list archives for future people to google 
otherwise.

On Oct 31, 2013, at 10:12 AM, Daniel J. Luke  wrote:
> We're actually running Catalyst::Runtime 5.80031 (currently), so I believe 
> it's using Catalyst::Engine::FastCGI which just does *STDOUT->syswrite()
> 
> I guess I try to do some testing with newer Catalyst (and maybe alternate 
> deployment methods), to see if that changes anything. Looking through the 
> Changelog, I didn't see anything specifically related to this, though 
> (although I imagine the Plack stuff makes it somewhat different in the more 
> recent releases). 
> 
> On Oct 30, 2013, at 11:03 PM, Hailin Hu  wrote:
>> It is an engine relevant stuff.
>> Find which engine you are using ( for example, Plack::Handler::FCGI )
>> and look around codes around write(r), you may find something.
>> Good luck :)
>> 
>> On Wed, Oct 30, 2013 at 9:51 AM, Daniel J. Luke  wrote:
>>> I've got some legacy CGI code that does a bunch of processing and uses the 
>>> old hack of $| = 1; print "foo\n"; do_work(); print "foo done\n"; etc. 
>>> (solution #1 from http://wiki.catalystframework.org/wiki/longcomputations)
>>> 
>>> While I'll eventually convert it to a job queue, I'd like to create an 
>>> output-identical implementation first with Catalyst, however it seems like 
>>> I'm getting output buffering when I don't want it.
>>> 
>>> As a very simple test, I've set up apache 2.2, mod_fastcgi 
>>> (FastCgiExternalServer with -flush and without -flush) and a method like 
>>> this:
>>> 
>>> sub test: Local {
>>>   my ($self, $c) = @_;
>>> 
>>>   $c->res->body('');
>>>   $c->response->content_type( 'text/plain; charset=utf-8' );
>>>   $c->finalize_headers;
>>> 
>>>   my $i;
>>>   for($i=1;$i<8;$i++) {
>>>   $c->write("$i: foo bar baz\n");
>>>   sleep(1);
>>>   }
>>> }
>>> 
>>> I see all the data at once in my browser instead of a line every second, 
>>> and with tcpdump, can see that all of the data is coming back in one packet 
>>> and not in 8+ smaller packets like I expect. If I make the string that gets 
>>> passed to write longer, I get several packets, but all at once (and not 
>>> with each iteration through the for loop).
>>> 
>>> Am I missing something obvious? Is there some way to get the behavior I'm 
>>> expecting?

--
Daniel J. Luke  
 
++  
  
| * dl...@geeklair.net * |  

| *-- http://www.geeklair.net -* |  

++  
  
|   Opinions expressed are mine and do not necessarily   |  

|  reflect the opinions of my employer.  |  

++




___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: Response traits.

[Bill Moseley]

On Thu, Oct 31, 2013 at 12:51 AM, Aristotle Pagaltzis wrote:

> CatalystX::RoleApplicator


Thanks.  That was what I was looking for.   Just missed it when looking.


-- 
Bill Moseley
mose...@hank.org
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] $c->write() buffering?

[Daniel J. Luke]

We're actually running Catalyst::Runtime 5.80031 (currently), so I believe it's 
using Catalyst::Engine::FastCGI which just does *STDOUT->syswrite()

I guess I try to do some testing with newer Catalyst (and maybe alternate 
deployment methods), to see if that changes anything. Looking through the 
Changelog, I didn't see anything specifically related to this, though (although 
I imagine the Plack stuff makes it somewhat different in the more recent 
releases). 

On Oct 30, 2013, at 11:03 PM, Hailin Hu  wrote:
> It is an engine relevant stuff.
> Find which engine you are using ( for example, Plack::Handler::FCGI )
> and look around codes around write(r), you may find something.
> Good luck :)
> 
> On Wed, Oct 30, 2013 at 9:51 AM, Daniel J. Luke  wrote:
>> I've got some legacy CGI code that does a bunch of processing and uses the 
>> old hack of $| = 1; print "foo\n"; do_work(); print "foo done\n"; etc. 
>> (solution #1 from http://wiki.catalystframework.org/wiki/longcomputations)
>> 
>> While I'll eventually convert it to a job queue, I'd like to create an 
>> output-identical implementation first with Catalyst, however it seems like 
>> I'm getting output buffering when I don't want it.
>> 
>> As a very simple test, I've set up apache 2.2, mod_fastcgi 
>> (FastCgiExternalServer with -flush and without -flush) and a method like 
>> this:
>> 
>> sub test: Local {
>>my ($self, $c) = @_;
>> 
>>$c->res->body('');
>>$c->response->content_type( 'text/plain; charset=utf-8' );
>>$c->finalize_headers;
>> 
>>my $i;
>>for($i=1;$i<8;$i++) {
>>$c->write("$i: foo bar baz\n");
>>sleep(1);
>>}
>> }
>> 
>> I see all the data at once in my browser instead of a line every second, and 
>> with tcpdump, can see that all of the data is coming back in one packet and 
>> not in 8+ smaller packets like I expect. If I make the string that gets 
>> passed to write longer, I get several packets, but all at once (and not with 
>> each iteration through the for loop).
>> 
>> Am I missing something obvious? Is there some way to get the behavior I'm 
>> expecting?

--
Daniel J. Luke  
 
++  
  
| * dl...@geeklair.net * |  

| *-- http://www.geeklair.net -* |  

++  
  
|   Opinions expressed are mine and do not necessarily   |  

|  reflect the opinions of my employer.  |  

++




___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

[Catalyst] Re: Response traits.

[Aristotle Pagaltzis]

* Bill Moseley  [2013-10-31 00:40]:
> What is the recommended way to apply a Response trait?

Uhm, how about applying it to your response class?

CatalystX::RoleApplicator I guess?

Not sure I get the question though.

-- 
Aristotle Pagaltzis // 

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/