On Wed, Feb 9, 2011 at 11:57 AM, Simon Nash <n...@apache.org> wrote: > ant elder wrote: >> >> On Wed, Feb 9, 2011 at 10:56 AM, Simon Nash <n...@apache.org> wrote: >>> >>> ant elder wrote: >>>> >>>> On Tue, Feb 8, 2011 at 2:12 PM, Simon Nash <n...@apache.org> wrote: >>>>> >>>>> ant elder wrote: >>>>>> >>>>>> On Tue, Feb 8, 2011 at 11:17 AM, Simon Nash <n...@apache.org> wrote: >>>>>>> >>>>>>> Mike Edwards wrote: >>>>>>>> >>>>>>>> On 08/02/2011 10:08, ant elder wrote: >>>>>>>>> >>>>>>>>> On Tue, Feb 8, 2011 at 9:56 AM, Simon >>>>>>>>> Laws<simonsl...@googlemail.com> >>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> I can see that relaxing the current spec restrictiveness would be >>>>>>>>>>> difficult as things would break in some circumstances, but it >>>>>>>>>>> does >>>>>>>>>>> seem like there will be situations when the assembler really >>>>>>>>>>> knows >>>>>>>>>>> it >>>>>>>>>>> would be fine but even so they can't get the PBR optimization >>>>>>>>>>> because >>>>>>>>>>> the impls aren't coded with the @AllowsPassByReference >>>>>>>>>>> annotation. >>>>>>>>>>> Isn't that a similar situation to where the remotable annotation >>>>>>>>>>> was >>>>>>>>>>> added to the interface SCDL element, and there could be a similar >>>>>>>>>>> allowsPassByReference attribute added to the service and >>>>>>>>>>> reference >>>>>>>>>>> SCDL elements? >>>>>>>>>>> >>>>>>>>>>> ...ant >>>>>>>>>>> >>>>>>>>>> Hi Ant. >>>>>>>>>> >>>>>>>>>> Can you say a bit more about the "situations when the assembler >>>>>>>>>> really >>>>>>>>>> knows it would be fine"? Reading previous posts to this thread >>>>>>>>>> doesn't >>>>>>>>>> convince me that that is the case. >>>>>>>>>> >>>>>>>>>> Simon >>>>>>>>>> >>>>>>>>> We'll have to wait for Raymond to see if thats anything like his >>>>>>>>> situation, but there are lots of ways the assembler could know, he >>>>>>>>> may >>>>>>>>> well have full access to the source but still be limited in making >>>>>>>>> any >>>>>>>>> updates due to production lifecycle or control issues. This seems >>>>>>>>> like >>>>>>>>> a similar situation as Java EE appservers have and I believe many >>>>>>>>> appservers have mechanisims for overriding and enabling PBR support >>>>>>>>> in >>>>>>>>> their ORB or EJB modules to gain performance benefits. >>>>>>>>> >>>>>>>>> ...ant >>>>>>>>> >>>>>>>> Folks, >>>>>>>> >>>>>>>> One possibility to start with would be to add a Tuscany extension >>>>>>>> attribute which could be used by an Assembler to mark a particular >>>>>>>> service >>>>>>>> and/or reference as "AllowsPassByReference". >>>>>>>> >>>>>>>> This would cope with the situation where the Java components are not >>>>>>>> marked, but the assembler knows enough about them to know that the >>>>>>>> marking >>>>>>>> is correct. >>>>>>>> >>>>>>>> >>>>>>>> Yours, Mike. >>>>>>>> >>>>>>>> >>>>>>> I'm very dubious about the wisdom of this. I bear the scars from a >>>>>>> previous life of a situation where a flag was added to an enterprise >>>>>>> application server (which shall remain nameless) to override the PBV >>>>>>> semantics required by the architecture in the interests of >>>>>>> performance >>>>>>> optimization when the user of the product "knew" that using PBR would >>>>>>> be safe. Needless to say, on a number of occasions this flag was set >>>>>>> incorrectly and this resulted in accusations of runtime bugs that >>>>>>> were >>>>>>> eventually shown after laborious debugging to have been caused by the >>>>>>> PBR "optimization" being enabled incorrectly. >>>>>>> >>>>>>> IMO it's the implementation's responsibility to make the correct >>>>>>> assertions about whether it's PBR-safe. Implementations that don't >>>>>>> assert @AllowsPassByReference will have worse performance than those >>>>>>> that do support it. If a component developer cares about >>>>>>> performance, >>>>>>> they need to code their implementation to play by the APBR rules and >>>>>>> turn on the flag to say they have done that. If the flag isn't >>>>>>> turned >>>>>>> on by the implementer, I can't imagine that an assembler will have a >>>>>>> detailed enough knowledge of the implementation to be able to safely >>>>>>> provide the APBR assertion that the component developer couldn't/ >>>>>>> wouldn't/didn't provide. >>>>>>> >>>>>>> (Deep breath) Now I feel better after getting that off my chest :-) >>>>>>> >>>>>>> Simon >>>>>>> >>>>>>> >>>>>> As an attempt to justify this: we don't have any samples that use >>>>>> @AllowsPassByReference, and I don't recall ever seeing many in Tuscany >>>>>> or elsewhere that do, but i think all those samples i've seen probably >>>>>> would have worked fine with it as they don't modify anything >>>>>> afterwards. I think it would be relatively uncommon to code something >>>>>> that would be unsuitable for using @AllowsPassByReference. So Joe >>>>>> developer writing his code probably wont use @AllowsPassByReference >>>>>> either, may not even know it exists, and any performance issues likely >>>>>> wont get found until much later when running in a production system by >>>>>> which time it can be very hard and time consuming to get the code >>>>>> modified, re-test, QA'd and redeploying into the live system. >>>>>> >>>>> OK, that's a good point and we should fix the Tuscany samples so that >>>>> people reading them get the message about using APBR. >>>>> >>>> One further comment from me too :) >>>> >>>> Well the thing with that is that _if_ we should be worried that having >>>> a PBR override facility is dangerous because people will see it as a >>>> "go faster" flag and turn it on when they shouldn't then the same >>>> could just as easily will happen with the annotation - someone will >>>> copy the sample for their code, that will get copied around all the >>>> impls they and their colleagues write and people may or may not notice >>>> or understand why the annotation is there or just think its a Good >>>> Thing as it improves performance. One day one of their impls wont be >>>> suitable for using PBR and it will intermittently go wrong and be even >>>> harder to track down as you'll have to actually understand what all >>>> the impl code does. >>>> >>> Well, that could certainly happen, just like any other kind of >>> implementation bug. As it's in the implementation it'll show up >>> wherever the implementation is used and therefore is likely to >>> be found fairly quickly, hopefully after the developer has had the >>> late-night hair-tearing experience to teach him/her to never be so >>> careless/casual again. >>> >>>> I wonder if it would have been simpler if the spec just prohibited the >>>> modification of arguments, or instead of @AllowsPassByReference had a >>>> @RequiresPassByValue for those unusual cases where you know you want >>>> the runtime to ensure copies have be made before returning from the >>>> call. >>>> >>>> ...ant >>>> >>>> >>> Having @RequiresPassByValue would fall even more into the trap of >>> developers forgetting to use it when needed, resulting in buggy >>> implementations. The current approach favours safety over performance. >>> >>> Prohibiting the modification of arguments feels wrong to me. This >>> is perfectly safe in the remote case (with no performance overhead), >>> so it seems like an unreasonable blanket restriction to impose on >>> all services. >>> >>> On interesting idea (taking up the theme of @RequiresPassByValue) would >>> to require @AllowsPassByReference to always be present (specifying "true" >>> or "false") on every service method and every reference. That would >>> force developers to think about the issue and explicitly state their >>> intentions. It would make "Hello World" rather ugly, though :-( >>> >>> Simon >>> >>> >> >> I don't buy that "even more" argument. Earlier it was being said that >> Assemblers shouldn't be able to override PBR as only the developer >> really knows how to do it and now you're saying even the developer >> can't be trusted to do it right. If thats the case why expect them to >> even be using @AllowsPassByReference correctly. And as the bugs are >> intermittent they likely often wont show up in testing only in a busy >> production system with lots of thread switching going on. >> > Actually, I thought it was you who was saying (previously) that the > developer couldn't be trusted to do it right. Developers are far more > likely to get this right than assemblers. Also, having this in the > implementation means it's subject to much more testing in different > situations, further improving the chances of getting it right. But > developers aren't infallible so there are bound to be occasional bugs. > If the developer has to find their bug and fix it, they'll learn > from the experience and won't repeat the mistake again. > > The best chance of getting this to work as intended is to put the > responsibility on developers and educate them as much as possible > to understand the issues. The correct setting of the switch is > an implementation issue, not an assembly issue. Making it a shared > responsibility between the assembly and the implementation would > muddy the waters over who is responsible when problems occur. > >> Its sounding like what could be useful would be a global switch on the >> runtime that can disable any PBR optimizations no mater what >> annotations have been coded so that we can protect the runtime frm all >> the flaky devs. >> >> ...ant >> >> > So this would be a magic fix-my-APBR-bugs switch instead of a > magic go-faster switch :-) Using this switch would slow things > down and change timing windows etc., so even if this made a bug > go away, it wouldn't prove that the bug was caused by incorrect > usage of ABPR. > > Simon > >
I remain unconvinced, so respectfully, i still think if someone does want to implement this type of thing it would be ok and useful. ...ant
