Mark and I chatted tonight and discussed the possibilities of
restructuring Transfer's caching architecture to be pluggable as he
posted over the weekend. The idea is, out of the box, to provide a
Javaloader 1.0/eHcache implementation that would be more flexible and
would solve the memory issues that many of us are seeing. This
pluggable architecture will support any caching system - Java-based
solutions like eHcache or ColdFusion solutions like Coldbox's cache or
anything else.
I'm putting up $800, or half the money needed, to pay for Mark's time
to solve this issue. If someone will match my contribution, Mark will
schedule the time now and we'll have a solution before the end of
October.
Who will match me and support Mark's great work on Transfer?
So how many of you have saved even one day of writing SQL or objects
by hand because of Transfer? How about two days? Maybe a week? Has
your entire team probably gained a month of productivity by, day in
and day out, using Transfer instead of doing it by hand?
Tell your boss that an $800 donation to an Open Source product (or
hell, 2 x $400 or 4 x $200) will greatly improve the package that your
application depends on. Reward Mark for answering all of our inane
questions. Support open source authors who make our lives easier.
Nobody has $800 to match my offer? For shame...
Brian
On Sep 20, 10:46 pm, Brian G <brian-goo...@vfive.com> wrote:
> Mark and I chatted tonight and discussed the possibilities of
> restructuring Transfer's caching architecture to be pluggable as he
> posted over the weekend. The idea is, out of the box, to provide a
> Javaloader 1.0/eHcache implementation that would be more flexible and
> would solve the memory issues that many of us are seeing. This
> pluggable architecture will support any caching system - Java-based
> solutions like eHcache or ColdFusion solutions like Coldbox's cache or
> anything else.
> I'm putting up $800, or half the money needed, to pay for Mark's time
> to solve this issue. If someone will match my contribution, Mark will
> schedule the time now and we'll have a solution before the end of
> October.
> Who will match me and support Mark's great work on Transfer?
On Behalf Of Brian G
Sent: Tuesday, September 29, 2009 9:41 AM
To: transfer-dev
Subject: [transfer-dev] Re: Match my $800 donation for Transfer caching
improvements
So how many of you have saved even one day of writing SQL or objects
by hand because of Transfer? How about two days? Maybe a week? Has
your entire team probably gained a month of productivity by, day in
and day out, using Transfer instead of doing it by hand?
Tell your boss that an $800 donation to an Open Source product (or
hell, 2 x $400 or 4 x $200) will greatly improve the package that your
application depends on. Reward Mark for answering all of our inane
questions. Support open source authors who make our lives easier.
Nobody has $800 to match my offer? For shame...
Brian
On Sep 20, 10:46 pm, Brian G <brian-goo...@vfive.com> wrote:
> Mark and I chatted tonight and discussed the possibilities of
> restructuring Transfer's caching architecture to be pluggable as he
> posted over the weekend. The idea is, out of the box, to provide a
> Javaloader 1.0/eHcache implementation that would be more flexible and
> would solve the memory issues that many of us are seeing. This
> pluggable architecture will support any caching system - Java-based
> solutions like eHcache or ColdFusion solutions like Coldbox's cache or
> anything else.
> I'm putting up $800, or half the money needed, to pay for Mark's time
> to solve this issue. If someone will match my contribution, Mark will
> schedule the time now and we'll have a solution before the end of
> October.
> Who will match me and support Mark's great work on Transfer?
Yeah, a lower amount spread out among a lot of people would help. I'm in for
$50 bucks. Hit hard here by the economic slowdown. Gimme til the day after
tomorrow to process it.
How about a plea that everyone on the list respond to this thread and
contribute something to the effort. Just hit the reply button, sit for a
moment of reflection like I just did, and type in a pledge. Almost everyone
can afford something.
Nando
On Tue, Sep 29, 2009 at 7:28 PM, Josh Nathanson <joshnathan...@gmail.com>wrote:
> -----Original Message-----
> From: transfer-dev@googlegroups.com [mailto:transfer-dev@googlegroups.com]
> On Behalf Of Brian G
> Sent: Tuesday, September 29, 2009 9:41 AM
> To: transfer-dev
> Subject: [transfer-dev] Re: Match my $800 donation for Transfer caching
> improvements
> So how many of you have saved even one day of writing SQL or objects
> by hand because of Transfer? How about two days? Maybe a week? Has
> your entire team probably gained a month of productivity by, day in
> and day out, using Transfer instead of doing it by hand?
> Tell your boss that an $800 donation to an Open Source product (or
> hell, 2 x $400 or 4 x $200) will greatly improve the package that your
> application depends on. Reward Mark for answering all of our inane
> questions. Support open source authors who make our lives easier.
> Nobody has $800 to match my offer? For shame...
> Brian
> On Sep 20, 10:46 pm, Brian G <brian-goo...@vfive.com> wrote:
> > Mark and I chatted tonight and discussed the possibilities of
> > restructuring Transfer's caching architecture to be pluggable as he
> > posted over the weekend. The idea is, out of the box, to provide a
> > Javaloader 1.0/eHcache implementation that would be more flexible and
> > would solve the memory issues that many of us are seeing. This
> > pluggable architecture will support any caching system - Java-based
> > solutions like eHcache or ColdFusion solutions like Coldbox's cache or
> > anything else.
> > I'm putting up $800, or half the money needed, to pay for Mark's time
> > to solve this issue. If someone will match my contribution, Mark will
> > schedule the time now and we'll have a solution before the end of
> > October.
> > Who will match me and support Mark's great work on Transfer?
> > Brian
--
Nando M. Breiter
The CarbonZero Project
CP 234
6934 Bioggio
Switzerland
+41 76 303 4477
na...@carbonzero.ch
we just finished the EHCache - clustered cache implementation for Railo. So
that you can use a distributed or synchronized cache across a cluster and
store for example all CachedWithin queries in the cluster cache. If you like
I can provide some information and source code about that, as a contribution
to it as well.
Von: transfer-dev@googlegroups.com [mailto:transfer-dev@googlegroups.com] Im
Auftrag von Nando
Gesendet: Dienstag, 29. September 2009 20:45
An: transfer-dev@googlegroups.com
Betreff: [transfer-dev] Re: Match my $800 donation for Transfer caching
improvements
Yeah, a lower amount spread out among a lot of people would help. I'm in for
$50 bucks. Hit hard here by the economic slowdown. Gimme til the day after
tomorrow to process it.
How about a plea that everyone on the list respond to this thread and
contribute something to the effort. Just hit the reply button, sit for a
moment of reflection like I just did, and type in a pledge. Almost everyone
can afford something.
Nando
On Tue, Sep 29, 2009 at 7:28 PM, Josh Nathanson <joshnathan...@gmail.com>
wrote:
How about 20 people for $40 or 40 people for $20? At least you'd get
something that way.
I just donated $40, hopefully that'll get things started.
The donation link is at the Transfer homepage, right hand column:
On Behalf Of Brian G
Sent: Tuesday, September 29, 2009 9:41 AM
To: transfer-dev
Subject: [transfer-dev] Re: Match my $800 donation for Transfer caching
improvements
So how many of you have saved even one day of writing SQL or objects
by hand because of Transfer? How about two days? Maybe a week? Has
your entire team probably gained a month of productivity by, day in
and day out, using Transfer instead of doing it by hand?
Tell your boss that an $800 donation to an Open Source product (or
hell, 2 x $400 or 4 x $200) will greatly improve the package that your
application depends on. Reward Mark for answering all of our inane
questions. Support open source authors who make our lives easier.
Nobody has $800 to match my offer? For shame...
Brian
On Sep 20, 10:46 pm, Brian G <brian-goo...@vfive.com> wrote:
> Mark and I chatted tonight and discussed the possibilities of
> restructuring Transfer's caching architecture to be pluggable as he
> posted over the weekend. The idea is, out of the box, to provide a
> Javaloader 1.0/eHcache implementation that would be more flexible and
> would solve the memory issues that many of us are seeing. This
> pluggable architecture will support any caching system - Java-based
> solutions like eHcache or ColdFusion solutions like Coldbox's cache or
> anything else.
> I'm putting up $800, or half the money needed, to pay for Mark's time
> to solve this issue. If someone will match my contribution, Mark will
> schedule the time now and we'll have a solution before the end of
> October.
> Who will match me and support Mark's great work on Transfer?
> Brian
--
Nando M. Breiter
The CarbonZero Project
CP 234
6934 Bioggio
Switzerland
+41 76 303 4477
na...@carbonzero.ch
Will there be a CF9 compatable stable release by the time CF9 is officially released (whenever that is - I have a feeling it will be fairly soon)? I seem to recall that you mentioned only the bleeding edge version worked with cf9 at the moment, and indeed I had to upgrade to that version to get it running on my test platform.
Apologies if this has already been covered - I did a quick search on the mailing list archives and couldn't see anything.
Because I think transfer is a great framework and I believe that Mark does a
very good job, I've just donated $800 to support this cache enhancement.
In fact,I'm working with transfer more than one year today and I have many
websites and RIA in production status and it's a real nightmare about memory
leaks and CPU bottlenecks. I've deactivated the cache to speed up my
applications... (for example : paris-exception.fr is powered by CFMX8,
MachII and transfer connected with several CRM legacy applications, welcome
to Paris to every one ;-) ).
> Mark and I chatted tonight and discussed the possibilities of
> restructuring Transfer's caching architecture to be pluggable as he
> posted over the weekend. The idea is, out of the box, to provide a
> Javaloader 1.0/eHcache implementation that would be more flexible and
> would solve the memory issues that many of us are seeing. This
> pluggable architecture will support any caching system - Java-based
> solutions like eHcache or ColdFusion solutions like Coldbox's cache or
> anything else.
> I'm putting up $800, or half the money needed, to pay for Mark's time
> to solve this issue. If someone will match my contribution, Mark will
> schedule the time now and we'll have a solution before the end of
> October.
> Who will match me and support Mark's great work on Transfer?
> Because I think transfer is a great framework and I believe that Mark does a
> very good job, I've just donated $800 to support this cache enhancement.
> In fact,I'm working with transfer more than one year today and I have many
> websites and RIA in production status and it's a real nightmare about memory
> leaks and CPU bottlenecks. I've deactivated the cache to speed up my
> applications... (for example : paris-exception.fr is powered by CFMX8,
> MachII and transfer connected with several CRM legacy applications, welcome
> to Paris to every one ;-) ).
>> Mark and I chatted tonight and discussed the possibilities of
>> restructuring Transfer's caching architecture to be pluggable as he
>> posted over the weekend. The idea is, out of the box, to provide a
>> Javaloader 1.0/eHcache implementation that would be more flexible and
>> would solve the memory issues that many of us are seeing. This
>> pluggable architecture will support any caching system - Java-based
>> solutions like eHcache or ColdFusion solutions like Coldbox's cache or
>> anything else.
>> I'm putting up $800, or half the money needed, to pay for Mark's time
>> to solve this issue. If someone will match my contribution, Mark will
>> schedule the time now and we'll have a solution before the end of
>> October.
>> Who will match me and support Mark's great work on Transfer?
> Without the "www", it shows up as "under construction".
> - Gabriel
> 2009/9/29 Aurélien DELEUSIÈRE <adeleusi...@gmail.com>:
> > Hello all -
> > Because I think transfer is a great framework and I believe that Mark
> does a
> > very good job, I've just donated $800 to support this cache enhancement.
> > In fact,I'm working with transfer more than one year today and I have
> many
> > websites and RIA in production status and it's a real nightmare about
> memory
> > leaks and CPU bottlenecks. I've deactivated the cache to speed up my
> > applications... (for example : paris-exception.fr is powered by CFMX8,
> > MachII and transfer connected with several CRM legacy applications,
> welcome
> > to Paris to every one ;-) ).
> >> Mark and I chatted tonight and discussed the possibilities of
> >> restructuring Transfer's caching architecture to be pluggable as he
> >> posted over the weekend. The idea is, out of the box, to provide a
> >> Javaloader 1.0/eHcache implementation that would be more flexible and
> >> would solve the memory issues that many of us are seeing. This
> >> pluggable architecture will support any caching system - Java-based
> >> solutions like eHcache or ColdFusion solutions like Coldbox's cache or
> >> anything else.
> >> I'm putting up $800, or half the money needed, to pay for Mark's time
> >> to solve this issue. If someone will match my contribution, Mark will
> >> schedule the time now and we'll have a solution before the end of
> >> October.
> >> Who will match me and support Mark's great work on Transfer?
I would like to release a stable version with a rewritten pluggable Cache
implementation, but with MAX, cf.Objective(ANZ), ColdSpring, JavaLoader and
the various other community stuff I am doing I am stretched a little thin at
the moment. Hence the call for the bounty. It enables me to keep providing
for the Community while also letting me put food on the table ;o)
At this stage it will most likely be after cf.Objective(ANZ), depending on
some other factors.
On Wed, Sep 30, 2009 at 5:26 AM, Will Swain <w...@hothorse.com> wrote:
> Hi,
> Thanks for all your work on Transfer Mark.
> Will there be a CF9 compatable stable release by the time CF9 is officially
> released (whenever that is - I have a feeling it will be fairly soon)? I
> seem to recall that you mentioned only the bleeding edge version worked with
> cf9 at the moment, and indeed I had to upgrade to that version to get it
> running on my test platform.
> Apologies if this has already been covered - I did a quick search on the
> mailing list archives and couldn't see anything.
On Wed, Sep 30, 2009 at 8:36 AM, Mark Mandel <mark.man...@gmail.com> wrote:
> I would like to release a stable version with a rewritten pluggable Cache
> implementation, but with MAX, cf.Objective(ANZ), ColdSpring, JavaLoader and
> the various other community stuff I am doing I am stretched a little thin at
> the moment. Hence the call for the bounty. It enables me to keep providing
> for the Community while also letting me put food on the table ;o)
> At this stage it will most likely be after cf.Objective(ANZ), depending on
> some other factors.
> Mark
> On Wed, Sep 30, 2009 at 5:26 AM, Will Swain <w...@hothorse.com> wrote:
>> Hi,
>> Thanks for all your work on Transfer Mark.
>> Will there be a CF9 compatable stable release by the time CF9 is
>> officially released (whenever that is - I have a feeling it will be fairly
>> soon)? I seem to recall that you mentioned only the bleeding edge version
>> worked with cf9 at the moment, and indeed I had to upgrade to that version
>> to get it running on my test platform.
>> Apologies if this has already been covered - I did a quick search on the
>> mailing list archives and couldn't see anything.
>> Without the "www", it shows up as "under construction".
>> - Gabriel
>> 2009/9/29 Aurélien DELEUSIÈRE <adeleusi...@gmail.com>:
>> > Hello all -
>> > Because I think transfer is a great framework and I believe that Mark
>> does a
>> > very good job, I've just donated $800 to support this cache enhancement.
>> > In fact,I'm working with transfer more than one year today and I have
>> many
>> > websites and RIA in production status and it's a real nightmare about
>> memory
>> > leaks and CPU bottlenecks. I've deactivated the cache to speed up my
>> > applications... (for example : paris-exception.fr is powered by CFMX8,
>> > MachII and transfer connected with several CRM legacy applications,
>> welcome
>> > to Paris to every one ;-) ).
>> >> Mark and I chatted tonight and discussed the possibilities of
>> >> restructuring Transfer's caching architecture to be pluggable as he
>> >> posted over the weekend. The idea is, out of the box, to provide a
>> >> Javaloader 1.0/eHcache implementation that would be more flexible and
>> >> would solve the memory issues that many of us are seeing. This
>> >> pluggable architecture will support any caching system - Java-based
>> >> solutions like eHcache or ColdFusion solutions like Coldbox's cache or
>> >> anything else.
>> >> I'm putting up $800, or half the money needed, to pay for Mark's time
>> >> to solve this issue. If someone will match my contribution, Mark will
>> >> schedule the time now and we'll have a solution before the end of
>> >> October.
>> >> Who will match me and support Mark's great work on Transfer?
Thanks to those who stepped up (whether it be $20 or $800) to make
this happen: YOU GUYS ROCK! I've just sent my $800 (917AUD) to Mark
so he'll have a little more than we initially bargained for, which
should keep him motivated for when he feels like going to bed. :)
Brian (last name rhymes with Ghirardelli)
On Sep 29, 3:44 pm, Mark Mandel <mark.man...@gmail.com> wrote:
> I will coordinate with Brian G (I can never spell your last name Brian ;o)
> ), and lock down some dates for getting this stuff done and out the door.
> Which will also give us a date for a CF9 stable release.
> Thanks guys! We get to build some cool stuff here!
> >> > Because I think transfer is a great framework and I believe that Mark
> >> does a
> >> > very good job, I've just donated $800 to support this cache enhancement.
> >> > In fact,I'm working with transfer more than one year today and I have
> >> many
> >> > websites and RIA in production status and it's a real nightmare about
> >> memory
> >> > leaks and CPU bottlenecks. I've deactivated the cache to speed up my
> >> > applications... (for example : paris-exception.fr is powered by CFMX8,
> >> > MachII and transfer connected with several CRM legacy applications,
> >> welcome
> >> > to Paris to every one ;-) ).
> >> >> Mark and I chatted tonight and discussed the possibilities of
> >> >> restructuring Transfer's caching architecture to be pluggable as he
> >> >> posted over the weekend. The idea is, out of the box, to provide a
> >> >> Javaloader 1.0/eHcache implementation that would be more flexible and
> >> >> would solve the memory issues that many of us are seeing. This
> >> >> pluggable architecture will support any caching system - Java-based
> >> >> solutions like eHcache or ColdFusion solutions like Coldbox's cache or
> >> >> anything else.
> >> >> I'm putting up $800, or half the money needed, to pay for Mark's time
> >> >> to solve this issue. If someone will match my contribution, Mark will
> >> >> schedule the time now and we'll have a solution before the end of
> >> >> October.
> >> >> Who will match me and support Mark's great work on Transfer?
First of all - big thanks to Brian for organising this in the first place.
Next, thanks to the people who donated, Brian, Josh and Aurelien, you guys
are amazing. Seriously. Amazing.
Gert, thanks for the offer, I may take you up on that, I will see how I go
with eHCache.
(Un)Fortunately, October is completely full with stuff, with MAX and whatnot
going on, so I've locked down the first week in November to roll this out.
It's a bit far away, I know, but literally yesterday all my time got sucked
up out of October, which is just one of those things that happens.
Expect to see a lot of emails as we hit November, as the pluggable cache
architecture will probably deprecate a lot of the caching config that
currently exists in the Transfer XML, and move it into whatever files the
pluggable cache will take - so I will be looking for some direction from the
community on that.
On Wed, Sep 30, 2009 at 9:01 AM, Brian G <brian-goo...@vfive.com> wrote:
> Thanks to those who stepped up (whether it be $20 or $800) to make
> this happen: YOU GUYS ROCK! I've just sent my $800 (917AUD) to Mark
> so he'll have a little more than we initially bargained for, which
> should keep him motivated for when he feels like going to bed. :)
> Brian (last name rhymes with Ghirardelli)
> On Sep 29, 3:44 pm, Mark Mandel <mark.man...@gmail.com> wrote:
> > Wow!
> > What a way to wake up in the morning!
> > I will coordinate with Brian G (I can never spell your last name Brian
> ;o)
> > ), and lock down some dates for getting this stuff done and out the door.
> > Which will also give us a date for a CF9 stable release.
> > Thanks guys! We get to build some cool stuff here!
> > >> > Because I think transfer is a great framework and I believe that
> Mark
> > >> does a
> > >> > very good job, I've just donated $800 to support this cache
> enhancement.
> > >> > In fact,I'm working with transfer more than one year today and I
> have
> > >> many
> > >> > websites and RIA in production status and it's a real nightmare
> about
> > >> memory
> > >> > leaks and CPU bottlenecks. I've deactivated the cache to speed up my
> > >> > applications... (for example : paris-exception.fr is powered by
> CFMX8,
> > >> > MachII and transfer connected with several CRM legacy applications,
> > >> welcome
> > >> > to Paris to every one ;-) ).
> > >> > Thanks,
> > >> > Aurelien, France, Paris
> > >> > 2009/9/21 Brian G <brian-goo...@vfive.com>
> > >> >> Mark and I chatted tonight and discussed the possibilities of
> > >> >> restructuring Transfer's caching architecture to be pluggable as he
> > >> >> posted over the weekend. The idea is, out of the box, to provide a
> > >> >> Javaloader 1.0/eHcache implementation that would be more flexible
> and
> > >> >> would solve the memory issues that many of us are seeing. This
> > >> >> pluggable architecture will support any caching system - Java-based
> > >> >> solutions like eHcache or ColdFusion solutions like Coldbox's cache
> or
> > >> >> anything else.
> > >> >> I'm putting up $800, or half the money needed, to pay for Mark's
> time
> > >> >> to solve this issue. If someone will match my contribution, Mark
> will
> > >> >> schedule the time now and we'll have a solution before the end of
> > >> >> October.
> > >> >> Who will match me and support Mark's great work on Transfer?
Brilliant. Thanks Mark - I missed the bounty thread but have now read
through it.
Cheers
Will
_____
From: transfer-dev@googlegroups.com [mailto:transfer-dev@googlegroups.com]
On Behalf Of Mark Mandel
Sent: 29 September 2009 23:40
To: transfer-dev@googlegroups.com
Subject: [transfer-dev] Re: Transfer and CF9
...and I just saw the bounty come through! Wow!
I'll write more in the other thread, but we'll start nailing down some
dates.
Mark
On Wed, Sep 30, 2009 at 8:36 AM, Mark Mandel <mark.man...@gmail.com> wrote:
I would like to release a stable version with a rewritten pluggable Cache
implementation, but with MAX, cf.Objective(ANZ), ColdSpring, JavaLoader and
the various other community stuff I am doing I am stretched a little thin at
the moment. Hence the call for the bounty. It enables me to keep providing
for the Community while also letting me put food on the table ;o)
At this stage it will most likely be after cf.Objective(ANZ), depending on
some other factors.
Mark
On Wed, Sep 30, 2009 at 5:26 AM, Will Swain <w...@hothorse.com> wrote:
Hi,
Thanks for all your work on Transfer Mark.
Will there be a CF9 compatable stable release by the time CF9 is officially
released (whenever that is - I have a feeling it will be fairly soon)? I
seem to recall that you mentioned only the bleeding edge version worked with
cf9 at the moment, and indeed I had to upgrade to that version to get it
running on my test platform.
Apologies if this has already been covered - I did a quick search on the
mailing list archives and couldn't see anything.
No virus found in this incoming message.
Checked by AVG - www.avg.com Version: 8.5.409 / Virus Database: 270.13.113/2400 - Release Date: 09/29/09
05:54:00
Hello Mark -
I didn't have time to get back on this. The amazing guy here is you, you're
always available, getting response for everyone and everything...
If I can help you for testing, tell me I'll try to take some time on this
(hot) topic.
> First of all - big thanks to Brian for organising this in the first place.
> Next, thanks to the people who donated, Brian, Josh and Aurelien, you guys
> are amazing. Seriously. Amazing.
> Gert, thanks for the offer, I may take you up on that, I will see how I go
> with eHCache.
> (Un)Fortunately, October is completely full with stuff, with MAX and
> whatnot going on, so I've locked down the first week in November to roll
> this out.
> It's a bit far away, I know, but literally yesterday all my time got sucked
> up out of October, which is just one of those things that happens.
> Expect to see a lot of emails as we hit November, as the pluggable cache
> architecture will probably deprecate a lot of the caching config that
> currently exists in the Transfer XML, and move it into whatever files the
> pluggable cache will take - so I will be looking for some direction from the
> community on that.
> Exciting, Exciting stuff.
> Mark
> On Wed, Sep 30, 2009 at 9:01 AM, Brian G <brian-goo...@vfive.com> wrote:
>> Thanks to those who stepped up (whether it be $20 or $800) to make
>> this happen: YOU GUYS ROCK! I've just sent my $800 (917AUD) to Mark
>> so he'll have a little more than we initially bargained for, which
>> should keep him motivated for when he feels like going to bed. :)
>> Brian (last name rhymes with Ghirardelli)
>> On Sep 29, 3:44 pm, Mark Mandel <mark.man...@gmail.com> wrote:
>> > Wow!
>> > What a way to wake up in the morning!
>> > I will coordinate with Brian G (I can never spell your last name Brian
>> ;o)
>> > ), and lock down some dates for getting this stuff done and out the
>> door.
>> > Which will also give us a date for a CF9 stable release.
>> > Thanks guys! We get to build some cool stuff here!
>> > >> > Because I think transfer is a great framework and I believe that
>> Mark
>> > >> does a
>> > >> > very good job, I've just donated $800 to support this cache
>> enhancement.
>> > >> > In fact,I'm working with transfer more than one year today and I
>> have
>> > >> many
>> > >> > websites and RIA in production status and it's a real nightmare
>> about
>> > >> memory
>> > >> > leaks and CPU bottlenecks. I've deactivated the cache to speed up
>> my
>> > >> > applications... (for example : paris-exception.fr is powered by
>> CFMX8,
>> > >> > MachII and transfer connected with several CRM legacy applications,
>> > >> welcome
>> > >> > to Paris to every one ;-) ).
>> > >> > Thanks,
>> > >> > Aurelien, France, Paris
>> > >> > 2009/9/21 Brian G <brian-goo...@vfive.com>
>> > >> >> Mark and I chatted tonight and discussed the possibilities of
>> > >> >> restructuring Transfer's caching architecture to be pluggable as
>> he
>> > >> >> posted over the weekend. The idea is, out of the box, to provide
>> a
>> > >> >> Javaloader 1.0/eHcache implementation that would be more flexible
>> and
>> > >> >> would solve the memory issues that many of us are seeing. This
>> > >> >> pluggable architecture will support any caching system -
>> Java-based
>> > >> >> solutions like eHcache or ColdFusion solutions like Coldbox's
>> cache or
>> > >> >> anything else.
>> > >> >> I'm putting up $800, or half the money needed, to pay for Mark's
>> time
>> > >> >> to solve this issue. If someone will match my contribution, Mark
>> will
>> > >> >> schedule the time now and we'll have a solution before the end of
>> > >> >> October.
>> > >> >> Who will match me and support Mark's great work on Transfer?
>> First of all - big thanks to Brian for organising this in the first place.
>> Next, thanks to the people who donated, Brian, Josh and Aurelien, you guys
>> are amazing. Seriously. Amazing.
>> Gert, thanks for the offer, I may take you up on that, I will see how I go
>> with eHCache.
>> (Un)Fortunately, October is completely full with stuff, with MAX and
>> whatnot going on, so I've locked down the first week in November to roll
>> this out.
>> It's a bit far away, I know, but literally yesterday all my time got
>> sucked up out of October, which is just one of those things that happens.
>> Expect to see a lot of emails as we hit November, as the pluggable cache
>> architecture will probably deprecate a lot of the caching config that
>> currently exists in the Transfer XML, and move it into whatever files the
>> pluggable cache will take - so I will be looking for some direction from the
>> community on that.
>> Exciting, Exciting stuff.
>> Mark
>> On Wed, Sep 30, 2009 at 9:01 AM, Brian G <brian-goo...@vfive.com> wrote:
>>> Thanks to those who stepped up (whether it be $20 or $800) to make
>>> this happen: YOU GUYS ROCK! I've just sent my $800 (917AUD) to Mark
>>> so he'll have a little more than we initially bargained for, which
>>> should keep him motivated for when he feels like going to bed. :)
>>> Brian (last name rhymes with Ghirardelli)
>>> On Sep 29, 3:44 pm, Mark Mandel <mark.man...@gmail.com> wrote:
>>> > Wow!
>>> > What a way to wake up in the morning!
>>> > I will coordinate with Brian G (I can never spell your last name Brian
>>> ;o)
>>> > ), and lock down some dates for getting this stuff done and out the
>>> door.
>>> > Which will also give us a date for a CF9 stable release.
>>> > Thanks guys! We get to build some cool stuff here!
>>> > >> > Because I think transfer is a great framework and I believe that
>>> Mark
>>> > >> does a
>>> > >> > very good job, I've just donated $800 to support this cache
>>> enhancement.
>>> > >> > In fact,I'm working with transfer more than one year today and I
>>> have
>>> > >> many
>>> > >> > websites and RIA in production status and it's a real nightmare
>>> about
>>> > >> memory
>>> > >> > leaks and CPU bottlenecks. I've deactivated the cache to speed up
>>> my
>>> > >> > applications... (for example : paris-exception.fr is powered by
>>> CFMX8,
>>> > >> > MachII and transfer connected with several CRM legacy
>>> applications,
>>> > >> welcome
>>> > >> > to Paris to every one ;-) ).
>>> > >> > Thanks,
>>> > >> > Aurelien, France, Paris
>>> > >> > 2009/9/21 Brian G <brian-goo...@vfive.com>
>>> > >> >> Mark and I chatted tonight and discussed the possibilities of
>>> > >> >> restructuring Transfer's caching architecture to be pluggable as
>>> he
>>> > >> >> posted over the weekend. The idea is, out of the box, to provide
>>> a
>>> > >> >> Javaloader 1.0/eHcache implementation that would be more flexible
>>> and
>>> > >> >> would solve the memory issues that many of us are seeing. This
>>> > >> >> pluggable architecture will support any caching system -
>>> Java-based
>>> > >> >> solutions like eHcache or ColdFusion solutions like Coldbox's
>>> cache or
>>> > >> >> anything else.
>>> > >> >> I'm putting up $800, or half the money needed, to pay for Mark's
>>> time
>>> > >> >> to solve this issue. If someone will match my contribution, Mark
>>> will
>>> > >> >> schedule the time now and we'll have a solution before the end of
>>> > >> >> October.
>>> > >> >> Who will match me and support Mark's great work on Transfer?
>>> First of all - big thanks to Brian for organising this in the first
>>> place.
>>> Next, thanks to the people who donated, Brian, Josh and Aurelien, you
>>> guys are amazing. Seriously. Amazing.
>>> Gert, thanks for the offer, I may take you up on that, I will see how I
>>> go with eHCache.
>>> (Un)Fortunately, October is completely full with stuff, with MAX and
>>> whatnot going on, so I've locked down the first week in November to roll
>>> this out.
>>> It's a bit far away, I know, but literally yesterday all my time got
>>> sucked up out of October, which is just one of those things that happens.
>>> Expect to see a lot of emails as we hit November, as the pluggable cache
>>> architecture will probably deprecate a lot of the caching config that
>>> currently exists in the Transfer XML, and move it into whatever files the
>>> pluggable cache will take - so I will be looking for some direction from the
>>> community on that.
>>> Exciting, Exciting stuff.
>>> Mark
>>> On Wed, Sep 30, 2009 at 9:01 AM, Brian G <brian-goo...@vfive.com> wrote:
>>>> Thanks to those who stepped up (whether it be $20 or $800) to make
>>>> this happen: YOU GUYS ROCK! I've just sent my $800 (917AUD) to Mark
>>>> so he'll have a little more than we initially bargained for, which
>>>> should keep him motivated for when he feels like going to bed. :)
>>>> Brian (last name rhymes with Ghirardelli)
>>>> On Sep 29, 3:44 pm, Mark Mandel <mark.man...@gmail.com> wrote:
>>>> > Wow!
>>>> > What a way to wake up in the morning!
>>>> > I will coordinate with Brian G (I can never spell your last name Brian
>>>> ;o)
>>>> > ), and lock down some dates for getting this stuff done and out the
>>>> door.
>>>> > Which will also give us a date for a CF9 stable release.
>>>> > Thanks guys! We get to build some cool stuff here!
>>>> > >> > Because I think transfer is a great framework and I believe that
>>>> Mark
>>>> > >> does a
>>>> > >> > very good job, I've just donated $800 to support this cache
>>>> enhancement.
>>>> > >> > In fact,I'm working with transfer more than one year today and I
>>>> have
>>>> > >> many
>>>> > >> > websites and RIA in production status and it's a real nightmare
>>>> about
>>>> > >> memory
>>>> > >> > leaks and CPU bottlenecks. I've deactivated the cache to speed up
>>>> my
>>>> > >> > applications... (for example : paris-exception.fr is powered by
>>>> CFMX8,
>>>> > >> > MachII and transfer connected with several CRM legacy
>>>> applications,
>>>> > >> welcome
>>>> > >> > to Paris to every one ;-) ).
>>>> > >> > Thanks,
>>>> > >> > Aurelien, France, Paris
>>>> > >> > 2009/9/21 Brian G <brian-goo...@vfive.com>
>>>> > >> >> Mark and I chatted tonight and discussed the possibilities of
>>>> > >> >> restructuring Transfer's caching architecture to be pluggable as
>>>> he
>>>> > >> >> posted over the weekend. The idea is, out of the box, to
>>>> provide a
>>>> > >> >> Javaloader 1.0/eHcache implementation that would be more
>>>> flexible and
>>>> > >> >> would solve the memory issues that many of us are seeing. This
>>>> > >> >> pluggable architecture will support any caching system -
>>>> Java-based
>>>> > >> >> solutions like eHcache or ColdFusion solutions like Coldbox's
>>>> cache or
>>>> > >> >> anything else.
>>>> > >> >> I'm putting up $800, or half the money needed, to pay for Mark's
>>>> time
>>>> > >> >> to solve this issue. If someone will match my contribution,
>>>> Mark will
>>>> > >> >> schedule the time now and we'll have a solution before the end
>>>> of
>>>> > >> >> October.
>>>> > >> >> Who will match me and support Mark's great work on Transfer?
The <setting> values get pass to the init() of the Provider.
(Some more basic statistic based methods will be added later for simple reporting, and tied back into the CacheMonitor)
So you see you can set up a defaultCacheProvider, and also use a specific CacheProvider for specific classes as well - so you can mix and match caches (possibly at your own peril ;o) )
Because you can also extend the Provider yourself, you can do all sorts of weird and wonderful things.
I'm writing up an EHCache one as the default, which will have some limitations as to the platform it can do things on (No CF7, quite possibly not going to work on some shared hosts, due to classpath restrictions), so I'll be looking for other people to do some intergration as well (A ColdBox cache adapter would be really cool, or any other cache framework). The only major dependency is that the cache framework has to be able to tell you when something gets discarded, as that is how Objects know to drop collections and the like when things get deleted/discarded from the cache.
Anyway, it's almost midnight here, I'm gonna grab some shut eye... and then get up tomorrow morning and rip apart Transfer some more as the whole nation stops for a horse race...
> The <setting> values get pass to the init() of the Provider.
> (Some more basic statistic based methods will be added later for simple > reporting, and tied back into the CacheMonitor)
> So you see you can set up a defaultCacheProvider, and also use a specific > CacheProvider for specific classes as well - so you can mix and match caches > (possibly at your own peril ;o) )
> Because you can also extend the Provider yourself, you can do all sorts of > weird and wonderful things.
> I'm writing up an EHCache one as the default, which will have some > limitations as to the platform it can do things on (No CF7, quite possibly > not going to work on some shared hosts, due to classpath restrictions), so > I'll be looking for other people to do some intergration as well (A ColdBox > cache adapter would be really cool, or any other cache framework). The only > major dependency is that the cache framework has to be able to tell you when > something gets discarded, as that is how Objects know to drop collections > and the like when things get deleted/discarded from the cache.
> Anyway, it's almost midnight here, I'm gonna grab some shut eye... and then > get up tomorrow morning and rip apart Transfer some more as the whole nation > stops for a horse race...
Thanks for the work. I've checked out the trunk. I'm going to switch this
today. I'm discovering the ehcache.xml config (first time). If you have a
simple ready to use xml file I'm intereted in.
>> The <setting> values get pass to the init() of the Provider.
>> (Some more basic statistic based methods will be added later for simple
>> reporting, and tied back into the CacheMonitor)
>> So you see you can set up a defaultCacheProvider, and also use a specific
>> CacheProvider for specific classes as well - so you can mix and match caches
>> (possibly at your own peril ;o) )
>> Because you can also extend the Provider yourself, you can do all sorts of
>> weird and wonderful things.
>> I'm writing up an EHCache one as the default, which will have some
>> limitations as to the platform it can do things on (No CF7, quite possibly
>> not going to work on some shared hosts, due to classpath restrictions), so
>> I'll be looking for other people to do some intergration as well (A ColdBox
>> cache adapter would be really cool, or any other cache framework). The only
>> major dependency is that the cache framework has to be able to tell you when
>> something gets discarded, as that is how Objects know to drop collections
>> and the like when things get deleted/discarded from the cache.
>> Anyway, it's almost midnight here, I'm gonna grab some shut eye... and
>> then get up tomorrow morning and rip apart Transfer some more as the whole
>> nation stops for a horse race...
I'm not 100% sure this is ready for general usage yet, as there are several
unit test suites that are not yet completing. Use very much at your own
risk.
> Thanks for the work. I've checked out the trunk. I'm going to switch this
> today. I'm discovering the ehcache.xml config (first time). If you have a
> simple ready to use xml file I'm intereted in.
>>> The <setting> values get pass to the init() of the Provider.
>>> (Some more basic statistic based methods will be added later for simple
>>> reporting, and tied back into the CacheMonitor)
>>> So you see you can set up a defaultCacheProvider, and also use a specific
>>> CacheProvider for specific classes as well - so you can mix and match caches
>>> (possibly at your own peril ;o) )
>>> Because you can also extend the Provider yourself, you can do all sorts
>>> of weird and wonderful things.
>>> I'm writing up an EHCache one as the default, which will have some
>>> limitations as to the platform it can do things on (No CF7, quite possibly
>>> not going to work on some shared hosts, due to classpath restrictions), so
>>> I'll be looking for other people to do some intergration as well (A ColdBox
>>> cache adapter would be really cool, or any other cache framework). The only
>>> major dependency is that the cache framework has to be able to tell you when
>>> something gets discarded, as that is how Objects know to drop collections
>>> and the like when things get deleted/discarded from the cache.
>>> Anyway, it's almost midnight here, I'm gonna grab some shut eye... and
>>> then get up tomorrow morning and rip apart Transfer some more as the whole
>>> nation stops for a horse race...
Yes, this is the branch I've checked out and I found this xml too.
I'm conscient that is not final, I'm using this on my own dev env. I'm just
curious to see how is the pain... ;-)
I've started to play with, no "big" problem for the moment. The application
starts.
The events binding seems not working. Will it work or I've to investigated
on ehCache side ?
ApplicationObserver.cfc->init(application.oTransfer) :
// auto register this observer
oTransfer.addBeforeCreateObserver(this);
oTransfer.addAfterCreateObserver(this);
> I'm not 100% sure this is ready for general usage yet, as there are several
> unit test suites that are not yet completing. Use very much at your own
> risk.
>> Thanks for the work. I've checked out the trunk. I'm going to switch this
>> today. I'm discovering the ehcache.xml config (first time). If you have a
>> simple ready to use xml file I'm intereted in.
>>>> The <setting> values get pass to the init() of the Provider.
>>>> (Some more basic statistic based methods will be added later for simple
>>>> reporting, and tied back into the CacheMonitor)
>>>> So you see you can set up a defaultCacheProvider, and also use a
>>>> specific CacheProvider for specific classes as well - so you can mix and
>>>> match caches (possibly at your own peril ;o) )
>>>> Because you can also extend the Provider yourself, you can do all sorts
>>>> of weird and wonderful things.
>>>> I'm writing up an EHCache one as the default, which will have some
>>>> limitations as to the platform it can do things on (No CF7, quite possibly
>>>> not going to work on some shared hosts, due to classpath restrictions), so
>>>> I'll be looking for other people to do some intergration as well (A ColdBox
>>>> cache adapter would be really cool, or any other cache framework). The only
>>>> major dependency is that the cache framework has to be able to tell you when
>>>> something gets discarded, as that is how Objects know to drop collections
>>>> and the like when things get deleted/discarded from the cache.
>>>> Anyway, it's almost midnight here, I'm gonna grab some shut eye... and
>>>> then get up tomorrow morning and rip apart Transfer some more as the whole
>>>> nation stops for a horse race...
> Yes, this is the branch I've checked out and I found this xml too.
> I'm conscient that is not final, I'm using this on my own dev env. I'm just
> curious to see how is the pain... ;-)
> I've started to play with, no "big" problem for the moment. The application
> starts.
> The events binding seems not working. Will it work or I've to investigated
> on ehCache side ?
> ApplicationObserver.cfc->init(application.oTransfer) :
> // auto register this observer
> oTransfer.addBeforeCreateObserver(this);
> oTransfer.addAfterCreateObserver(this);
>> I'm not 100% sure this is ready for general usage yet, as there are
>> several unit test suites that are not yet completing. Use very much at your
>> own risk.
>>> Thanks for the work. I've checked out the trunk. I'm going to switch this
>>> today. I'm discovering the ehcache.xml config (first time). If you have a
>>> simple ready to use xml file I'm intereted in.
>>>>> The <setting> values get pass to the init() of the Provider.
>>>>> (Some more basic statistic based methods will be added later for simple
>>>>> reporting, and tied back into the CacheMonitor)
>>>>> So you see you can set up a defaultCacheProvider, and also use a
>>>>> specific CacheProvider for specific classes as well - so you can mix and
>>>>> match caches (possibly at your own peril ;o) )
>>>>> Because you can also extend the Provider yourself, you can do all sorts
>>>>> of weird and wonderful things.
>>>>> I'm writing up an EHCache one as the default, which will have some
>>>>> limitations as to the platform it can do things on (No CF7, quite possibly
>>>>> not going to work on some shared hosts, due to classpath restrictions), so
>>>>> I'll be looking for other people to do some intergration as well (A ColdBox
>>>>> cache adapter would be really cool, or any other cache framework). The only
>>>>> major dependency is that the cache framework has to be able to tell you when
>>>>> something gets discarded, as that is how Objects know to drop collections
>>>>> and the like when things get deleted/discarded from the cache.
>>>>> Anyway, it's almost midnight here, I'm gonna grab some shut eye... and
>>>>> then get up tomorrow morning and rip apart Transfer some more as the whole
>>>>> nation stops for a horse race...
On Thu, Nov 5, 2009 at 10:50 PM, Mark Mandel <mark.man...@gmail.com> wrote:
> The EventManager Unit Tests are the ones that are currently failing at the
> moment ;o)
>> Yes, this is the branch I've checked out and I found this xml too.
>> I'm conscient that is not final, I'm using this on my own dev env. I'm
>> just curious to see how is the pain... ;-)
>> I've started to play with, no "big" problem for the moment. The
>> application starts.
>> The events binding seems not working. Will it work or I've to investigated
>> on ehCache side ?
>> ApplicationObserver.cfc->init(application.oTransfer) :
>> // auto register this observer
>> oTransfer.addBeforeCreateObserver(this);
>> oTransfer.addAfterCreateObserver(this);
>>> I'm not 100% sure this is ready for general usage yet, as there are
>>> several unit test suites that are not yet completing. Use very much at your
>>> own risk.
>>>> Thanks for the work. I've checked out the trunk. I'm going to switch
>>>> this today. I'm discovering the ehcache.xml config (first time). If you have
>>>> a simple ready to use xml file I'm intereted in.
>>>> Thanks -
>>>> Aurelien
>>>> 2009/11/4 Mark Mandel <mark.man...@gmail.com>
>>>> Just letting you all know this is alive and kicking.
>>>>> I'm just polishing off the final tests, and resolving any issues that I
>>>>> have found.
>>>>> While this is a break in backwards compatibility, this has simplified
>>>>> much of Transfer architecture, and streamlined it very nicely.
>>>>> Should see some code that is ready for testing in a day or two.
>>>>> Mark
>>>>> On Mon, Nov 2, 2009 at 11:53 PM, Mark Mandel <mark.man...@gmail.com>wrote:
>>>>>> I'm about to go to bed, but I'll give you all an update.
>>>>>> The <objectCache> section now looks akin to this:
>>>>>> The <setting> values get pass to the init() of the Provider.
>>>>>> (Some more basic statistic based methods will be added later for
>>>>>> simple reporting, and tied back into the CacheMonitor)
>>>>>> So you see you can set up a defaultCacheProvider, and also use a
>>>>>> specific CacheProvider for specific classes as well - so you can mix and
>>>>>> match caches (possibly at your own peril ;o) )
>>>>>> Because you can also extend the Provider yourself, you can do all
>>>>>> sorts of weird and wonderful things.
>>>>>> I'm writing up an EHCache one as the default, which will have some
>>>>>> limitations as to the platform it can do things on (No CF7, quite possibly
>>>>>> not going to work on some shared hosts, due to classpath restrictions), so
>>>>>> I'll be looking for other people to do some intergration as well (A ColdBox
>>>>>> cache adapter would be really cool, or any other cache framework). The only
>>>>>> major dependency is that the cache framework has to be able to tell you when
>>>>>> something gets discarded, as that is how Objects know to drop collections
>>>>>> and the like when things get deleted/discarded from the cache.
>>>>>> Anyway, it's almost midnight here, I'm gonna grab some shut eye... and
>>>>>> then get up tomorrow morning and rip apart Transfer some more as the whole
>>>>>> nation stops for a horse race...
|
