Re: [Catalyst] Progress bar

2012-10-24 Thread Fred Moyer 
On Wed, Oct 24, 2012 at 9:59 AM, Bill Moseley  wrote:
>
>
> On Wed, Oct 24, 2012 at 5:44 AM, Lorn  wrote:
>>
>> I'm not following the thread but, did you guys know about
>> http://wiki.nginx.org/HttpUploadProgressModule. ?
>
>
> PerlBal (as in this old post:
> http://lists.danga.com/pipermail/perlbal/2005-November/000138.html ) can do
> this as well.

I can vouch for the scalability of the Perlbal upload tracker. I used
it on taperfriendlymusic.org in front of a slashcode based mod_perl
app in 2006, and one box was able to handle 50 megabits of uploads
with around 10% cpu usage.



>
> I wonder about the topology.   We used to run with Perlbal (and heartbeat
> and IP failover) in front of a pool of web servers.   We now run with
> hardware load balancers in front of a pool of web servers.
>
> The load balancer does make it easy to adjust the pool -- as well as
> gracefully handle a web server dropping out of the pool.   I don't want to
> add yet another set of servers for an extra proxy layer.
>
> So, I'm currently thinking of running Nginx on each web server. (Keep-alive
> between the load balancer and Nginx, and no keep-alive between Nginx and
> Catalyst with maybe Starman.)
>
> Anyone see why this might be a bad (or good) approach?
>
> --
> 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] Progress bar

2012-10-24 Thread Bill Moseley 
On Wed, Oct 24, 2012 at 5:44 AM, Lorn  wrote:

>  I'm not following the thread but, did you guys know about
> http://wiki.nginx.org/HttpUploadProgressModule. ?
>

PerlBal (as in this old post:
http://lists.danga.com/pipermail/perlbal/2005-November/000138.html ) can do
this as well.

I wonder about the topology.   We used to run with Perlbal (and heartbeat
and IP failover) in front of a pool of web servers.   We now run with
hardware load balancers in front of a pool of web servers.

The load balancer does make it easy to adjust the pool -- as well as
gracefully handle a web server dropping out of the pool.   I don't want to
add yet another set of servers for an extra proxy layer.

So, I'm currently thinking of running Nginx on each web server. (Keep-alive
between the load balancer and Nginx, and no keep-alive between Nginx and
Catalyst with maybe Starman.)

Anyone see why this might be a bad (or good) approach?

-- 
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] [ANNOUNCE] Catalyst-Runtime version 5.90018

2012-10-24 Thread John Napiorkowski 
I'm pleased to announce Catalyst version 5.90018! 

This release solves pointless test failures when installing Catalyst due to 
recent changes in HTTP::Message.


You may not consider this a mandatory upgrade unless this issue is biting you.

Thanks!

John Napiorkowski

___
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] Progress bar

2012-10-24 Thread Craig Chant 
Or a plethora of other methods using PHP/Perl/JQuery/Flash/HTML5

https://github.com/blueimp/jQuery-File-Upload

http://www.uploadify.com/

http://sourceforge.net/projects/uber-uploader/



From: Lorn [mailto:l...@lornlab.org]
Sent: 24 October 2012 13:45
To: The elegant MVC web framework
Subject: Re: [Catalyst] Progress bar

I'm not following the thread but, did you guys know about
http://wiki.nginx.org/HttpUploadProgressModule. ?

They work together with upload module, and dont "overload" your backend with 
upload files, nginx handle that and just pass the file path to the backend.

--
Lorn


On Wednesday, 24 de October de 2012 at 02:33, Toby Corkindale wrote:
I was just investigating why the upload progress bar was broken on one
of my apps.. came here to make a post and discovered this thread.
Well, at least that's the first question answered!

Given the caveats around Starman and WebKit browsers, are there any
other suggestions for how to do upload progress indicators?
Is this something we can do via HTML5 neater? Are there any
open-source Flash implementations?

Cheers,
Toby

On 22 October 2012 09:42, Bill Moseley 
mailto:mose...@hank.org>> wrote:

On Sat, Oct 20, 2012 at 1:51 PM, Tomas Doran 
mailto:bobtf...@bobtfish.net>> wrote:

And UploadProgress is shipped, should be available once it's reindexed
(permissions cock up), which should be shortly :)


So, when running under Starman the uploads are buffered before chunked to
Catalyst, which means the progress bar data isn't updated until the upload
has completed. This renders the upload progress bar pretty useless with
Starman.

The progress bar works fine running the app under mod_perl.

I suppose using something like Nginx or Perlbal in front of the app would
work (because those do cache uploads but also provide a hook for reading
upload progress). But, we already have hardware load balancers in front of
the app, so don't really need an extra proxy in front of every web server.

Any other options? Using a upload/request caching proxy is probably THE
correct answer since don't really want to tie up the app with slow uploads.

I guess I should test, but I wonder if there's a limit on what Starman will
buffer -- I assume it's buffering in memory.




