Le 07/10/2014 07:10, Jacopo Cappellato a écrit :
Hi Darrell,
sorry for the late response, please see inline:
On Oct 6, 2014, at 4:20 PM, darrell73s <darrellof...@gmail.com> wrote:
Jacopo, all,
I checked into the "quick ship" feature and confirmed my thought earlier: it
appears that quick ship will not work without the store having the "Reserve
Inventory" set to "Y".
Yes, reservations are definitely needed if you have to manage the warehouse
(reserve, pick, pack, ship).
I have asked you to disable the flag just to confirm that the bottleneck was
the db lock contention on the InventoryItem records.
Unfortunately there is not an easy fix for this issue that shows up when you
have medium-high traffic (caused by concurrent order creation/reservations and
picking/packing) over the same inventory items.
Scott and I discussed some possible solutions for this issue, but they will
require some rather complex refactoring of the inventory reservation logic; in
my opinion this is something we should tackle because it will help to scale
OFBiz much more than it is possible now, but I doubt it will happen today or
tomorrow.
I think I will be interested to participate at this effort, if we can
coordinate it somehow
Jacques
However, now that we know where the bottleneck is, there are a few things you
can do to alleviate this issue.
For example you can create several inventory items for the same product; you can
easily do this using Facility->Receive Product (every time you receive products
a new inventory item is created).
For example, if in your load tests you want to place orders for 10000 units of
WG-1111 then, instead of receiving in one shot 10000 units you could perform
the receive process 10 or 100 times (generating 10 or 100 inventory items with
a quantity on hand of 1000 or 100 units each); please consider that if you do
not receive anything, the first time you place an order the system will create
one inventory item and then will use it for all the orders, causing the db lock
contention issues.
As I mentioned previously, I'm using the PIZZA, a configurable good, which
creates a Production Run on order creation. If I create ten sales orders for
example, and run the production run associated to the order item in the 10th
(last) order, a pizza is created, and put into inventory. The oldest order
seems to be assigned to this inventory item.
This makes sense because when the production run is completed (via
productionRunProduce) and the inventory item is created,
"balanceInventoryItems" is called with the store's ReserveOrderEnumId set to
"FIFO Received". However, I see that 'priorityOrderId' and
'priorityOrderItemSeqId' is being passed to balanceInventoryItems also (and
have confirmed that the fields are populated), so I'm wondering why the
orderId/orderItemSeqId which is passed isn't receiving priority on the
inventory item being produced?
This sounds like an issue and we will have to check the code, there may be a
bug; did you try to disable/enable balanceInventoryItems?
Regards,
Jacopo
Hopefully you can shed some light on that for me
Thanks,
Darrell
--
View this message in context:
http://ofbiz.135035.n4.nabble.com/Locking-While-Placing-Orders-12-04-13-07-tp4656365p4656554.html
Sent from the OFBiz - User mailing list archive at Nabble.com.
