is the stomp protocol production ready at this point?

dstanek: sure

we are seeing issues where the server accepts the message but it never gets into the queue - at the same time the server has a large amount of close_waits and runs out of file descriptors

have you heard of anything like that?

dstanek: did u see https://issues.apache.org/.../AMQ-1739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43773#action_43773

gtully: thanks looking now

unfortunately there doesn't seem to be a way to get an ack back from the server if a message was received

is there a maximum number of consumers on a single queue on a single broker?

westmaas: that's mainly based on your hardware

and performance requriements

alright

is 2000 consumers "a lot" or should that not be a problem

each using a separate connection or sharing connections?

cause connections is the main thing that tend to load up a broker.

separate connection (attempting to simulation 2000 distinct machines connecting to the one server)

gotcha

yeah w/ default settings 2000 tends to be alot

same as saying can your DB handle 2000 connections

you can optimize for it tho.

but you could just use multiple brokers.

to split the load and stuff.

also youmight want to try out the NIO transport as that should increase your load capacity

great chirino, thanks a lot!

chirino_m: do you know if there is a performance penalty for using stomp? it seems we can have more clients connected to openwire than stomp and we aren't sure why

openwire is binary optimized protocol.

it has less overhead to parse.

are there any disadvantages to the NIO transport?