Just for posterity, this was me being a bonehead - I didn't have a JMS
connection pool in my camel config - once I added one things got MUCH
happier.
Larry
On Mon, May 12, 2014 at 11:07 AM, Larry Meadors wrote:
> Thanks for your time, Christian!
>
> Firewall/networking between them: None. :-\
>
Thanks for your time, Christian!
Firewall/networking between them: None. :-\
They are running on the same (virtual) machine - it's an EC2 host
running ubuntu.
I am running 3 instances of AMQ on it (it's a dev/test/qa type of
environment) - the AMQ endpoints are configured as localhost:61617,
loc
What networking/firewalls do you have between your clients and broker?
On Sun, May 11, 2014 at 7:30 AM, Larry Meadors wrote:
> No hints?
>
> This is killing me - I'm restarting AMQ several times a week now. :-/
>
> On Wed, May 7, 2014 at 11:18 AM, Larry Meadors
> wrote:
>> I'm running AMQ 5.7.0
No hints?
This is killing me - I'm restarting AMQ several times a week now. :-/
On Wed, May 7, 2014 at 11:18 AM, Larry Meadors wrote:
> I'm running AMQ 5.7.0 with a camel application (using camel 2.10.7, in
> case that's relevant) and recently, the app has started logging these
> messages:
>
> W
Good point. We will try the failover.
Thanks
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Wire-format-negotiation-timeout-auto-retry-tp4677624p4677630.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
On 02/07/2014 10:49 AM, Jerry Cwiklik wrote:
Under a heavy network load we occasionally are getting the dreaded "Wire
format negotiation timeout..." exception when opening broker's connection in
the client. We attempted to solve the problem with
wireFormat.maxInactivityDurationInitalDelay=6
I'm using 5.8.0
Mark
On 5/13/2013 8:29 PM, ceposta [via
ActiveMQ] wrote:
No, it's probably the same cost. But the cost is in
establishing the
underlying connection, not in creating the session. It just
happens that if
No, it's probably the same cost. But the cost is in establishing the
underlying connection, not in creating the session. It just happens that if
you haven't started the connection by the time you try to create the
session, creating the session will set up the underlying connection data
structures b
Well, what happens when you "create a connection" but
don't start it, it
will open the transport and start wire format negotiation... when
you do
connection.start().. or when you try to open a session, it will
ensure that
Nice investigation!
>
> In a well-tuned system/network, I would think that sending a
> 40-character text string to ActiveMQ would be nearly instantaneous
> from a human's perspective, right?
>
> Yes, it should be super fast.
> What I learned from this is that I can reduce the o
OK, here's some useful info... I used:
tcpdump tcp port 61616 and host dell7
I noticed that if I use:
?wireFormat.maxInactivityDurationInitialDelay=3
in my client to extend the timeout to 30 seconds instead of the
default 10 seconds, then my
Thanks! I'm studying up on tcpdump's man page now (about 30 pages
of technical details!). Wireshark isn't installed by default, so I
put in a request to have it installed on Tuesday. I won't be back
in until Thursday, so I'll resume my diagnostics then.
T
You can use wireshark (or tcpdump) on the broker machine to see if the
client's WireFormatInfo is coming through and whether the broker is sending
one. Wireshark does have a built in activemq command codec so you can see
the command objects going through. You can also try things like ping or
tracer
I'm also suspecting it is a network issue, as I surmise you are by
the questions you ask. But my strength is programming, not
sysadmin. So I want to answer your questions, but don't know the
RedHat tricks or tools to determine the answers. Can you hold my
hand
Mark,
When the connection to the broker is first established, the wire format is
negotiated by each side sending it's preferred info. Looks like the client
is sending its info, but not getting anything back. Maybe take a thread
dump to see what's going on on the broker side... can you verify the cl
http://activemq.apache.org/javaxjmsjmsexception-wire-format-negociation-timeout-peer-did-not-send-his-wire-format.html
is relevant.
If it's only once a month, then you could just use the failover transport
for automatic reconnection.
-
Michael Hayes B.Sc. (NUI), M.Sc. (DCU), SCSA SCNA
--
V
should be ?wireFormat.maxInactivityDurationInitialDelay
On 7 October 2011 19:20, shoevarek wrote:
> My application is using ActiveMQ to publish some events and send some error
> messages to a queue for asynchronous processing. From time to time I am
> getting Wire format negotiation timeout excep
Great! Glad it worked. Thanks for letting me know.
--
This is the Droid you're looking for.
On Sep 19, 2011 3:59 PM, "zcduthie" wrote:
> I've left it running for a week and everything seems to be working fine.
> What a silly mistake!
>
> Thanks very much!
>
> --
> View this messag
I've left it running for a week and everything seems to be working fine.
What a silly mistake!
Thanks very much!
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Wire-format-negotiation-timeout-peer-did-not-send-his-wire-format-tp3790325p3825459.html
Sent from the ActiveMQ
Try removing the ?wireFormat.maxInactivityDuration=0 parameter from your
connection URI.
On Sun, Sep 4, 2011 at 8:53 PM, zcduthie wrote:
> I've been searching for a solution to this problem for a while, however I
> could not find something that actually worked anywhere on these forums.
>
> Basi
Do you have failover and reconnect logic? It might not be a problem for you
if you have this logic. Your client will keep trying to connect and once
connected, will send the message. new connections are not super reliable
(in my opinion). if the listening socket is busy i have seen new
connect
Thanks for the response, Steve!
Our broker is not public and the clients are all internal applications and
not internet users.
we intermittently altho frequently see this error when the client is trying
to publish a message. Our clients are both publishers and subscribers. For
every publish, th
I do not know why they classify as an "ERROR". This is good for information
purposes; it is not an error.
Go ahead and telnet to your broker using your brokers port. Then do
nothing. You will generate this error after the timeout. This error is
caused by many different possibilities:
Your cl
Sorry to bug about this but can someone please respond...we are using
ActiveMQ 5.1.0 and are seeing this error in our production environement
quite frequently. This is a critical issue for us right now
I wanted to understand if this is a bug on the ActiveMQ side
(https://issues.apache.org/activem
Hi
can someone answer my email below?
Basically
What could be some possible causes of the wireformat negotiation not being
established?
Also, Is there a way to set the default timeout parameter from the
Connection URI i.e one of the wireformat.* options?
Currently we are seeing a lot of ne
Thanks Joe!
No. we only see this if I send higher than certain number of requests (after
about 1000 - 2000 concurrent requests)
Couple of questions...
What could be some possible causes of the negitiation not being established?
Also, Is there a way to set this timeout parameter from the Connec
The TransportConnector is used by the broker to listen for and accept
connection requests from clients and other brokers. When a connection is
initially established, the connection endpoints go through a wireformat
negotiation phase. This is explained on this page.
http://activemq.apache.org/o
27 matches
Mail list logo
