activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From michaelandrepearce <...@git.apache.org>
Subject [GitHub] activemq-artemis issue #1695: ARTEMIS-1545 Ensure JMS security exceptions oc...
Date Fri, 08 Dec 2017 11:13:44 GMT
Github user michaelandrepearce commented on the issue:

    https://github.com/apache/activemq-artemis/pull/1695
  
    @andytaylor the issue i see is that the defaults should err on the side of safety imo.

    
    Having a client not throw any exception and continue blindly is dangerous (even if its
miss-config). Just because something is like it is, doesn't always been it should be.
    
    I get the performance thing, but then thats something someone should make a conscious
decision to enable at the expense of exceptions.
    
    Just a bit of background, we migrated a flow (it was using JMS api, so switch is just
in the CF) from another vendor's broker to Artemis, and released to prod.
    
    The broker did alert, but the operations team operating the broker saw it as a client
issue. and as was a client issue they believed the client team would also get an error, have
been alerted and would have resolved. 
    Because the client team had no error, it was not until quite a period later it was discovered
and external reports had to alert us to the issue.
    
    We re-tested the scenario with our other brokers, and they would have alerted client side
so this is why this assumption is had.
    
    If we look to other people migrating I'm fairly sure the other brokers we use, are quite
well used, and as such other users would make similar assumptions and expectation that the
client would still error by default, unless they toggled something for performance on purpose.
    



---

Mime
View raw message