I have a strange issue with AMQ FUSE - since we started using activemq-fuse-5.0.0.11.jar in our project, we have found that our logging styled changed, and it has been identified that the fuse jar contains a modified class org.apache.commons.logging.LogFactory with a different implementation of logging, which has overridden ours

Is that an issue anyone has heard of? Maybe it is just our misconfig or bad code that has allowed the fuse JAR to override our logger, I am not sure

TomJ: hey

so we use common logging

and include it in our uber jar the -all.jar

basically it has all the dependencies amq needs to run a client and a simple broker

but if you want to use different version of the dependencies you can use the more fine grained jars

the main one being the -core .jar

of course, sorry

but then you need to also add in the jms spec jar

and some others..

depending on what you are doing

perfect, thanks very much

Is there someone here who could entertain a question about jms bridge failover scenarios?

I thought i remember seeing somewhere the broker can cache requests and if the same requests is sent twice, then the cached response is sent. Is this a possibility with the amq broker? Looking in docs, I really do not see reference to anything like this

pbarry: there is some value caching that happens but it's all for the low level protocol bits.

not the message contents

stuff like connection/session/producer/consumer ids are the things cacheds

ah I see. So if a message was sent to broker and it matched a messageID already sent, there is no, "auto-reply" sent back from broker with old response

Is there someone here who could entertain a question about jms bridge failover scenarios?

Steve: shoot someone might be able to help

hopefully it's not too complicated.

chirino_m: when you get a moment can you have a peek at https://issues.apache.org/activemq/browse/AMQ-1724

gtully: ok

we're deploying an embedded broker that will store & forward log messages to a stand-alone activemq instance for later processing

we want to get the logging activity out of process as quickly as possible and want to survive a failure of the main activemq instance

I'm using a JmsQueueConnector to bridge to the main instance

if I use a url like tcp://localhost:123 and there's no stand-alone instance active, the broker starts up fine

However, when I attempt failover://tcp://localhost:123, instantiation of the broker blocks on reconnect attempts

We have a requirement that the bridge can start up w/o the main instance being active

any ideas/

?

In general, our goal is that the broker will either accept the message or fail immediately -- it should never block

I filed JIRA 1717 about StoreUsage blocking

i added OpenEJB to the Related Projects list on the Navigation page... hope no one minds :)