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
