ActiveMQ client for J2ME
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 loginValidationid>eFileHandlerloginValidationmethod>abcianparams> ^@ 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
Re: No JIRA emails on the list since the move.
Guilty as charged :) Should be fine now. The spam detector in GMail is way too good; it thinks the moderate mails are spam (which most of them are). We need a moderate plugin for GMail :) James On 3/27/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: > thx! James, start moderating ;-) > > On 3/27/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > > I think James is. > > I am a moderator on ServiceMix and received a moderating mail the first > > time a notification has been sent. > > > > Guillaume > > > > Hiram Chirino wrote: > > > > >I have not seen any JIRA emails on the dev list since the JIRA > > >instance moved to Apache hardware. Perhaps it's emails are being > > >moderated? Who's a list moderator here? > > > > > >-- > > >Regards, > > >Hiram > > > > > > > > > > > > > > > > > -- > Regards, > Hiram > -- James --- http://radio.weblogs.com/0112098/
[jira] Created: (AMQ-664) Messages sent via STOMP don't have a correct JMSTimestamp.
Messages sent via STOMP don't have a correct JMSTimestamp. -- Key: AMQ-664 URL: https://issues.apache.org/activemq/browse/AMQ-664 Project: ActiveMQ Type: Improvement Components: Transport Versions: 4.0 RC1 Reporter: Bruce Mitchener Priority: Minor Messages sent via STOMP have no correct JMSTimestamp specified. (Or that's what jconsole indicates) -- 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-665) Error while using management interface on messages with binary data.
Error while using management interface on messages with binary data. Key: AMQ-665 URL: https://issues.apache.org/activemq/browse/AMQ-665 Project: ActiveMQ Type: Bug Reporter: Bruce Mitchener Priority: Minor I'm sending binary data through STOMP (with a content-length header). When I go into jconsole and try to use 'browse' to view the message, I get this exception on the server side: javax.management.openmbean.OpenDataException: Argument's element itemValues[7]="[EMAIL PROTECTED]" is not a valid value for this item (itemName=BodyPreview,itemType=javax.management.openmbean.ArrayType(name=[Ljava.lang.Byte;,dimension=1,elementType=javax.management.openmbean.SimpleType(name=java.lang.Byte))). at javax.management.openmbean.CompositeDataSupport.(CompositeDataSupport.java:145) at javax.management.openmbean.CompositeDataSupport.(CompositeDataSupport.java:190) at org.apache.activemq.broker.jmx.OpenTypeSupport.convert(OpenTypeSupport.java:253) at org.apache.activemq.broker.jmx.DestinationView.browse(DestinationView.java:91) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.sun.jmx.mbeanserver.StandardMetaDataImpl.invoke(StandardMetaDataImpl.java:414) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1408) at javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectionImpl.java:81) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1245) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1341) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:782) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) at sun.rmi.transport.Transport$1.run(Transport.java:153) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:149) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:595) -- 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: [Heads up] new visualisation plugin available
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/
Re: Regarding feedback on OpenWire C++ client
On 3/27/06, Mats Forslöf <[EMAIL PROTECTED]> wrote: > > 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. > Regards, > Mats & David > -- Regards, Hiram
Re: [Heads up] new visualisation plugin available
Very nice. Put some IP addresses there and refresh the DOT file periodically with some numbers/stats, and I'll start drooling. Otis - Original Message From: James Strachan <[EMAIL PROTECTED]> To: activemq-dev@geronimo.apache.org Sent: Sunday, March 26, 2006 11:45:45 PM Subject: [Heads up] new visualisation plugin available After being inspired by Gregor & Erik's talk at TSSJS 2 days ago, I hacked up a broker plugin to visualise the topic and queue hierarchy... http://docs.codehaus.org/display/ACTIVEMQ/Visualisation I'm sure we could do much more of this kind of thing - particularly on ServiceMix too - to help folks visualise the current system topology and configuration. -- James --- http://radio.weblogs.com/0112098/
RE: openwire C++ client
Nathan, in point 3, you certainly have a point. Even though I've been conscious about the internal structure of C++ objects, the fact that making an up-cast to one of multiple base classes needs ptr adjustment (as static_cast<> and dynamic_cast<> does), I have been missing this part when implementing the p_cast<> function. The reason why using void* is to be able to reuse classes internal refcounting mechanism if such is present, but attach an own refcounter where not. For example, the p<> template is compatible with both p and p. Thanks for seeing the problem. We will need to update the IFR code in order for the client to work properly where p_cast<> is used. I'll look into this and update the IFR. Mats and I will continue with testing and fixing issues. David -Original Message- From: Nathan Mittler [mailto:[EMAIL PROTECTED] Sent: den 26 mars 2006 23:12 To: activemq-dev@geronimo.apache.org Subject: openwire C++ client I've taken a closer look at the openwire C++ client this weekend and noticed a few things ... 1) I think there are a few cases where we could reduce the usage of smart pointers. One instance where I think smart pointer usage is questionable is when openwire is referencing an object that it doesn't control. For example, when my code declares a class that is an IMessageListener, it seems strange that this should be passed in as a smart pointer to openwire functions. Openwire doesn't control the lifetime of this object, so I don't believe it should be referencing it in a "managed" way. Another case where smart pointers could be avoided is strings. If all string member variables are std::strings, then the setXXX method could just take a "const char*" and the const getXXX method could simply return a "const char*" (which would be the value returned from the mystr.c_str() method). This makes for a much simpler and symmetric API. 2) ITextMessage should extend IMessage It seems that the ITextMessage class was at one time derived from IMessage, but it is commented out (probably to get through compilation :-) ). If you try to call send() on the MessagePublisher class with an ITextMessage, the code won't compile. I've gotten around this by making ITextMessage extend IMessage - the trick is that when you do this, ActiveMQTextMessage gets IMessage from two branches. In one branch, it gets the methods from IMessage implemented for it ( by ActiveMQMessage) and in the other branch (ITextMessage), it doesn't. So you have to have ActiveMQTextMessage implement all the methods from the IMessage interface and delegate them to the ActiveMQMessage base class. This seems to do the trick. 3) It seems that the smart pointer code should be using dynamic_cast rather than reinterpret cast. I seem to remember times where a dynamic_cast returned a slightly different address (in some cases). If this is the case, it could be very dangerous to use reinterpret_cast everywhere since it just takes the same pointer and treats its address as the other type (corrupting the references to the object). This could lead to strange bugs that are difficult to track down. The other problem is in the fact that the internal pointer is a void* rather than a T*. This complicates debugging, because the debugger sees an internal pointer, but doesn't look inside since it doesn't know what type it "really" is. 4) I'm not seeing an ExceptionListener equivalent. Am I missing something? 5) I got a small sample app compiling, but I'm getting a segfault when creating a session (could certainly be user error - a code snippet is below). Here's the stack dump: Thread [1] (Suspended: Signal 'SIGSEGV' received. Description: Segmentation fault.) 12 apache::activemq::client::command::ConnectionInfo::marshal() at src/command/ConnectionInfo.cpp:111 0x0804fd02 11 apache::activemq::client::protocol::OpenWireFormat::marshal() at src/protocol/OpenWireFormat.cpp:89 0x0808c0a3 10 apache::activemq::client::transport::SocketTransport::send() at src/transport/SocketTransport.cpp:144 0x08051650 9 apache::activemq::client::transport::SocketTransport::asyncRequest() at src/transport/SocketTransport.cpp:109 0x08052e11 8 apache::activemq::client::transport::SocketTransport::request() at src/transport/SocketTransport.cpp:123 0x08051362 7 apache::activemq::client::Connection::syncRequest() at src/Connection.cpp:188 0x0805e31e 6 apache::activemq::client::Connection::checkConnected() at src/Connection.cpp:298 0x0805e196 5 apache::activemq::client::Connection::syncRequest() at src/Connection.cpp:186 0x0805e2d1 4 apache::activemq::client::Connection::createSession() at src/Connection.cpp:173 0x0805fb56 3 apache::activemq::client::Connection::createSession() at src/Connection.cpp:162 0x0805db3b 2 Tester::test() at ../main.cpp:47 0x0804bd8a 1 main() at ../main.cpp:102 0x0804ab34 My code is a modified version of the cms sample ... the guts of the code is shown below int numMessa
Re: Regarding feedback on OpenWire C++ client
Hi Mats, On 3/27/06, Mats Forslöf <[EMAIL PROTECTED]> wrote: > > Hi All, > > Thanks everyone for looking at and testing the latest C++ client update. > Sorry if we have not been so clear regarding the stability of the code, the > code is highly untested and as said in the upload mail we will commence > testing/debugging shortly - so expect bugs!! No problem, bugs are expected ... just reporting that I think I found one :-) As we've just finished the port we will shift focus and look into all the > issues you have raised, see comments below. > > 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. 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. 2) ITextMessage should extend IMessage > > This was a last minute change to make it compile. Nate, your solution > seems to be a viable way of handling it - thanks! No problem. 3) SP dynamic_cast rather than reinterpret_cast > > It is correct that reinterpret_cast<> does not adjust the pointer value as > needed when casting between different classes in a class hierarchy. However, > the reinterpret_cast<> is used for casting between void* and objects and is > needed for the p<> template to work. Where such pointer-value-adjustment is > needed (up/down-casting), static_cast<> is used which works the same as > dynamic_cast<> except that it does no runtime type check. Hmmm ... so why are we using void* instead of T*? 4) ExceptionListener > > An ExceptionListener is missing. We could either add a method on > IMessageListener or add a new interface IExceptionListener, prefer the > latter. Ok? Agreed. 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. > > Regards, > Mats & David > Regards, Nate
Re: [jira] Updated: (AMQ-656) Update of AMQ C++ client
no problem! Nate On 3/27/06, David Fahlander <[EMAIL PROTECTED]> wrote: > > Oops... I've been building it using GCC on a linux but where the path is > smbmount:ed and hosted by a windows machine. Sorry about the error. > > Thanks, > /David > > -Original Message- > From: Nathan Mittler [mailto:[EMAIL PROTECTED] > Sent: den 26 mars 2006 19:51 > To: activemq-dev@geronimo.apache.org > Subject: Re: [jira] Updated: (AMQ-656) Update of AMQ C++ client > > Hi David, > One minor tweak (for linux) ... in Guid.cpp, the include should be > "Guid.hpp", > not "guid.hpp". Paths in linux are case-sensitive, so it won't build. > > Regards, > Nate > > On 3/24/06, David Fahlander (JIRA) <[EMAIL PROTECTED]> wrote: > > > > [ http://jira.activemq.org/jira//browse/AMQ-656?page=all ] > > > > David Fahlander updated AMQ-656: > > > > > > Attachment: source_060324.zip > > > > This is a complete update that replaces the previous attached file. > > > > Now compiles without warnings with full warning turned on on the > following > > compilers: > > > > gcc 3.4.3 > > gcc 4.0.2 > > visual c++ 2005 > > > > Fixes also done with marshalling of messageId as int instead of short. > > > > > > > > > Update of AMQ C++ client > > > > > > > > > Key: AMQ-656 > > > URL: http://jira.activemq.org/jira//browse/AMQ-656 > > > Project: ActiveMQ > > > Type: Improvement > > > > > Components: JMS client > > > Reporter: MF > > > Attachments: source_060323.zip, source_060324.zip > > > > > > > > > Attached is a new update of the C++ client, the zip-file contains > the > > full source since the update is a major overhaul. > > > > -- > > This message is automatically generated by JIRA. > > - > > If you think it was sent incorrectly contact one of the > administrators: > >http://jira.activemq.org/jira//secure/Administrators.jspa > > - > > For more information on JIRA, see: > >http://www.atlassian.com/software/jira > > > > >
RE: New AMQ C++ client update
Hi Erin, See previous post regarding stability/bugs. To run the scripts to generate the commands you'll need to the source and Maven 1.0.2. Go to the activemq-core subdirectory and run 'maven -o openwire:generate". You should omit the "-o" (offline) flag the first time so Maven downloads all required libs. If you're running on Windows you need to patch the maven.xml by adding a line beneatch section , see below. <--- Add this line The path problem is known and will be fixed in a later version of AMQ. Remember to update the scripts from the C++ client update. Regards, Mats -Original Message- From: ErinO [mailto:[EMAIL PROTECTED] Sent: den 24 mars 2006 23:36 To: activemq-dev@geronimo.apache.org Subject: Re: New AMQ C++ client update Hi, It is nice to try the C++ client update. Although there are some glitches (reference count problem, non-initialized variables etc.), I got the client talk to a broker, seems there are some marshalling issues which I don't know how to solve them. The C++ client tried to talk to a ActiveMQ4.0 M4 broker, they didn't understand each other, I am wondering which version's broker the client should talk to? RC? Could you please also tell me how to regenerate the command classes? Seems the page on the ActiveMQ.org shows how to use the groovy scripts is broken. Thanks Erin -- View this message in context: http://www.nabble.com/New-AMQ-C%2B%2B-client-update-t1330048.html#a3580516 Sent from the ActiveMQ - Dev forum at Nabble.com.
Regarding feedback on OpenWire C++ client
Hi All, Thanks everyone for looking at and testing the latest C++ client update. Sorry if we have not been so clear regarding the stability of the code, the code is highly untested and as said in the upload mail we will commence testing/debugging shortly - so expect bugs!! As we've just finished the port we will shift focus and look into all the issues you have raised, see comments below. 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. 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*". 2) ITextMessage should extend IMessage This was a last minute change to make it compile. Nate, your solution seems to be a viable way of handling it - thanks! 3) SP dynamic_cast rather than reinterpret_cast It is correct that reinterpret_cast<> does not adjust the pointer value as needed when casting between different classes in a class hierarchy. However, the reinterpret_cast<> is used for casting between void* and objects and is needed for the p<> template to work. Where such pointer-value-adjustment is needed (up/down-casting), static_cast<> is used which works the same as dynamic_cast<> except that it does no runtime type check. 4) ExceptionListener An ExceptionListener is missing. We could either add a method on IMessageListener or add a new interface IExceptionListener, prefer the latter. Ok? 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. Regards, Mats & David