--
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/



--
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/

This Email and any attachments contain confidential information and is intended 
solely for the individual to whom it is addressed. If this Email has been 
misdirected, please notify the author as soon as possible. If you are not the 
intended recipient you must not disclose, distribute, copy, print or rely on 
any of the information contained, and all copies must be deleted immediately. 
Whilst we take reasonable steps to try to identify any software viruses, any 
attachments to this e-mail may nevertheless contain viruses, which our 
anti-virus software has failed to identify. You should therefore carry out your 
own anti-virus checks before opening any documents. HomeLoan Partnership will 
not accept any liability for damage caused by computer viruses emanating from 
any attachment or other document supplied with this e-mail. HomeLoan 
Partnership reserves the right to monitor and archive all e-mail communications 
through its network. No representative or employee of HomeLoan Partnership has 
the authority to enter into any contract on behalf of HomeLoan Partnership by 
email. HomeLoan Partnership is a trading name of H L Partnership Limited, 
registered in England and Wales with Registration Number 5011722. Registered 
office: 26-34 Old Street, London, EC1V 9QQ. H L Partnership Limited is 
authorised and regulated by the Financial Services Authority.
___
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] Progress bar

2012-10-24 Thread Lorn 
I'm not following the thread but, did you guys know about  
http://wiki.nginx.org/HttpUploadProgressModule. ?

They work together with upload module, and dont "overload" your backend with 
upload files, nginx handle that and just pass the file path to the backend.

-- 
Lorn


On Wednesday, 24 de October de 2012 at 02:33, Toby Corkindale wrote:

> I was just investigating why the upload progress bar was broken on one
> of my apps.. came here to make a post and discovered this thread.
> Well, at least that's the first question answered!
> 
> Given the caveats around Starman and WebKit browsers, are there any
> other suggestions for how to do upload progress indicators?
> Is this something we can do via HTML5 neater? Are there any
> open-source Flash implementations?
> 
> Cheers,
> Toby
> 
> On 22 October 2012 09:42, Bill Moseley  wrote:
> > 
> > On Sat, Oct 20, 2012 at 1:51 PM, Tomas Doran  wrote:
> > > 
> > > And UploadProgress is shipped, should be available once it's reindexed
> > > (permissions cock up), which should be shortly :)
> > > 
> > 
> > 
> > 
> > So, when running under Starman the uploads are buffered before chunked to
> > Catalyst, which means the progress bar data isn't updated until the upload
> > has completed. This renders the upload progress bar pretty useless with
> > Starman.
> > 
> > The progress bar works fine running the app under mod_perl.
> > 
> > I suppose using something like Nginx or Perlbal in front of the app would
> > work (because those do cache uploads but also provide a hook for reading
> > upload progress). But, we already have hardware load balancers in front of
> > the app, so don't really need an extra proxy in front of every web server.
> > 
> > Any other options? Using a upload/request caching proxy is probably THE
> > correct answer since don't really want to tie up the app with slow uploads.
> > 
> > I guess I should test, but I wonder if there's a limit on what Starman will
> > buffer -- I assume it's buffering in memory.
> > 
> > 
> > 
> > 
> > --
> > 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/
> > 
> 
> 
> 
> 
> -- 
> 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] Catalyst-Runtime 5.90017 isntallation problem

2012-10-24 Thread Dimitar Petrov 
Just to add that version 5.90018 has been released which I guess fix that
issue.

Cheers,
Dimitar

On Tue, Oct 23, 2012 at 10:26 PM, Tomas Doran  wrote:

>
> On 22 Oct 2012, at 07:48, Siddhartha wrote:
>
> > Hi
> >
> >
> > I have problem to install Catalyst-Runtime 5.90017 on OpenSUSE 12.1
> > Any ideas
>
>
> This fail is due to changes in HTTP::Message (we were relying on it's
> internals in tests and they changed) - you can safely force the install, or
> you can downgrade HTTP::Message 2 releases and it'll all work.
>
> Now fixed in master, there will be a new release soon.
>
> Cheers
> t0m
>
>
>
>
> ___
> 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] Moose's make_immutable in Catalyst classes

2012-10-24 Thread Tomas Doran 

On 24 Oct 2012, at 05:35, Toby Corkindale wrote:
> I was just wondering.. should we be adding Moose's make_immutable call
> to the end of these classes?
> ie. __PACKAGE__->meta->make_immutable;


This makes things faster if you construct lots of them (and also makes things a 
bit safer, as they can't be changed), at the cost of a bit of startup time.

Generally Catalyst components are only initialised once (i.e. they're scoped to 
the lifetime of the app), so there is no speed benefit to immutable in this 
case (actually, it's probably a startup speed reduction), but I still tend to 
use it for the safety…

So it's entirely optional, in classes which implement ACCEPT_CONTEXT (and so 
are constructed once per request), you will see a speed benefit from doing it, 
but this is the less unusual case.. 

Cheers
t0m


___
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/