hi,

i want to use mod_archive module. i have downloaded ejabberd modules and follow the step in http://www.ejabberd.im/ejabberd-modules. i have generated mod_archive.beam file by compiling mod_archive.erl and put this file in Applications/ejabberd-13.12/lib/ejabberd-13.12/ebin (mac os).
but when start module i got following crash report.

2014-04-22 12:07:13 =CRASH REPORT====
crasher:
initial call: mod_archive:init/1
pid: <0.505.0>
registered_name: []
exception exit: {{{case_clause,undefined},[{gen_iq_handler,add_iq_handler,6,[{file,"src/gen_iq_handler.erl"},{line,65}]},{mod_archive,init,1,[{file,"mod_archive.erl"},{line,126}]},{gen_server,init_it,6,[{file,"gen_server.erl"},{line,304}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]},[{gen_server,init_it,6,[{file,"gen_server.erl"},{line,328}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]}
ancestors: [ejabberd_sup,<0.37.0>]
messages: []
links: [<0.308.0>]
dictionary: []
trap_exit: false
status: running
heap_size: 610
stack_size: 27
reductions: 164
neighbours:

please, can anyone help me.
thanks in advance.

Hi,
I set the mod_archive_odbc in my server and apparently work. But when I send a offline message to any contact, the mod_archive_odbc save in database the message, then when the contact receive the message the mod_archive_odbc save again the same message. Resulting in something like that:

Initially I think it's a problem in my javascript client, but I tested it in other clients and all to the same.

Now I don't know if it is a server problem or a client bad implementation problem.

Anyone have a ideia how to fix it or a better way to do that?

Thank you and sorry for my english,

Bottin

P.S.: I tryed the mod_offline and the mod_offline_odbc

Would like to know if there are any plans to add Oracle and/or SQL server support to mod_archive.

Also, am interested to know if DB calls are asynchronous and if there are issues w/ memory consumption under heavy load (e.g., queue of db writes grows). I know that IM compliance/proxy solutions like Actiance deal with this by writing to a persistent message queue (MSMQ) because write time to a queue is much faster than the db while having the benefit of being persistent and have a separate process to perform the db write (sometimes in bulk).

Dave

i am having huge trouble getting mod_archive to work using postgresql via odbc as a backend.

when trying to retrieve messages from the archive i get the following error:

any hint is highly appreciated.

Patch given at http://www.ndl.kiev.ua/content/mod_archive_odbc-release#comment-265 fixes the issue because of which mod_archive_webview was not working. The patch has been tested with ejabberd 2.1.5 and mod_archive r1057 in Debian Squeeze. Here is a copy of the patch.

Hi,
I've sometimes issues to listing a collection.
The XMPP stanzas that fail are something like this:

  <iq type='get' xmlns='jabber:client'>
   <list xmlns='http://www.xmpp.org/extensions/xep-0136.html#ns' with='test@localhost' start='2010-11-2T00:00:00.000000Z'>
     <set xmlns='http://jabber.org/protocol/rsm'>
        <max>5</max>
     </set>
    </list>
  </iq>

There are days it works like a charm and days where I get an "internal server error" as response.
After restarting the ejabberd server it works again.
I've seen a similar issue on http://www.ndl.kiev.ua/content/mod_archive_odbc-release but it was
a PosgreSQL problem.

My config is:
- ejabberd version ejabberd-2.1.3
- mod_archive_odbc at revision 1057 from https://svn.process-one.net/ejabberd-modules/mod_archive
- RDBMS MySQL 5.0.26

ejabberd.cfg

{mod_archive_odbc, [{database_type, "mysql"},
{default_auto_save, true},
{enforce_default_auto_save, true},
{default_expire, infinity},
{enforce_min_expire, 0},
{enforce_max_expire, infinity},
{replication_expire, 31536000},
{session_duration, 1800},
{wipeout_interval, 86400}]},

the config is a result of http://www.ndl.kiev.ua/content/mod_archive_odbc-release

The log looks like this :

E(<0.2977.0>:mod_archive_odbc:2428) : failed transaction: {aborted,
{{badmatch,
{aborted,
"query timed out"}},
[{mod_archive_odbc,
get_last_inserted_id,
2},
{mod_archive_odbc,
get_collection_id,
1},
{mod_archive_odbc,
new_dict_answer,
5},
{mod_archive_odbc,
'-do_log/12-fun-0-',
13},
{ejabberd_odbc,
outer_transaction,
3},
{ejabberd_odbc,
session_established,
3},
{p1_fsm,
handle_msg,10},
{proc_lib,
init_p,5}]}}, stack: {backtrace,
<<"Program counter: 0xb7c234e4 (unknown function)\nCP: 0xb30dfb00 (mod_archive_odbc:run_sql_transaction/2 + 232)\n\n0xb3effe24 Return addr 0xb30d3da4 (mod_archive_odbc:do_log/12 + 256)\ny(0) {aborted,{{badmatch,{aborted,\"query timed out\"}},[{mod_archive_odbc,get_last_inserted_id,2},{mod_archive_odbc,get_collection_id,1},{mod_archive_odbc,new_dict_answer,5},{mod_archive_odbc,'-do_log/12-fun-0-',13},{ejabberd_odbc,outer_transaction,3},{ejabberd_odbc,session_established,3},{p1_fsm,handle_msg,10},{proc_lib,init_p,5}]}}\n\n0xb3effe2c Return addr 0xb30d2a78 (mod_archive_odbc:handle_cast/2 + 460)\ny(0) []\ny(1) []\ny(2) []\ny(3) {dict,0,16,16,8,80,48,{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]},{{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]}}}\ny(4) []\ny(5) []\ny(6) []\ny(7) []\ny( []\ny(9) []\ny(10) []\n\n0xb3effe5c Return addr 0xb6a59d14 (gen_server:handle_msg/5 + 932)\ny(0) []\ny(1) []\ny(2) []\ny(3) []\ny(4) []\ny(5) []\ny(6) []\ny(7) []\ny( []\ny(9) []\ny(10) []\ny(11) []\ny(12) {state,\"handelsplattform.zentrale.de\",{dict,0,16,16,8,80,48,{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]},{{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]}}},1800}\n\n0xb3effe94 Return addr 0xb6a637ec (proc_lib:init_p/5 + 200)\ny(0) mod_archive_odbc\ny(1) {state,\"handelsplattform.zentrale.de\",{dict,0,16,16,8,80,48,{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]},{{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]}}},1800}\ny(2) 'ejabberd_mod_archive_odbc_handelsplattform.zentrale.de'\ny(3) <0.251.0>\ny(4) {'$gen_cast',{addlog,\"chat\",to,\"vmuth\",\"handelsplattform.zentrale.de\",\"40554349641283841483603324\",{jid,\"mttest\",\"handelsplattform.zentrale.de\",[],\"mttest\",\"handelsplattform.zentrale.de\",[]},[],[],[],\"wird das auf der db hinterlegt?\"}}\ny(5) Catch 0xb6a59d14 (gen_server:handle_msg/5 + 932)\n\n0xb3effeb0 Return addr 0x081dbe40 ()\ny(0) Catch 0xb6a637fc (proc_lib:init_p/5 + 216)\ny(1) gen\ny(2) init_it\ny(3) [gen_server,<0.251.0>,<0.251.0>,{local,'ejabberd_mod_archive_odbc_handelsplattform.zentrale.de'},mod_archive_odbc,[\"handelsplattform.zentrale.de\",[{database_type,\"mysql\"},{default_auto_save,true},{enforce_default_auto_save,true},{default_expire,infinity},{enforce_min_expire,0},{enforce_max_expire,infinity},{replication_expire,31536000},{session_duration,1800},{wipeout_interval,86400}]],[]]\n">>}

=ERROR REPORT==== 2010-09-07 08:39:23 ===
E(<0.2977.0>:mod_archive_odbc:489) : error when performing automated archiving: {xmlelement,
"error",
[{"code",
"500"},
{"type",
"wait"}],
[{xmlelement,
"internal-server-error",
[{"xmlns",
"urn:ietf:params:xml:ns:xmpp-stanzas"}],
[]}]}

For any looking for xep-0136 capable client - vacuum im (open-source, cross-platform, http://code.google.com/p/vacuum-im/) supports server-side history. I was able to build ejabberd+mod_archive_odbc+mysql and server-side history works for me now - only reasonably working client I found is vacuum im. If anyone knows more xep-0136 capable clients - please post them here.

Hi,
I am using ejabberd 2.0.1 on Debian Lenny which has been patched with mod_archive module taken from trunk. I have followed all the instructions in README.txt and http://www.ndl.kiev.ua/content/mod_archive_odbc-release for setting it up. The messages get archived properly. But when I try to access the archive via my browser using the URL http://localhost:5280/archive/ ejabberd, it throws an error as shown below in sasl.log:

I tried to debug but hardly have any knowledge of erlang. Is something wrong with my configuration or is mod_archive_webview broken? Looking forward for any possible support in resolving this issue.

New version, mod_archive_odbc is available at http://www.ndl.kiev.ua/typo/articles/2007/11/14/mod_archive_odbc-release

This version, I hope, should solve quite some problems existed in earlier implementations.

1) when I retrieve message page from collection I cannot retrieve next page by 'last' value (something here last value return the same page that first)

2) when I retrieve archive store, they have wrong timestamp (it is not UTC). Maybe I must to change some config settings?

I have -vsn('$Revision: 702 $ ').

Can it store the archived messages in odbc/sql/wherever, or only in mnesia? Because with current client support, (that is, lack thereof) sql storage is essential, since it's the only way to get at the logs. You can expect to turn automated logging on from an XML console, but reading them that way would be pointless.