Possibly you could just create consumers where effectively (not real code):
sendTime < now() - 10min
and just create a new consumer, receive until there's nothing left, then try
again a minute later.
you'd be able to yank from one queue and re-publish to another. I'd bet you
could do this with c
We attempted this as well, but it seemed the JCA adapter for AMQ was
implemented to throw on all the new JCA 1.5 calls. So the MDB deployer
would immediately fail when it tried to setup the listeners. Looking at the
jca source from AMQ (was a pre 5.0 snapshot from a month or two ago) the
methods
I have a mechanism I've written that uses dynamic proxies to intercept hits
to JMX mbeans that checks to see if a local instance is up and initialized,
if not, it will send a JMS message to a centralized broker to see if another
server has the service available to service the request.
Basically i
Hi folks,
I was trying to integrate AMQ 4.2 (snapshot) with JBoss 4 + EJB3 (for MDBs)
it appears that the activemq-ra library (from looking at the source) doesn't
actually support the new functions that came along with JCA 1.5
There are many functions stubbed out to throw JMSException("Not supp
For what it's worth (James' solutions are probably better)... if you need
'random' access to queues from jboss (or any JNDI enforced thing), you can
create your own JNDI context (javax.naming.Context) and bind that to some
spot in the jboss jndi tree, then all you do is override Context.lookup(nam
Hi folks,
this is along the lines of what Franz was asking in "Master/Slave
Configuration With Non-Persistence - 2 Brokers Starting Problem", but I
didn't want to hijack his thread in case it wasn't related.
what I'm looking for is:
* Pure master/slave share nothing
* transparent failover in the
temp queues are discarded when the creating session closes (goes away,
crashes etc)
also, if you want message to not be received when a client isn't there, you
could always use topics
On 5/17/07, Gustavo Lanna <[EMAIL PROTECTED]> wrote:
Right, but if client doesn't connect and others service
would just block
persistence writes while state sync occurs. Would require the master to
know about the slave though so it can sync back (or be master/slave in the
longest-up-is-master way)
Thanks,
-David
On 5/4/07, David Budworth <[EMAIL PROTECTED]> wrote:
true, but I was shooting for z
se a shared DB or file system you should be able to failover
and fail back without a problem.
On 5/4/07, David Budworth <[EMAIL PROTECTED]> wrote:
> I mistakenly hijacked another thread yesterday when asking this, so I'll
> repost it as it's own thread.
>
> If I unders
I mistakenly hijacked another thread yesterday when asking this, so I'll
repost it as it's own thread.
If I understand the wiki and comments I've read on this list recently, AMQ
has no state synchronizer.
Meaning that if I have Master / Slave and the Master dies, i can't restart
it without stopp
I have a question along these lines, you said here that there's no mechanism
to do real time broker-broker synchronization.
Does that imply that when starting up a master slave system, you must start
both the master and the slave before any clients start sending messages? Or
if the master is up
the connection that is doing tmp.receive(timeout) was started? ( ie:
connection.start() )
If a connection is not started it can send but not receive a message.
may not be it, but that gets me reasonably often when ever I change
connection creation schemes
On 4/24/07, James Strachan <[EMAIL PRO
12 matches
Mail list logo
