RE: Regarding feedback on OpenWire C++ client
Hi Hiram, 5) .NET namespace Hiram, what rules does Apache imply on this? Is it ok to use the namespaces your giving examples on? Looking on the Java code all Apache code starts with org.apache. As far as I know the org.apache namespace is a Java thing as it's the only language the encourages that form. I've never seen this form use in other languages yet. Even so it might be better to be a bit overzealous to prevent namespace clashes :) If ASF does not have any rules about this we'll change it - no problem. However, if we're to sync the names between C# and C++ the C# name spaces should be altered also!? C# namespace cms namespace activemq.command namespace activemq.core namespace activemq.io C++ namespace cms namespace activemq::command namespace activemq::io namespace activemq::marshal namespace activemq::protocol namespace activemq::transport namespace activemq::util Regards, Mats
Re: ActiveMQ client for J2ME
Awesome stuff BTW Ian - I'd *love* a J2ME Stomp/ActiveMQ client :) BTW the correlation-id is the Stomp-approved name for passing along the correlationID; in JMS-land its really a property called JMSCorrelationID, so changing your selector header to activemq.selector:JMSCorrelationID= '11143353544334-0' Should do the trick I think. I confess this renaming of JMSCorrelationID - correlation-id in Stomp could be a bit confusing for folks; maybe it'd be better if we let folks keep the regular JMS* style headers? (It'd be easy to support both BTW) James Ian de Beer wrote: Hi I have developed a J2ME client for ActiveMQ using the Stomp protocol. I would be happy to contribute this to the project, but I have a real show stopper issue that I cannot seem to resolve. I use it in a request/response mode with the request and subscription looking like this: SEND destination:/queue/Mobile.Queue reply-to:/queue/Temp.Queue correlation-id:11143353544334-0 ?xml version='1.0' encoding='UTF8' ?requestidloginValidation/ idbeaneFileHandler/beanmethodloginValidation/ methodparamspasswordabc/passwordusernameian/username/ params/request ^@ and : SUBSCRIBE destination:/queue/Temp.Queue activemq.selector:correlation-id = '11143353544334-0' ack:client ^@ Despite various permutations of correlation-id and selector settings, the clients keep consuming each others messages. Could someone please tell me what the Stomp syntax is for selecting messages with a specific correlation-id from the queue. Regards Ian -- View this message in context: http://www.nabble.com/ActiveMQ-client-for-J2ME-t1354154.html#a3627782 Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: Regarding feedback on OpenWire C++ client
On 3/28/06, David Fahlander [EMAIL PROTECTED] wrote:
Hi Nathan,
1) Use of smart pointers.
Though the user interface would be cleaner without smart pointers
they
serves a purpose even when the passed in object is not owned by the
client.
As soon as an object is shared between two classes you have the
problem when the object should be deleted - this problem is
eliminated
when using SP's, the object is deleted when both object releases its
reference to it.
I'm not sure I agree. For user-generated objects, it should be up to
the user to
add and remove references to them across the openwire library (such as
references
to IMessageListeners). When the user passes in a reference to one of
his objects,
he's not expecting to give any amount of lifetime control to the
openwire code.
In fact, the user object may not even have been created on the heap,
it may be a
local variable that was added just for the scope of a function. In
this case,
when the openwire library decides to delete it, the application blows
up! We
have to make a separation of what is and what is not under our
library's control.
We can't assume a structure of the client code, this forces the client
into a
particular way of programming and causes our client to become a burden
to the
developer and will turn them off to using ActiveMQ.
Regarding objects that the user provides, we still get benefits by using
smart pointers for them. It is not always the creator that is
responsible of deletion. Especially in a threaded application it can be
important to not end-up with ghost pointers. A thread in our client
library that holds a pointer to a listener, must be able to rely on that
the instance is still alive as long as it holds the SP to it. If the
user would provide an ordinary pointer, the user must never delete it as
long as there might be threads in our library using it. What about
static objects that should last forever in the client's lifetime then?
Still, we want to be able to take down the client in a controlled way.
Doing that without smart pointers, may create a lot of problems in our
experience.
The burden for the user would only lie in the classes that implement
our interfaces. If our API requires a pIMessageListener, the user must
hold his message listener using a pMyMessageListener allocated with
new MyMessageLister (...);. The user does not have to let this affect
his design. If the user wants, this instance can lie as a member within
another class that is neither derived from our interface nor maintained
as a smart pointer.
You get no benefits at all by adding smart pointers to the interface. The
user will delete their objects whenever they wish, regardless of what the
openwire library does ... and if it does so, the openwire library will
explode as soon as it tries to reference it. That's the thing - this is C++
and there is no mechanism to prevent someone from coding badly, and adding
smart pointers to the API isn't going to change that. The user is
responsible for both adding and removing referenes to its objects. And it's
not the job of the openwire lib to worry about memory management in the
user-domain - it should only be concerned with its own memory management.
In addition, smart pointers are assuming that the object is allocated on the
heap, as it will do a delete when the last reference is removed. This is
wrong, because the user should be able allocate its objects in whatever way
makes sense for the application.
Also, adding smart pointer arguments to all the methods on the api makes it
complicated and ugly. If the openwire library wants to use smart pointers
internally, that's fine, but it shouldn't impose the use of smart pointers
on the user. It's our job to make the user's experience a good one so they
continue to use ActiveMQ in their applications.
SP's and Strings: Semi-agreed :) The setters should all have const
char*
but we could change the getters to std:string (without SP), then it
is
up to the user to either use it as a std:string or a const char*.
I think symmetry is a good thing. We should pick one way or the other
...
either both the getter and setter take const char* or they both take
strings.
Also, when passing strings around, they should be passed as const
std::string ...
this way you don't have to copy the entire string, you just pass a
constant reference
to it. This will save a lot of processing when dealing with large
text messages, for
example.
The options we have regarding passing and holding strings are the
following:
Class Xxx {
pstring name;
public:
void setName (pstring name) {
this-name = name;
}
pstring getName () {
return this-name;
}
pstring createName() {
return new string (name: + *name);
}
};
In the above example, strings are never copied, just the ptr value. The
downside is that the caller needs to pass their strings as
[jira] Created: (AMQ-666) enable RESTful browsing of message queues using a web connector - either as message IDs or as XML or as RSS/Atom
enable RESTful browsing of message queues using a web connector - either as message IDs or as XML or as RSS/Atom Key: AMQ-666 URL: https://issues.apache.org/activemq/browse/AMQ-666 Project: ActiveMQ Type: New Feature Components: Broker Reporter: james strachan Assigned to: james strachan Fix For: 4.0 RC 2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: Regarding feedback on OpenWire C++ client
Nate,
You get no benefits at all by adding smart pointers to the interface.
The user will delete their objects whenever they wish, regardless of
what the openwire library does ... and if it does so, the openwire
library will explode as soon as it tries to reference it. That's the
thing - this is C++ and there is no mechanism to prevent someone from
coding badly, and adding smart pointers to the API isn't going to change
that. The user is responsible for both adding and removing referenes to
its objects. And it's not the job of the openwire lib to worry about
memory management in the user-domain - it should only be concerned with
its own memory management.
In addition, smart pointers are assuming that the object is allocated on
the heap, as it will do a delete when the last reference is removed.
This is wrong, because the user should be able allocate its objects in
whatever way makes sense for the application.
Also, adding smart pointer arguments to all the methods on the api makes
it complicated and ugly. If the openwire library wants to use smart pointers
internally, that's fine, but it shouldn't impose the use of smart pointers
on the user. It's our job to make the user's experience a good one so they
continue to use ActiveMQ in their applications.
Please define the interfaces that you want to be SP-free!
It's all about the user and helping them come up to speed and use the api
as quickly and painlessly as possible. I understand that in these cases
you're passing a pointer and not copying, but it complicates the user
interface when the person just wants to pass in a string. They shouldn't
have to create a string on the heap an then wrap it in a smart pointer to
just call a function.
Just a quick note, this is not necessary with the current design of accepting
const char* and returning pstring. The user can easily extract the const
char from the SP string if wanted.
Class Xxx {
std::string name;
void setName (const std::string name) {
this-name = name;
}
const std::string getName () const {
return this-name;
}
};
Shall we agree on the one above?
Regards,
Mats David
[jira] Resolved: (AMQ-666) enable RESTful browsing of message queues using a web connector - either as message IDs or as XML or as RSS/Atom
[ https://issues.apache.org/activemq/browse/AMQ-666?page=all ] james strachan resolved AMQ-666: Resolution: Fixed For details see: http://docs.codehaus.org/display/ACTIVEMQ/RSS+and+Atom enable RESTful browsing of message queues using a web connector - either as message IDs or as XML or as RSS/Atom Key: AMQ-666 URL: https://issues.apache.org/activemq/browse/AMQ-666 Project: ActiveMQ Type: New Feature Components: Broker Reporter: james strachan Assignee: james strachan Fix For: 4.0 RC 2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: ActiveMQ client for J2ME
BTW in 4.x I think the Stomp syntax for a selector is selector rather than activemq.selector though the latter will probably work too http://activemq.codehaus.org/Stomp -- View this message in context: http://www.nabble.com/ActiveMQ-client-for-J2ME-t1354154.html#a3628451 Sent from the ActiveMQ - Dev forum at Nabble.com.
RE: Regarding feedback on OpenWire C++ client
Please define the interfaces that you want to be SP-free!
I'm with Hiram ... I think the entire API should be SP-free. The less
the users have to see SPs, the better.
It's all about the user and helping them come up to speed and use the
api
as quickly and painlessly as possible. I understand that in these
cases
you're passing a pointer and not copying, but it complicates the user
interface when the person just wants to pass in a string. They
shouldn't
have to create a string on the heap an then wrap it in a smart pointer
to
just call a function.
Just a quick note, this is not necessary with the current design of
accepting const char* and returning pstring. The user can easily
extract the const char from the SP string if wanted.
But then you lose the symmetry of the getters and setters ... the setter
should take the same type that the getter returns. IMHO, it seems
strange to have the setter take a char* and then the getter returns a
smart pointer.
Class Xxx {
std::string name;
void setName (const std::string name) {
this-name = name;
}
const std::string getName () const {
return this-name;
}
};
Shall we agree on the one above?
Regards,
Mats David
Regards,
Nate
[jira] Created: (AMQ-667) fix SslTransportBrokerTest
fix SslTransportBrokerTest -- Key: AMQ-667 URL: https://issues.apache.org/activemq/browse/AMQ-667 Project: ActiveMQ Type: Test Components: Test Cases Reporter: james strachan Assigned to: Adrian Co -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Regarding feedback on OpenWire C++ client
On 3/28/06, Mats Forslöf [EMAIL PROTECTED] wrote: Hi Hiram, Even so it might be better to be a bit overzealous to prevent namespace clashes :) I would like to make this c++ lib, feel very c++ like, I don't want it to smell like it came from a Java shop. So I think it's better to have short names like most of the other libs out there. If ASF does not have any rules about this we'll change it - no problem. However, if we're to sync the names between C# and C++ the C# name spaces should be altered also!? C# namespace cms namespace activemq.command namespace activemq.core namespace activemq.io No.. becaue the C# one alos works for VB.NET and J# etc. etc. that's why the interface are in the .NET Message Service (NMS) namespace. Also .Net uses Camel case convention in it's namespaces. So we will do it like that. Once again the aim is to have a .NET library the feels very native. C++ namespace cms namespace activemq::command namespace activemq::io namespace activemq::marshal namespace activemq::protocol namespace activemq::transport namespace activemq::util This looks good to me! Regards, Mats -- Regards, Hiram
Re: [Heads up] new visualisation plugin available
I've just completed a second, more impressive visualisation that shows all the connections on a broker together with the producers and consumers, showing the flow of connection - producer - destination - subscriber - connection. http://docs.codehaus.org/display/ACTIVEMQ/Visualisation To minimise noise I've left off the actual session objects from the graph; you can kinda figure that out by the numbers in each producer/consumer (the first number is the session and the second the producer/consumer number) James On 3/27/06, James Strachan [EMAIL PROTECTED] wrote: On 3/27/06, OG [EMAIL PROTECTED] wrote: Very nice. Put some IP addresses there and refresh the DOT file periodically with some numbers/stats, and I'll start drooling. You read my mind :) So right now this DOT file is real time; every time a destination is added/removed we regenerate the DOT file. So using the OS X tool, we get a real time graphical view. (We could hopefully add a kinda web/ajax client on top of this to get real time visualisations on the management portal too). The part I really want us to do is to graphically represent how connections, sessions, consumers producers relate to brokers destinations within the brokers; together with stats. There's a ton of useful visualisations we can do - our only limitation here is our imagination. I've put together a visualisation wish list wiki page... http://docs.codehaus.org/display/ACTIVEMQ/Visualisation+Wish+List please if you can think of any interesting ideas for what we could visualise or how it could look, please add a note. Better still try patch the code to do it :) BTW if you are interested - here's the code for the real time rendering of the destination hierarchies http://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/broker/view/ as you can see its pretty simple stuff; we've a ton of stats and information inside the broker that it'll be really easy to render as some kind of picture -- James --- http://radio.weblogs.com/0112098/ -- James --- http://radio.weblogs.com/0112098/
[jira] Created: (AMQ-668) Build is broken - missing the rome_version and the jdom_version
Build is broken - missing the rome_version and the jdom_version --- Key: AMQ-668 URL: https://issues.apache.org/activemq/browse/AMQ-668 Project: ActiveMQ Type: Bug Versions: 4.0 Reporter: Bruce Snyder Attachments: project.properties.diff + | Executing clean ActiveMQ :: Web | Memory: 6M/9M + DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml build:end: Attempting to download rome-.jar. WARNING: Failed to download rome-.jar. Attempting to download jdom-.jar. WARNING: Failed to download jdom-.jar. BUILD FAILED File.. /Users/bsnyder/.maven/cache/maven-multiproject-plugin-1.4.1/plugin.jelly Element... maven:reactor Line.. 218 Column -1 The build cannot continue because of the following unsatisfied dependencies: rome-.jar jdom-.jar Total time : 1 minutes 21 seconds Finished at : Tuesday, March 28, 2006 1:51:36 PM MST -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-668) Build is broken - missing the rome_version and the jdom_version
[ https://issues.apache.org/activemq/browse/AMQ-668?page=all ] Bruce Snyder updated AMQ-668: - Attachment: project.properties.diff Build is broken - missing the rome_version and the jdom_version --- Key: AMQ-668 URL: https://issues.apache.org/activemq/browse/AMQ-668 Project: ActiveMQ Type: Bug Versions: 4.0 Reporter: Bruce Snyder Attachments: project.properties.diff + | Executing clean ActiveMQ :: Web | Memory: 6M/9M + DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml build:end: Attempting to download rome-.jar. WARNING: Failed to download rome-.jar. Attempting to download jdom-.jar. WARNING: Failed to download jdom-.jar. BUILD FAILED File.. /Users/bsnyder/.maven/cache/maven-multiproject-plugin-1.4.1/plugin.jelly Element... maven:reactor Line.. 218 Column -1 The build cannot continue because of the following unsatisfied dependencies: rome-.jar jdom-.jar Total time : 1 minutes 21 seconds Finished at : Tuesday, March 28, 2006 1:51:36 PM MST -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-669) Add a keepDurableSubsActive option to brokers so that durable subs eagerly loaded and kept in memory
Add a keepDurableSubsActive option to brokers so that durable subs eagerly loaded and kept in memory Key: AMQ-669 URL: https://issues.apache.org/activemq/browse/AMQ-669 Project: ActiveMQ Type: Improvement Components: Broker Reporter: Hiram Chirino Assigned to: Hiram Chirino Fix For: 4.0 RC 2 Problem is described at: https://issues.apache.org/activemq/browse/AMQ-493 One way to solve this is to avoid getting to the big backlog of messages. The there are not too many messages to recover, then AMQ-493 is not an issue. Add a keepDurableSubsActive option to the broker would be a workaround to this issue. The down side is that the broker would eventually block if the durable consumer is offline for too long. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
