[ic] Interchange crashing when updating order status in admin.

[Cameron G]

> -----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. :/