i have a situation where i have to send 100 messages a day to 3000 different
devices.
these devices are not always on (or in a state to receive messages) for
which a lot of messages would stay on queues for a long time.
i would need suggestions on the following:
1) is it efficient to have 3000 qu
Hi all,
I'm not sure if batch or stream processors e.g. aggregator or resequencer
are persistent and reliable in case of system crash. Anyone can help?
There has been a message posted already but with no answer:
http://www.nabble.com/Better-Aggregator-support-td12564277s22882.html#a12564277
Reg
Thanks for the quick reply. Looks like that was the secret sauce :-)
ttmdev wrote:
>
> Try taking the 'failover' out of broker A's static connector. Like so,
>
> ... />
>
> With the above static connector, if broker B fails, Broker A should go
> into connect retry mode.
>
>
--
View this
Done, thanks for the reply.
https://issues.apache.org/activemq/browse/AMQ-1661
--
View this message in context:
http://www.nabble.com/%22Duplex%22-problems-tp16601619s2354p16617626.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Doh! Never mind my previous question ;)
Joe
ttmdev wrote:
>
> Try taking the 'failover' out of broker A's static connector. Like so,
>
> ... />
>
> With the above static connector, if broker B fails, Broker A should go
> into connect retry mode.
>
> What version of AMQ are you using?
>
>
Try taking the 'failover' out of broker A's static connector. Like so,
With the above static connector, if broker B fails, Broker A should go into
connect retry mode.
What version of AMQ are you using?
Joe
Goto www.ttmsolutions.com for a free ActiveMQ user guide
rmahoney249 wrote:
>
>
Thx!
On 10 Apr 2008, at 20:33, Rob Bugh wrote:
Done. See AMQ-1660
rajdavies wrote:
That sounds like a nice enhancement ! - could you raise a jira ?
cheers,
Rob
http://open.iona.com/ -Enterprise Open Integration
http://rajdavies.blogspot.com/
--
View this message in context:
http://
On 10 Apr 2008, at 20:14, rmahoney249 wrote:
I'm having a problem with a Network of Brokers in a store and
forward setup.
If I take down the activemq instance on the producer side and then
restart,
it never recreates the DemandForwardingBridge. Here are the details:
Server A (linux, java
Done. See AMQ-1660
rajdavies wrote:
>
>
> That sounds like a nice enhancement ! - could you raise a jira ?
>
> cheers,
>
> Rob
>
> http://open.iona.com/ -Enterprise Open Integration
> http://rajdavies.blogspot.com/
>
>
--
View this message in context:
http://www.nabble.com/Scheduled-Fa
I'm having a problem with a Network of Brokers in a store and forward setup.
If I take down the activemq instance on the producer side and then restart,
it never recreates the DemandForwardingBridge. Here are the details:
Server A (linux, java 1.5):
- STOMP Producers putting messages on queue F
On 10 Apr 2008, at 16:55, Rob Bugh wrote:
I am using a JDBC Master/Slave topology. I'm using Postgres as the
db and
noticed that due to the long running transaction of the master
holding the
lock on the activemq_lock table my vacuums are not very effective.
If you
are familiar with posgr
Was just looking into this - so thanks for the update!
On 10 Apr 2008, at 16:00, j0llyr0g3r wrote:
Update again:
i have to correct myself: This is NOT an AMQ / Java problem, but a
problem
with SLES9. (All of my testservers run on sles9, that's why i
thought it
would be an AMQ / Java pro
I am using a JDBC Master/Slave topology. I'm using Postgres as the db and
noticed that due to the long running transaction of the master holding the
lock on the activemq_lock table my vacuums are not very effective. If you
are familiar with posgres then you know that vacuum can only recover dead
t
Update again:
i have to correct myself: This is NOT an AMQ / Java problem, but a problem
with SLES9. (All of my testservers run on sles9, that's why i thought it
would be an AMQ / Java problem)
I can reproduce above described behaviour:
Producer on Ubuntu / Java 1.6 -> Broker on Sles 9 / Java
Joe,
You had mentioned that this problem afflicted 5.0.0. I am now experiencing
this
problem with 4.1.1 as well. Could i perhaps be experiencing a different
issue here?
Regards
/Ur
ttmdev wrote:
>
> Try disabling or increasing the inactivity timeout on the brokers'
> corresponding transport
The "duplex" feature has had its issues :( I think you'll find that if you
set networkTTL to 1, the topic consumer(s) on broker A will not get
duplicate messages. However, even with networkTTL set to greater than 1,
broker B should not be sending messages back to where they came from.
Re your f
Hey ho,
i finally solved the problem and i consider this an activemq bug:
The reason for the error:
-> Broker was running on Java 1.5
-> Producer was running on Java 1.6
Solution:
Don't use Java 1.5 and Java 1.6 together.
This is a freakin' catastrophy, because nothing, really nothing in the
Hey folks,
i really hope someone can help me out, since i am running out of ideas
My problem seems quite simple:
-> I have a self-written message producer using AMQ-libraries
-> I have a self-written message consumer using AMQ-libraries
-> And a (single) AMQ-Broker in the middle
-> All used
Hi,
Recently I've had a lot of problems with my app. The most noteable
with v4.1.1 are below.
-- Messages being left on queue when consumers are there.
-- Obtaining lock exceptions with derby.
I am wondering is six consumers to a broker too much for the broker or
for derby? How do I arrive at
Hi,
I'm getting the following exception.
2008-04-10 02:59:23,282 WARN org.apache.activemq.ActiveMQCo
ception: A lock could not be obtained within the time requested
java.lang.RuntimeException: java.io.IOException: Failed to broker
message: ID:gboff01-gs-dev-bpro1-47686-120777491
20 matches
Mail list logo
