Client sends succeed without permissions, but fail on Server

[drkirwin]

Folks--

I've experienced a strange problem in trying to get my mind wrapped around the users, roles and permission settings in the 2.0.0 GA release.

Say I have a user "guest3" with a password "guest3" defined in hornet-users.xml, and give that user a role of "foo".

In hornet-configuration.xml, I have:

     <security-enabled>true</security-enabled>

but I do NOT add the "foo" role to any of the <permission/> elements in the <security-settings/> block.

Now I construct a session for guest3, then construct a producer, then send a message.

The message "seems" to send just fine. I get no exception when I call producer.send(msg).

However, on the server side (HQ logs), I see this:

HornetQException[errorCode=105 message=Unable to validate user: guest3 for check type SEND for address test.address]

at org.hornetq.core.security.impl.SecurityStoreImpl.check(SecurityStoreImpl.java:187)

at org.hornetq.core.server.impl.ServerSessionImpl.send(ServerSessionImpl.java:1976)

at org.hornetq.core.server.impl.ServerSessionImpl.handleSend(ServerSessionImpl.java:1426)

at org.hornetq.core.server.impl.ServerSessionPacketHandler.handlePacket(ServerSessionPacketHandler.java:275)

at org.hornetq.core.remoting.impl.ChannelImpl.handlePacket(ChannelImpl.java:466)

at org.hornetq.core.remoting.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:423)

at org.hornetq.core.remoting.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:389)

at org.hornetq.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:432)

at org.hornetq.integration.transports.netty.HornetQChannelHandler.messageReceived(HornetQChannelHandler.java:67)

at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:98)

at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:560)

at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:796)

at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:358)

at org.hornetq.integration.transports.netty.HornetQFrameDecoder2.decode(HornetQFrameDecoder2.java:171)

at org.hornetq.integration.transports.netty.HornetQFrameDecoder2.messageReceived(HornetQFrameDecoder2.java:136)

at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:80)

at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:560)

at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:555)

at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:345)

at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:332)

at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:323)

at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:275)

at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:196)

at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)

at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:46)

at org.jboss.netty.util.VirtualExecutorService$ChildExecutorRunnable.run(VirtualExecutorService.java:179)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

at java.lang.Thread.run(Thread.java:637)

What I expect to see is no output on the server side, but an exception thrown by the client side.

If it helps any, a "consumer" seems to work just fine, but the error there is about "CREATE_NON_DURABLE_QUEUE", rather than "SEND" or "CONSUME".

So, is this a bug? Or have I misunderstood something?

Keith

[timfox]

This is because, by default, non persistent messages are sent non blocking (i.e. we don't do a network round trip on each message) - otherwise it would be extremely slow.

Since we're not blocking there's no way to get back an error message synchronously from the server on a send.

If you want to send non persistent messages blocking, you can configure it to do this. See user manual chapter on "send guarantees..."

[drkirwin]

Hm.

Section 20.2. Guarantees of Non Transactional Message Sends

...

BlockOnNonDurableSend. If this is set to true then all calls to send for non-durable messages on non transacted sessions will block until the message has reached the server, and a response has been sent back. The default value is false.

...

I think that's exactly what I need! Thanks.

Keith

[timfox]

Bear in mind, that if you set to block, your perf will drop. Since you'll be doing a network round trip on each send.

Therefore your perf will be determined by the latency of your network, not the bandwidth. This can make a *very* signifcant difference in perf.

IIRC there is an illustrative calculation in the docs explaining this.

HornetQ has a unique feature not found elsewherre which allows you to still send asynchronously but get back "send acknowledgements" async in a different handler. This gives you the reliability guarantees of blocking with the performance of async sending.

[drkirwin]

For this stage in our little project, we're just sending monitoring messages every 5 seconds or so. I don't think we'd detect a performance hit. Nevertheless, I think this would be a perfect test case for the asynchronous stuff.

When we ramp up to our main task with messages, I think the async stuff will be VERY useful, mainly because we'll be storing messages in a data store before sending them. We could send as fast as we can, then delete those that have been sent in an event driven manner. (I may not be describing it all that well.)

My worry is about what happens if the producer goes down before the acknowledgements have come in, but I think our system is pretty robust about sending duplicate messages, so....

Anyway, cool. I'm excited to see it work and experiment.

Keith