well... correction, and just for completion... the default url is actually
failover:(tcp://localhost:61616)
On Mon, Jan 27, 2014 at 10:42 AM, Christian Posta
wrote:
> That's correct. The default url in the ActiveMQConnectionFactory is
> tcp://localhost:61616
>
> https://github.com/apache/activ
That's correct. The default url in the ActiveMQConnectionFactory is
tcp://localhost:61616
https://github.com/apache/activemq/blob/trunk/activemq-client/src/main/java/org/apache/activemq/ActiveMQConnectionFactory.java#L91
On Mon, Jan 27, 2014 at 10:08 AM, Chris Geer wrote:
> I think you are corre
I think you are correct that there is something rogue out there not using
the connection pool and making it's own connection. It occurred to me that
if you use the Camel ActiveMQ component that by default it connects to
localhost over Openwire. So it probably means that someone screwed up their
cam
You probably had something on your local machine open a connection to
the broker on 61616. The logging indicates that the client used port
47400. Guess you have to figure out what rouge client is making
connections if you expect everything to happen over the VM transport.
Maybe shut off the openwir
Clients and broker are all running in the same karaf instance...in fact all
my "clients" are connecting using this connection setting:
Netstat came back with nothing.
On Tue, Jan 21, 2014 at 4:01 PM, Rodrigo Ramos wrote:
> Hello Chris,
>
> You can use netstat for identify w
Hello Chris,
You can use netstat for identify what process is listening in 47400 port,
as root type:
# netstat -punlt | grep 47400
I hope will be helpfully
Regards
2014/1/21 artnaseef
> Can you use a network packet sniffer, like tcpdump or wireshark?
>
> Those errors mean the other end of
Can you use a network packet sniffer, like tcpdump or wireshark?
Those errors mean the other end of the TCP/IP connection was dropped without
a higher-level cleanup of the connection. Could be the broker dropping and
coming back, network issues (timeouts, disconnects), or aborted connection
in th
The problem is actually with the non-blocking socket implementation in my
PHP/Stomp client. I'll have to investigate little bit more on this in order
to implement it better.
Do you have some experience with non-blocking sockets and Stomp with
ActiveMQ?
Thanks
Cheers,
Ivan
Ivan Jovanovic wrote
HI,
I succeeded to put big messages on my broker with your PHP/Stomp client and
your test code.
I'll look inside my Stomp client a bit deeper to see what happens.
Thanks for bringing back hope on the stage ;)
Cheers,
Ivan
Dejan Bosanac wrote:
>
> Hi,
>
> I've tried and cannot reproduce thi
Hi,
I've tried and cannot reproduce this issue.
here's first a test case trying to send/receive a large message (as Ivan
described in one of previous emails)
public void testSendLargeMessage() throws Exception {
MessageConsumer consumer = session.createConsumer(queue);
Strin
Ivan Jovanovic wrote:
>
> I'm experiencing the same problem with the large messages in PHP/Stomp.
>
> Did you solve this one, since your problem dates from couple of months
> ago?
>
Hi,
We were not able to find a solution other than not to send such large
messages. We haven't tried 5.1 so I
I'm experiencing the same problem with the large messages in PHP/Stomp.
Did you solve this one, since your problem dates from couple of months ago?
Thanks in advance for the answer.
Cheers,
Ivan
gwittel wrote:
>
> Hi
>
> We're using a Perl/Stomp client to retrieve messages out of a standar
12 matches
Mail list logo
