> I want this to be triggered by the URL when the image is requested
I hope you have a good reason. That request is going to be noticeably slow
and your server will be very busy if there are a lot of requests.
On Wed, Nov 20, 2013 at 4:42 PM, Keith Gable wrote:
> You could probably add a proxy
You could probably add a proxy handler thing like CouchDB Lucene used
at one point, then have it fetch the attachment and run IM and return
the image. Sounds like a great way to exhaust server resources though.
From: Hank Knight
Sent: 11/20/2013 17:53
To: user@couchdb.apache.org
Subject: Re: CouchD
I want this to be triggered by the URL when the image is requested,
not when the image is uploaded.
For example:
https://zuhqtr5.couchappy.com/site/www/qqq/z.jpg/resized/201x201/www/qqq/z.jpg
https://zuhqtr5.couchappy.com/site/www/qqq/z.jpg/resized/202x202/www/qqq/z.jpg
https://zuhqtr5.couchappy.c
We are combining clients onto larger servers. We are testing what we
anticipate will be peak usage (in this case 30 simultaneous users). So this
will roughly emulate the goal.
We are building indexes, but those appear to be cached. At least after the
initial data migration there is a very slow per
TCP no delay?... Plus are you building a lot of indexes?... If you're just
serving documents I'm surprised it doesn't cache it all and mind its own
business I'm curious...is your test testing what yours actually going
to be using it for or are they just Benchmarks?
On Nov 20, 2013 3:24 PM, "Joe
Thanks for the helpful responses earlier. Couch crashing was actually a
result of a code bug, but with that fixed, we are still have performance
problems. I would appreciate any and all suggestions that might help
improve performance.
thanks,
joe
What I've tried:
I've upgraded to couch 1.5.0
I'
Yeah..it seems that way...but Imagine a scenario where there are a lot of
writes... But few reads... Like...tracking user installs...and queries that
occasionally need to see the number of installs... Unless that query is
being run often... It will fall behind and anyone waiting for it to reindex
w
Idk..it sounds hackey.. But curl and crontab is good enough for me for the
views that can't fall more than 1 minute behind
Depends on your use case, I don't think it's any more hackey than
cron/curl. Crontab is good for scheduling, but if you want to refresh the
view depending on what *actually*
> .it sounds hackey.
Just use update_after. It's not a hack.
On Wed, Nov 20, 2013 at 2:59 PM, Stanley Iriele wrote:
> Idk..it sounds hackey.. But curl and crontab is good enough for me for the
> views that can't fall more than 1 minute behind
> On Nov 20, 2013 2:57 PM, "Robert Newson" wrote:
Idk..it sounds hackey.. But curl and crontab is good enough for me for the
views that can't fall more than 1 minute behind
On Nov 20, 2013 2:57 PM, "Robert Newson" wrote:
> The bigcouch merge will not bring any automatic view updating
> scheduler. Nothing stops someone contributing one, of course
The bigcouch merge will not bring any automatic view updating
scheduler. Nothing stops someone contributing one, of course.
B.
On 20 November 2013 22:49, Mike Marino wrote:
> There are, of course, ways to get couchdb to update views dependent on
> writes. I also believe this is supposed to get
I would use a simple node program that "watches" all the image uploads and
then runs imagemagick
On Wed, Nov 20, 2013 at 2:36 PM, Hank Knight wrote:
> Here is an example of an image attachment served by CouchDB:
> https://zuhqtr5.couchappy.com/site/www/qqq/z.jpg
>
> I would like a CouchDB modu
There are, of course, ways to get couchdb to update views dependent on
writes. I also believe this is supposed to get easier in the future
(included in the bigcouch merge?).
> Am 20.11.2013 um 23:46 schrieb Simon Metson :
>
> Nope, views are updated on read, hence the "blocking" behaviour you desc
Nope, views are updated on read, hence the "blocking" behaviour you describe.
You can query with update_after, which returns the stale index then triggers
the update.
On Wednesday, 20 November 2013 at 22:43, Mark Hahn wrote:
> I thought that every write triggered a view rebuild and that the
I thought that every write triggered a view rebuild and that the stale
option only meant a read didn't have to wait for a current rebuild to
finish. That would means the views are pretty much up-to-date.
On Wed, Nov 20, 2013 at 2:36 PM, Robert Newson wrote:
> True, but remember couchdb doesn't
Here is an example of an image attachment served by CouchDB:
https://zuhqtr5.couchappy.com/site/www/qqq/z.jpg
I would like a CouchDB module that would use ImageMagick to
automatically resize an image based on parameters passed in the URL.
https://github.com/kivra/emagick
For example this should r
True, but remember couchdb doesn't automatically keep indexes fresh in
the background, so "stale" can be "really really stale". ;)
B.
On 20 November 2013 22:34, Simon Metson wrote:
> Unless your app can deal with querying the view stale.
>
>
> On Wednesday, 20 November 2013 at 21:56, Mark Hahn
Unless your app can deal with querying the view stale.
On Wednesday, 20 November 2013 at 21:56, Mark Hahn wrote:
> I meant http view requests were blocked. It is waiting for the view
> rebuild.
>
> I'm can't type what I'm thinking today.
>
>
> On Wed, Nov 20, 2013 at 1:54 PM, Mark Hahn wro
I meant http view requests were blocked. It is waiting for the view
rebuild.
I'm can't type what I'm thinking today.
On Wed, Nov 20, 2013 at 1:54 PM, Mark Hahn wrote:
> never mind. I wasn't talking about the file level at all. I meant that
> http read requests are blocked after http update
never mind. I wasn't talking about the file level at all. I meant that
http read requests are blocked after http update requests.
On Wed, Nov 20, 2013 at 1:52 PM, Robert Newson wrote:
> "DB reads are blocked by DB updates at the http level."
>
> Nope, there's a process that can read the databa
When you say blocked... Do you mean time for the view to build? Or waiting
to get a doc out of the database while its being written?.. I thought couch
db was mvcc so there was none of that
On Nov 20, 2013 1:36 PM, "Mark Hahn" wrote:
> > Database writes are not coupled to view updates.
>
> I under
"DB reads are blocked by DB updates at the http level."
Nope, there's a process that can read the database and a separate one
for writing to it. Writing to an append only file is obviously
serialized but there's no need to block reads.
B.
On 20 November 2013 21:35, Mark Hahn wrote:
>> Database
> Database writes are not coupled to view updates.
I understand now, you are talking about file read/write level. DB reads
are blocked by DB updates at the http level.
On Wed, Nov 20, 2013 at 1:05 PM, Robert Newson wrote:
> "A write requires updating views and reads have to wait for the update
"A write requires updating views and reads have to wait for the update"
Is not true. Database writes are not coupled to view updates.
Sent from my iPad
> On 20 Nov 2013, at 20:59, Mark Hahn wrote:
>
> A write requires updating views and reads have
> to wait for the update
> And read requests are never, ever blocked, even during a write,
I don't think this is true. A write requires updating views and reads have
to wait for the update. You can tell it to not wait and use stale values
but that impairs consistency.
On Wed, Nov 20, 2013 at 8:56 AM, Jens Alfke wrote
I guess this was released from moderation by someone that didn't see
your other email after you subscribed, let's consider this thread
dead?
B.
On 19 November 2013 21:16, Diogo Moitinho de Almeida wrote:
> Hello,
>
> Based on the research that I've done, CouchDB seems like a very good fit for
>
John,
On 11/19/2013 04:28 AM, John Norris wrote:
> I am trying to retrofit an existing web app using SQL to couchdb with
> ektorp. I have setup couchdb and run through some tutorials (ektorp,
> seven databases in seven weeks, definitive guide).
> If I have several objects (represented as pojos) th
John,
On 11/19/2013 04:28 AM, John Norris wrote:
> I am trying to retrofit an existing web app using SQL to couchdb with
> ektorp. I have setup couchdb and run through some tutorials (ektorp,
> seven databases in seven weeks, definitive guide).
> If I have several objects (represented as pojos) th
On Nov 19, 2013, at 2:28 AM, John Norris
mailto:j...@norricorp.f9.co.uk>> wrote:
But in couchdb, a database is a number of documents? And those documents
can represent several object types? So do I need each document to have a
field representing what type it is? (eg a field that is unique to tha
Im sure this is simple, but I cant find an answer.
I installed CouchDB on windows, added an admin password and now I cant
login to Futon.
I tried http://admin:admin@futon
and it still says admin only.
So how do I login to futon after Ive set up a password?
Hi,
I am trying to retrofit an existing web app using SQL to couchdb with
ektorp. I have setup couchdb and run through some tutorials (ektorp,
seven databases in seven weeks, definitive guide).
If I have several objects (represented as pojos) then in SQL this would
probably equate to several ta
Hello,
Based on the research that I've done, CouchDB seems like a very good fit
for the problem I'm trying to solve, but when talking to people from
within the company, they're expressed that there are some unadvertised
down sides to it (though they tried using it 3 years ago) and that we
wou
So far I only tried 1.5 and was somewhat reluctant to start from scratch
with an earlier version since it already took some days to synch 50gb but
at this point I am out of options so I will give 1.2 a shot.
Thanks,
Ed
On Mon, Nov 18, 2013 at 3:06 PM, Nathan Vander Wilt <
nate-li...@calftrail.c
On Nov 20, 2013, at 8:01 AM, Robert Newson wrote:
> There's no such thing in couchdb. Databases are append-only, there's a
> single writer, but concurrent PUT/POST requests are faster than serial
> anyway, and each writes to different databases are fully independent.
And read requests are never
@Diogo Have you considered using cloudant? :)
On Wed, Nov 20, 2013 at 11:01 AM, Robert Newson wrote:
> 1) "a stop the world lock when writing to disk"
>
> There's no such thing in couchdb. Databases are append-only, there's a
> single writer, but concurrent PUT/POST requests are faster than ser
1) "a stop the world lock when writing to disk"
There's no such thing in couchdb. Databases are append-only, there's a
single writer, but concurrent PUT/POST requests are faster than serial
anyway, and each writes to different databases are fully independent.
2) Stack traces are hard to read, not
Hello,
Based on the research that I've done, CouchDB seems like a very good fit
for the problem I'm trying to solve, but when talking to people from within
the company, they're expressed that there are some unadvertised down sides
to it (though they tried using it 3 years ago) and that we would ha
Sure - I have several fields in the document and in principle, the
client could send only what it changed - if it was also guaranteed to be
the only writer (or I could send rev id to check).
But that requires my client to remember more state. I am happy with
sending entire document for now.
Right...are you loading the entire json object out of the
database?...messing with it..and then placing it back?
Why not just send what you need?...in the http request?..that way you don't
have to maintain the rev number...because the way you have it now if
something updates the document out of pl
I would like to do both update and run update handler - without having a
window of time between the client update and sever side update handler.
What is wrong with this ?
On 11/20/2013 03:36 AM, Stanley Iriele wrote:
Wait...I believe you''re fundamentally have the idea of the update handler
w
Wait...I believe you''re fundamentally have the idea of the update handler
wrong
"curl -s -X PUT 'http://localhost:5984/i7rmdb/_design/compnbd/_update/
timestamp/testid' -d @/tmp/2.json"
you don't need to pass in that json file
an update handler loads the latest version of that doc from the data
Ok - got it
I should have used
var newdoc = JSON.parse(req.body) ;
I guess returning string as the first arg was somehow silently
ignored. Also the permissiveness of javascript allowed the rest of the
code to run without exception
js> newdoc = "hello world" ;
"hello world"
js> var d =
Ok - so we are taking about the first problem only.
If I try this, then I get not update to the data at all:
function(doc, req) {
if( doc.type == "profile" ) {
var newdoc = req.body ;
var d = new Date();
newdoc.serverISO8601time = d.toISOString();
newdoc.serve
On Wed, Nov 20, 2013 at 12:01 PM, Vivek Pathak wrote:
> On 11/20/2013 02:48 AM, Alexander Shorin wrote:
>>
>> First problem is that your update function works with `doc` argument -
>> that is the stored within database document -, not that you had sent
>> with PUT request. To process the request p
On 11/20/2013 02:48 AM, Alexander Shorin wrote:
First problem is that your update function works with `doc` argument -
that is the stored within database document -, not that you had sent
with PUT request. To process the request payload you need to work with
req.body data, but in your case this
45 matches
Mail list logo
