- **status**: review --> fixed
---
** [tickets:#757] IMM: Class-create needs a guard/lock while it is being
processed by PBE**
**Status:** fixed
**Milestone:** 4.3.3
**Created:** Wed Jan 29, 2014 11:04 AM UTC by Anders Bjornerstedt
**Last Updated:** Fri Feb 21, 2014 03:36 PM UTC
**Owner:** Anders Bjornerstedt
This issue was discovered while analyzing the logs&trace provided
for ticket #737.
A test program creates a test-class, instances of that class and performs
operations on the instances.
Relevant for this ticket is the observation of this sequence.
1) A class create request is made. The request is well formed and is
sent to the PBE to be persistified. The request can not be replied on
until the PBE has replied if it succeeded or not in persistifying the class.
2) A second requests to create the same class arrives, possibly due to
the first request receiving ERR_TIMEOUT (PBE could be backlogged).
That request immediately receives ERR_EXIST.
3) The test program receiving ERR_EXIST, takes this as confirmed availability
of the class and proceeds to request a create of an object of that class.
4) The imm accepts the object create request (this is the defect reported here).
Accepts apply and ccb goes critical in being queueud up to the PBE.
5) The PBE replies OK on the class create.
6) The PBE replies OK on the apply of the ccb with object create.
If the PBE had failed in the class-create (for whatever reason) then
the subsequent apply would also be guaranteed to have failed in the PBE.
But probably not gracefully. I am pretty sure the PBE would crash on
assert, restart. On probe on outcome of the object create ccb it would
reply with abort/FAILED_OPERATION.
This is obviously a low probability issue since the issue has been there
as long as PBE has been there and no one has reported a problem related to this.
Real classes are rarely created, typically only as part of an upgrade.
Instances are typically created separately.
Even though the probability of occurence is low and the effects are not
catastrophic, this should be prevented by some form of "create lock" on the
class while it is being processed by the PBE.
This problem is old so it should not block 4.4.RC1
---
Sent from sourceforge.net because [email protected] is
subscribed to https://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
