xfer problems between 2.3.15 and 2.4.17

gavin.gray at ed.ac.uk gavin.gray at ed.ac.uk
Tue Jun 10 06:26:14 EDT 2014


Hi Wes,

It looks like the whole mupdate thing is working perfectly well.
If I create a folder while connected to my 2.4.17 frontend then the logs 
show the backend issuing the cmd_set and then a bunch of cmd_find going 
out including to the frontend in question. Furthermore the new folder 
really is there in the mailboxes.db on the frontend. So in a way that's 
reassuring, but then why is the frontend telling email clients that the 
folder doesn't exist when a request to subscribe to it comes in? We aren't 
seeing any kick_mupdate getting logged.

The only thing is we see two cmd_sets is that normal? :

Jun 10 11:07:29 mupd1 mupdate[31917]: cmd_set(fd:5, user.gaving.gavarella)
Jun 10 11:07:30 mupd1 mupdate[31917]: cmd_set(fd:5, user.gaving.gavarella)
Jun 10 11:07:30 mupd1 mupdate[31917]: cmd_find(fd:29, 
user.gaving.gavarella)
Jun 10 11:07:30 mupd1 mupdate[31917]: cmd_find(fd:29, 
user.gaving.gavarella)
Jun 10 11:07:30 mupd1 mupdate[31917]: cmd_find(fd:24, 
user.gaving.gavarella)
Jun 10 11:07:30 mupd1 mupdate[31917]: cmd_find(fd:24, 
user.gaving.gavarella)
Jun 10 11:07:30 mupd1 mupdate[31917]: cmd_find(fd:25, 
user.gaving.gavarella)
Jun 10 11:07:30 mupd1 mupdate[31917]: cmd_find(fd:25, 
user.gaving.gavarella)
Jun 10 11:07:30 mupd1 mupdate[31917]: cmd_find(fd:10, 
user.gaving.gavarella)
Jun 10 11:07:30 mupd1 mupdate[31917]: cmd_find(fd:10, 
user.gaving.gavarella)
Jun 10 11:07:31 mupd1 mupdate[31917]: cmd_find(fd:11, 
user.gaving.gavarella)
Jun 10 11:07:31 mupd1 mupdate[31917]: cmd_find(fd:11, 
user.gaving.gavarella)
Jun 10 11:07:31 mupd1 mupdate[31917]: cmd_find(fd:36, 
user.gaving.gavarella)
Jun 10 11:07:31 mupd1 mupdate[31917]: cmd_find(fd:36, 
user.gaving.gavarella)
Jun 10 11:07:31 mupd1 mupdate[31917]: cmd_find(fd:26, 
user.gaving.gavarella)
Jun 10 11:07:31 mupd1 mupdate[31917]: cmd_find(fd:38, 
user.gaving.gavarella)
Jun 10 11:07:31 mupd1 mupdate[31917]: cmd_find(fd:38, 
user.gaving.gavarella)
Jun 10 11:07:31 mupd1 mupdate[31917]: cmd_find(fd:14, 
user.gaving.gavarella)
Jun 10 11:07:31 mupd1 mupdate[31917]: cmd_find(fd:22, 
user.gaving.gavarella)
Jun 10 11:07:31 mupd1 mupdate[31917]: cmd_find(fd:22, 
user.gaving.gavarella)
Jun 10 11:07:31 mupd1 mupdate[31917]: cmd_find(fd:26, 
user.gaving.gavarella)
...

fd 38, and 26 is the 2.4.17 frontend in question. Thanks for helping out 
with this.

Gavin

On Mon, 9 Jun 2014, Wesley Craig wrote:

> On 09 Jun 2014, at 07:14, gavin.gray at ed.ac.uk wrote:
>> Actually we get very little logged on our mupdate master, just logins, checkpointing notices etc, nothing about the work done to maintain folder state. It's one of the reasons we feel so in the dark with this issue.
>
> Set logging on the mupdate master to debug, it shares lots of details.  In particular, you want to see cmd_set and cmd_find.  The cmd_set is from the backend making changes to the mupdate master.  The cmd_find is *either* a frontend looking for particular mailboxes *or* the normal streaming of state change events from the mupdate master to the frontends.  Obviously, there can be timing issues, but the typical paradigm implemented on the frontends is that when an expected mailbox isn't there, the frontend will specifically ask the mupdate master about it using a kick_mupdate().
>
> :wes
>

Gavin Gray
Edinburgh University Information Services
Rm 2013 JCMB
Kings Buildings
Edinburgh
EH9 3JZ
UK
tel +44 (0)131 650 5987
email gavin.gray at ed.ac.uk

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


More information about the Info-cyrus mailing list