Michael, Great initiative bringing this up and offering to fix it.
We dont use those Genius classes in SFC, so we're "safe" for now :) I would love to help, but wont be able to until after Carbon MS5. Thanks, Brady -----Original Message----- From: Michael Vorburger <[email protected]<mailto:michael%20vorburger%20%[email protected]%3e>> To: [email protected]<mailto:[email protected]>, odl netvirt dev <[email protected]<mailto:odl%20netvirt%20dev%20%[email protected]%3e>>, [email protected]<mailto:[email protected]>, Brady Allen Johnson <[email protected]<mailto:brady%20allen%20johnson%20%[email protected]%3e>> Subject: Re: FlowEntity immutability Date: Fri, 24 Mar 2017 03:22:30 +0100 +netvirt +sfc On Thu, Mar 16, 2017 at 12:27 PM, Michael Vorburger <[email protected]<mailto:[email protected]>> wrote: Hey guys, I can't remember if I have raised this before or not, but ... the org.opendaylight.genius.mdsalutil.FlowEntity API as-is is outright dangerous IMHO, because it's not thread safe, because it's not immutable... currently any code, theoretically, could create FlowEntity instances, and then e.g. use IMdsalApiManager's installFlow() and THEN after make changes to the SAME FlowEntity just after. Or, even more fun and really hard to track, if it ever came to it, some background thread could concurrently change a FlowEntity WHILE something else is using it... .. I'm not saying that we do have such a problem anywhere today, just that the FlowEntity & Co. classes are... not optimal. Should we make an effort to create a FlowEntityBuilder (& Co.) and let FlowEntity (& Co.) only have getters? how about https://git.opendaylight.org/gerrit/#/c/53763/ ? as briefly discussed during today's Genius call, this change would require adapting downstream netvirt & genius to switch new FlowEntity(1) ... to new FlowEntityBuilder().dpnId(1) etc. of course - but that's certainly doable - any volunteers to help doing this? Tx, M. -- Michael Vorburger <[email protected]<mailto:[email protected]>> | IRC: vorburger @freenode | ~ = http://vorburger.ch<http://vorburger.ch/>
_______________________________________________ sfc-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/sfc-dev
