[
https://issues.apache.org/jira/browse/COUCHDB-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805379#action_12805379
]
Chris Anderson commented on COUCHDB-583:
----------------------------------------
I ran the etap test (don't forget to make it executable)
And got this output:
$ ./test/etap/run ./test/etap/140-attachment-comp.t
# Current time local 2010-01-26 21:57:12
# Using etap version "0.3.4"
1..57
Apache CouchDB 0.0.0 (LogLevel=info) is starting.
Apache CouchDB has started. Time to relax.
[info] [<0.2.0>] Apache CouchDB has started on http://127.0.0.1:5984/
# Test died abnormally: {'EXIT',{{badmatch,{error,enoent}},[{erl_eval,expr,3}]}}
[error] [<0.31.0>] {error_report,<0.23.0>,
{<0.31.0>,crash_report,
[[{initial_call,{etap,start_etap_server,[]}},
{pid,<0.31.0>},
{registered_name,etap_server},
{error_info,
{exit,
{badarg,
[{io,format,
[<0.23.0>,"~s~n",
[[66,97,105,108,32,111,117,116,33,32|
{'EXIT',{{badmatch,{error,enoent}},[{erl_eval,expr,3}]}}]]]},
{etap,test_server,1},
{proc_lib,init_p_do_apply,3}]},
[{io,o_request,3},{etap,test_server,1},{proc_lib,init_p_do_apply,3}]}},
{ancestors,[<0.2.0>]},
{messages,[done]},
{links,[]},
{dictionary,[]},
{trap_exit,false},
{status,running},
{heap_size,377},
{stack_size,24},
{reductions,451}],
[]]}}
On the other hand, the Futon tests pass, and I browsed to an old database file
and was able to load attachments from it so that's some good news.
> storing attachments in compressed form and serving them in compressed form if
> accepted by the client
> ----------------------------------------------------------------------------------------------------
>
> Key: COUCHDB-583
> URL: https://issues.apache.org/jira/browse/COUCHDB-583
> Project: CouchDB
> Issue Type: New Feature
> Components: Database Core, HTTP Interface
> Environment: CouchDB trunk
> Reporter: Filipe Manana
> Attachments: couchdb-583-trunk-10th-try.patch,
> couchdb-583-trunk-11th-try.patch, couchdb-583-trunk-12th-try.patch,
> couchdb-583-trunk-13th-try.patch, couchdb-583-trunk-14th-try-git.patch,
> couchdb-583-trunk-15th-try-git.patch, couchdb-583-trunk-3rd-try.patch,
> couchdb-583-trunk-4th-try-trunk.patch, couchdb-583-trunk-5th-try.patch,
> couchdb-583-trunk-6th-try.patch, couchdb-583-trunk-7th-try.patch,
> couchdb-583-trunk-8th-try.patch, couchdb-583-trunk-9th-try.patch,
> jira-couchdb-583-1st-try-trunk.patch, jira-couchdb-583-2nd-try-trunk.patch
>
>
> This feature allows Couch to gzip compress attachments as they are being
> received and store them in compressed form.
> When a client asks for downloading an attachment (e.g. GET
> somedb/somedoc/attachment.txt), the attachment is sent in compressed form if
> the client's http request has gzip specified as a valid transfer encoding for
> the response (using the http header "Accept-Encoding"). Otherwise couch
> decompresses the attachment before sending it back to the client.
> Attachments are compressed only if their MIME type matches one of those
> listed in a separate config file. Compression level is also configurable in
> the default.ini file.
> This follows Damien's suggestion from 30 November:
> "Perhaps we need a separate user editable ini file to specify compressable or
> non-compressable files (would probably be too big for the regular ini file).
> What do other web servers do?
> Also, a potential optimization is to compress the file while writing to disk,
> and serve the compressed bytes directly to clients that can handle it, and
> decompressed for those that can't. For compressable types, it's a win for
> both disk IO for reads and writes, and CPU on read."
> Patch attached.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
