Adam Heath wrote: > I can give you a list a mile long of problems with ofbiz, if you want > it. Usability issues. Unimplemented features. Half-finished code. > Things all over. It's like people who are writing code aren't even > using what they are writing.
(replying to myself, with a few more examples) JobSandbox is stupid. We at brainfood hate it. Very much. It craps out when there are problems. Let's say I'm trying to make gift certificate purchases work thru a new web frontend. As I'm doing this, I am doing things wrong. Ok, fine, I can accept that, I'm learning. But, during this process, when I attempt to convert a ShoppingCart to a real order, ofbGcPurchase is called asynchronously. This is part of the digital good fulfillment process. Still no problem. But, because of a bug in my code, there was no associated SurveyResponse to this OrderItem for the gift certificate. So, the ofbGcPurchase that was run asynchronously, and stored in the JobSandbox fails. Still no problem, really. However, this JobSandbox entry runs over and over and over, without ever stopping, and without any hope of ever finishing. It should *not* continue to retry. Period. This causes excess load. Even more so when tons of things fail, and they keep getting retried. When cron in unix runs a job, and it fails, it doesn't keep retrying it. Additionally, when a service requires a UserLogin object, and it is scheduled to run in the future, but then the user changes their password, the service will never succeed. The only real way to fix this is to *not* store the authentication principals in the context, but store them in a separate location, kinda out-of-band(we could still make use of an xml serializer when storing them into the database).
