There aren't currently any plans to implement udp. However,
contributions are always welcome :)
Nate
On Sep 25, 2008, at 6:05 PM, gui pei wrote:
Hi, all
Does anyone know when will cms support udp, and is there a report
about tcp
and upd's performance difference.
Thanks.
--
It's
Hi Chris,
Unfortunately, the SSL implementation is incomplete. The full
implementation is currently aimed at the 2.3 release: http://issues.apache.org/activemq/browse/AMQCPP-140
Regards,
Nate
On Sep 25, 2008, at 5:56 PM, Chris Foote wrote:
I noticed that CMS (current svn trunk) contains
Definitely sounds like a bug - would you mind capturing this in a JIRA
issue? If you have a code snippet, you can attach that as well, and
we'll take a look.
Thanks,
Nate
On Aug 17, 2008, at 1:23 AM, BRoach wrote:
There seems to be a rather nasty bug having to do with transactions
in
Unfortunately, ActiveMQ-CPP does not currently support the failover
transport, so it's up to the client to reconnect.
Regards,
Nate
On Aug 10, 2008, at 1:24 PM, Patrick Ruckstuhl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Is there a way to automatically reconnect in with cms?
FYI, You don't have to use the asynchronous consumers. You can always
poll for new messages with a call to receive(). That way the
threading shouldn't be an issue for you.
Nate
On Jul 10, 2008, at 3:10 AM, Joselu wrote:
Thanks, Nate
Yes, we're using a C++ compiler. Openwire C client
ActiveMQ-CPP doesn't support ObjectMessages. If you're stuck sending
ObjectMessages from Java, probably your best bet would be to use a
Camel message translator in the broker (http://activemq.apache.org/camel/message-translator.html
).
Regards,
Nate
On Jul 6, 2008, at 6:44 PM, Joshua
Joshua,
The C++ application wouldn't consume a JMS ObjectMessage; rather, it
would have the message transformed to something it can consume, say
XML. This transformation process is where Apache Camel comes in. The
ActiveMQ 5.x broker can embed Camel components that will allow you to
You may want to upgrade to ActiveMQ-CPP 2.2 - which fixed several bugs.
Regards,
Nate
On Jul 5, 2008, at 12:35 AM, dingjing wrote:
i start my c++ consumer listener and wait for message comming
infinitely
it works normally,but it always lost connection to broker whitout
exception
after
Just ran against v5.1.0 of the broker and the durable tests run fine,
so I think we can ignore my problems last night against v5.0.0.
You're right, the release notes were there - apologies!
So I think the only real problems are the failed unit tests - I'll
cook up an issue to document it.
Awesome job getting this out, Tim!
I checked out the tag on OS X and built and ran the unit tests.
Everything builds cleanly, but I did notice a couple of failed unit
tests (both in MathTest):
1) test: decaf::lang::MathTest::test_hypot_DD (F) line: 262 decaf/lang/
MathTest.cpp
equality
Sounds like a bug - mind opening a JIRA issue for this?
Thanks,
Nate
On Feb 5, 2008, at 12:51 PM, Tom Johnson wrote:
I was trying to use a map message from a C++ program. It appears
to send a
message but none of the fields from the map. I tested this by
modifying
the
Would you mind creating a JIRA issue for this?
Nate
On Feb 1, 2008, at 1:54 AM, pfid wrote:
Hello,
i'm having problems with our activemq application in production
environment.
the application core dumped several times during the last days when
the
connection to the broker was lost. each
Yes, that is a possibility. Making an error handling routine
synchronized is probably your best bet.
Nate
On Jan 16, 2008, at 5:19 AM, gali_ka wrote:
we have an c++ application using activemq.
As we understand, in case of broken connection we can get a signal
about it
from two places:
Hi,
Hi,
i'm using activemq in my c++ application. I have one connection and
one
session for this connection. I see that the session
(SessionExecutor) starts
a new thread. I set my class that starts the connection and the
session to
be the exceptionListener. Does that mean that the
Hi Phillip,
We don't have anything planned yet, but you're more than welcome to
capture a JIRA issue (http://issues.apache.org/activemq/browse/AMQCPP)
and we'll see if we can work it into 2.2.
Regards,
Nate
On Dec 19, 2007, at 9:27 AM, fettuccini wrote:
Are there any plans to bring the
Robert,
I've captured what you have to do to change the timeout here
http://issues.apache.org/activemq/browse/AMQCPP-157
Regards,
Nate
Yes please tell me where to change the code for th etime out I will re
compile and try.
Hey James,
I've captured the details here
http://issues.apache.org/activemq/browse/AMQCPP-157
Looks like the C++ producer's response correlator timed out when
waiting for a response for a sent bytes message (this timeout defaults
to 3 seconds).
It may simply be that the app was bogging
On a side note, we've got SSL on our todo list for C++ as well :). If
you're thinking about putting SSL into C#, it might help work together
to nail down the basic user interface. Some of our thoughts on how it
should work from the user perspective were captured here:
,
Nate
On Dec 11, 2007, at 11:22 PM, Rob Davies wrote:
Hi Nathan,
I think we just need ensure that the C/C++/C# clients handle flow
control with the broker
cheers,
Rob
On Dec 12, 2007, at 4:05 AM, Nathan Mittler wrote:
Appreciate your feedback and helping to identify this problem!
I've
Appreciate your feedback and helping to identify this problem! I've
captured this in a JIRA issue here:
https://issues.apache.org/activemq/browse/AMQCPP-157
We'll do our best to get this resolved soon!
Regards,
Nate
On Dec 11, 2007, at 9:10 AM, Hellweek wrote:
As promised I have created
Hi John,
That sounds like the correct use case. Even if it wasn't, it
shouldn't core dump :)
Would you mind capturing this in a JIRA issue (http://issues.apache.org/activemq/browse/AMQCPP
) and attaching a sample that causes the problem?
Thanks,
Nate
On Nov 21, 2007, at 5:52 AM,
Our discussion has been specifically about the C++ client, ActiveMQ-CPP.
The wire format (OpenWire, Stomp) is a layer on top of the transport (tcp).
It is done this way so that you can use any wire format with any transport.
ActiveMQ-CPP does not yet support an SSL transport, therefore it is
example in SSL/STOMP/Ruby ?
Thanks a lot for your time.
On Thu, 2007-11-01 at 09:36 -0400, Nathan Mittler wrote:
Our discussion has been specifically about the C++ client, ActiveMQ-CPP.
The wire format (OpenWire, Stomp) is a layer on top of the transport
(tcp).
It is done this way so
In preparation for the soon to be released ActiveMQ-CPP 2.1.1, we have
released an update to the CMS (C++ Messaging Service) API. The main change
in this release was to make the readXXX() methods in BytesMessage const so
that they can be called from a MessageListener's onMessage method without
Which version of ActiveMQ-CPP are you using and against which ActiveMQ
broker version? Also, platform might be helpful.
I'm creating a C++ adapter class to represent a message consumer
connecting
to ActiveMQ.
Unfortunately, the consumers are not reliably receiving messages. Some
receive
Yes, in fact we're just about to start the ball rolling on 2.1.1. Should
have an official release soon.
Nate
On 10/25/07, appi03 [EMAIL PROTECTED] wrote:
I was just wondering if you guys were working on it. I am not sure if we
will
need but it would be a cool feature to have.
Btw, do you
Not sure I understand your question exactly. Are you looking to simply use
the threading classes in your own program or are you asking about how to
shutdown a connection?
If the latter, you simply have to do a connection.close().
If you're looking to use ActiveMQ-CPP's threading classes in
Is it possible you have multiple applications competing for the same port on
the server box? Might be worth while to bring down the broker and verify
that nothing else is running on any of those ports: 61616, 61613, 61617.
Also, you might want to disable the networkConnector until you've solved
Sounds fine to me.
+1
On 9/21/07, Albert Strasheim [EMAIL PROTECTED] wrote:
Hello
Maybe MessageListener::onMessage should be fixed to pass a non-const
Message
instead of pretending that BytesMessage::read is const when it isn't (also
consider something like std::istream::read, which isn't
I agree, this definitely would be a pain since the onMessage method gives
you a const Message. Could you capture this issue in JIRA?
http://issues.apache.org/activemq/browse/AMQCPP
Thanks,
Nate
On 9/21/07, Motl [EMAIL PROTECTED] wrote:
Hi,
I once asked you why readBytes() and other read
Hi everyone,
In preparation for releasing ActiveMQ-CPP 2.1, we're releasing a patched
version 1.1 of the CMS API (C++ Messaging Service). We've made a couple of
tweaks to decouple CMS from ActiveMQ-CPP and to support exporting symbols
from a shared library.
You can download the new API here:
If you want your consumer (even a durable one) to receive the messages, it
would have to have been registered on the topic before the message was
sent. At that point, you could kill your consumer and bring it back up and
it will get the messages it missed.
The way you have your application
Is it possible that you're sending the message before you've created the
consumer?
On 7/18/07, Nydia [EMAIL PROTECTED] wrote:
I sent the topic message using persistent:
destination = session-createTopic( TEST.FOO );
producer = session-createProducer( destination );
That would be my guess (use topic/SciTegic) ... the problem of creating
topics vs using pre-existing ones should not be a non-issue. All
topics/queues in ActiveMQ are dynamic, so it doesn't matter how you create
them (from the client-side or server-side). So long as the names are the
same, it
For those interested, we now have functioning links on the CMS website to
get to the API. You can check out the APIs here
http://activemq.apache.org/cms/api.html
Regards,
Nate
FYI, we're not planning on making any changes to activemq-cpp to address the
shortcomings of other compilers.
Regarding the destroy methods for deallocating amq-cpp resources, do you
think this would be required for clients that are built with newer msvc
compilers? Would it also be a problem
I've just upgraded my darwinports to the latest macports (renamed)
v1.440and also upgraded cppunit and the automake tools and everything
works for
me. My guess is that there must be a problem with your installation of
macports. For some reason, the build isn't finding your cppunit libraries
...
Ideally, the build should generate both the static and dynamic versions of
the library. Patches are always welcome :)
On 5/2/07, Kit Plummer [EMAIL PROTECTED] wrote:
Curious if there is a reason the default build for activemq-cpp is to
an archive - rather than a shared object library. The
That's strange ... I just checked on the wiki that generates the site and
the links work fine there. Perhaps the site generation was corrupted last
time around. I've just saved the navigation panel on the wiki to see if
this might sort out the broken links on the website. It will probably be
Hey everyone,
It's official ... ActiveMQ-CPP has OpenWire 2.0 support! (finally! :))
We've also found and fixed numerous bugs along the way. I've created a
download page here: http://activemq.apache.org/activemq-cpp-20-release.html
... Feel free to give it a test drive!
The links on this page
That is indeed the case and it has just been addressed in the AMQ-CPP
trunk. The patch will be included in the 2.0 release which should be out
soon.
On 4/2/07, James Strachan [EMAIL PROTECTED] wrote:
You might wanna switch to CLIENT_ACKNOWLEDGE to prevent this problem
(as the C++ client is
There are already some people trying out our latest trunk - you're more than
welcome (and encouraged) to try it out as well. We've got a handful of
issues that have popped up that we're working on now. I would say that it
will be a couple of weeks before we're ready for a release.
Regards,
Great! will do!
On 2/2/07, Lalit Nagpal [EMAIL PROTECTED] wrote:
Hey Nate-
It works great it works bcoz now message-getCMSReply() method
accepts a ::cms::Destination ... that makes it easier now
This change and the introduction of setter/getter methods in the
::cms::Message
43 matches
Mail list logo
