This should be a pretty straight forward question. We're running an old app in Merb 1.0.3. It uses the STOMP adapter gem to send messages to an AMQP server. We used to open a new STOMP connection, send the message and then close the STOMP connection on every message send. This proved problematic for RabbitMQ, which would occasionally just stomp accepting STOMP connections altogether. The fix was supposidly to reuse the STOMP connection, which is what we did.
We're now running in to a problem where the STOMP messages are interweaving, so instead of sending the line "SEND" to the socket, RABBIT receives a command like "SENDSEND," which looks to be two messages interwoven. The STOMP adapter wraps all of its transmit calls inside of a semaphore.synchronize block, so it shouldn't have this issue I think. I was wondering if the issue was with how Merb forks off workers when run in daemon mode? We're running a concurrency of 4 on production. We built a class to wrap our STOMP functionality: https://gist.github.com/9d9a2512b2a58cc09780 And call MyStomp.send on each message send. Note we do send 5 messages right in a row, which may or may not be the problem. We also call MyStomp.setup in init.rb in the after_app_loads block to init the connection. Now, as far as I can tell, all workers of a clustered merb app use the exact same model classes, so they all should be sharing the same instance of MyStomp and @@connection. I verified this by clustering locally and checking the object_id of the MyStomp objects before send - they all had the same ID. My question is, as Merb is running along and killing then restarting workers, is there every two instances of your model classes (in this case MyStomp), which would then not share the same MyStomp class and the semaphore? If not, is there anything else this might be? Thanks, -J--
You received this message because you are subscribed to the Google Groups "merb" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to [email protected].
For more options, visit this group at http://groups.google.com/group/merb?hl=en.
