Nick,
What might be most helpful is to describe the symptoms and errors
you're actually seeing instead of an interpretation of them (it's hard
to guess at whether you interpretation is correct or not, or what that
might mean relative to what people know about the system).
For example, what do you mean by "the service does not appear to
return a clean error"? The most complete way to answer that is
answering the questions:
1. what did the user do
2. what did you expect (or hope!) to happen
3. what actually happened
You also mention DB locks, and until those are known to be caused by
the issue it might be best to treat them as an independent symptom,
possibly to an independent problem. The DB locks may actually be the
cause of certain problems as opposed to being caused by. The best
thing for DB lock wait timeout errors (which is what I assume you're
getting based on what you said, but you should verify that) is to send
over the actual error message the user sees and the relevant errors in
the log file (possibly before and after the main error).
Going back to the beginning of this problem: why are the captures
failing? Is there an error message that might help lead to a
resolution? Is it because the CC processor is down or something and
you don't like the way OFBiz is handling it? If so, what is the
process you'd like to see OFBiz follow in order to handle it?
BTW, these are questions I'd start asking were I working on fixing
this. You don't necessarily have to answer all of them on the mailing
list, though that would be the best way to get help from the
community. You can also just use these internally to help focus the
efforts of your people.
-David
On Oct 15, 2008, at 12:47 PM, Nick Rosser wrote:
Hi,
We have recently deployed OFBiz into our clients production
environment. The
following is typical of a serious issue we are experiencing:
* run Pick n Pack, in a batch job
* if we get an error in the "capture" process:
o the service does not appear to return a clean error
o it attempts re-auth, capture again etc.
o ultimately we are experiencing DB locks because of the
above (I
assume that while waiting for the payment processing the 80 or so
users are
experiencing db locking issues)
Is there a way to simply return a "capture" failure, we'll skip that
Order
and move on?
BTW: in dev test/debug, we are seeing some pretty complex code
managing all
these iterations (re-auth etc.) but ultimately the order goes into
'pick'
and is 'completed'. We are assuming that the store setting "Ship If
Capture
Fails = Y". Could someone confirm?
We are also looking into the usage of the following "store"
settings, so if
anyone has insight as to how these setting may relate to the problem
it
would be much appreciated:
Assume this setting will keep retrying to authorize (for n times?)
if the
authorization fails:
Retry Failed Auths = Y
Assume these are as labeled, keep trying in the event of a failure:
Auto Order Cc Try Exp: Y
Auto Order Cc Try Other Cards: Y
Auto Order Cc Try Later Nsf: Y
Auto Order Cc Try Later Max: blank
(BTW: our client ships 2000 orders per day, and runs their operation
with 80
customer service reps . any help appreciated since this is impacting
their
business)
Regards,
Nick Rosser
[EMAIL PROTECTED]
O: 516.742.7888 x221
C: 516.901.1720
F: 516.742.9169
Visit us at www.salmonllc.com
