[ic] Interchange crashing when updating order status in admin.
ritontor at icenet.com.au
Sat Oct 18 15:16:52 EDT 2003
> -----Original Message-----
> From: interchange-users-bounces at icdevgroup.org
> [mailto:interchange-users-bounces at icdevgroup.org] On Behalf
> Of Mike Heins
> Sent: Friday, October 17, 2003 11:38 PM
> To: interchange-users at icdevgroup.org
> Subject: Re: [ic] Interchange crashing when updating order
> status in admin.
> Quoting Cameron G (ritontor at icenet.com.au):
> > Here's an interesting one, and I'm at a bit of a loss to
> explain it so far.
> > Here's the overview.
> > When processing orders and updating their status on one of
> the sites
> > that run on a particular server, IC crashes - most of the time, but
> > not all of the time. The other sites on the machine work perfectly.
> > Here's an example of strace -f -p output that shows where I *think*
> > the child process is breaking, incriminating details (like
> the admin
> > username, which is where the issue may be?) have been changed. Up
> > until this point, both traces appear to be basically identical...
> > THE BAD STRACE:
> > [pid 7000] <... read resumed>
> "\5\0\0\0\r\0\0\0\3510\0\0007\0\0\0\2620\0\0D\0\0\0D6\0"..., 4096) =
> > 4096 [pid 6999] <... rt_sigprocmask resumed> , 8) = 0
> [pid 7000]
> > lseek(12, 12288, SEEK_SET <unfinished ...> [pid 6999]
> > rt_sigprocmask(SIG_BLOCK, NULL, <unfinished ...>
> > [pid 7000] <... lseek resumed> ) = 12288
> > [pid 6999] <... rt_sigprocmask resumed> , 8) = 0 [pid 7000]
> > read(12, <unfinished ...> [pid 6999]
> rt_sigprocmask(SIG_BLOCK, NULL,
> > <unfinished ...> [pid 7000] <... read resumed>
> > "cusername\tpassword\tname\tlast_log"...,
> > 178) = 178
> This looks like you are running your userdb on GDBM or some
> other non-SQL database. Not recommended, especially for busy
> sites. Interchange does a lot of database updates in the
> latest foundation catalogs, and if you have a lot of
> logged-in users this can easily happen.
> It probably means you are getting caught up in write
> contention that can't be resolved.
> Try switching the userdb, transactions, and orderline tables
> to SQL and see what happens then.
I already am running on mysql, and have been for several months now. :/
More information about the interchange-users