Hi Nathan,
Please review the following patch. It allows the stomp client to accept a
variable amount of while space between frames. I ran the integration tests
a slightly modified amq broker where it used 3 \n between frames and also
one where no \n were used between frames. Everything seemed to work, but
since c++ is not my forte, I'm looking for a +1 from a before I commit the
change.
Index: src/main/activemq/connector/stomp/StompCommandReader.cpp
===================================================================
--- src/main/activemq/connector/stomp/StompCommandReader.cpp (revision
418889)
+++ src/main/activemq/connector/stomp/StompCommandReader.cpp (working
copy)
@@ -70,20 +70,46 @@
void StompCommandReader::readStompCommand( StompFrame& frame )
throw ( StompConnectorException )
{
- // Read the command;
- int numChars = readStompHeaderLine();
+ while( true )
+ {
+ // Clean up the mess.
+ buffer.clear();
- if( numChars <= 0 )
- {
- throw StompConnectorException(
- __FILE__, __LINE__,
- "StompCommandReader::readStompCommand: "
- "Error on Read of Command Header" );
- }
+ // Read the command;
+ readStompHeaderLine();
- // Set the command in the frame - copy the memory.
- frame.setCommand( reinterpret_cast<char*>(&buffer[0]) );
-
+ // Ignore all white space before the command.
+ int offset=-1;
+ for( size_t ix = 0; ix < buffer.size()-1; ++ix )
+ {
+ // Find the first non space character
+ char b = buffer[ix];
+ switch ( b )
+ {
+ case '\n':
+ case '\t':
+ case '\r':
+ break;
+
+ default:
+ offset = ix;
+ break;
+ }
+
+ if( offset != -1 )
+ {
+ break;
+ }
+ }
+
+ if( offset >= 0 )
+ {
+ // Set the command in the frame - copy the memory.
+ frame.setCommand(
reinterpret_cast<char*>(&buffer[offset]) );
+ break;
+ }
+
+ }
// Clean up the mess.
buffer.clear();
}
@@ -224,8 +250,7 @@
read( &buffer[0], content_length );
// Content Length read, now pop the end terminator off (\0\n).
- if(inputStream->read() != '\0' ||
- inputStream->read() != '\n')
+ if(inputStream->read() != '\0' )
{
throw StompConnectorException(
__FILE__, __LINE__,
@@ -251,16 +276,6 @@
continue;
}
- // We read up to the first NULL, now lets pop off the required
- // newline to complete the packet.
- if(inputStream->read() != '\n')
- {
- throw StompConnectorException(
- __FILE__, __LINE__,
- "StompCommandReader::readStompBody: "
- "Read Body, and no trailing newline");
- }
-
break; // Read null and newline we are done.
}
}
On 7/3/06, Nathan Mittler <[EMAIL PROTECTED]> wrote:
No problem - sorry for the confusion :)
On 7/3/06, Hiram Chirino <[EMAIL PROTECTED]> wrote:
>
> Oh. That makes sense! Sorry for the noise!
>
> On 7/3/06, Mittler, Nathan <[EMAIL PROTECTED]> wrote:
> >
> > Hey Hiram,
> > I was actually thinking of the messages coming from the broker to the
> > client - the newer version of the broker always sends a \0\n to denote
> > the end of the frame. I'm not sure if the CMS client is sly enough to
> > handle both cases - I think it's expecting one or the other (either \0
> > or \0\n). I was just throwing that out there as a possible reason
that
> > the client may freeze on a read - waiting for the trailing \n that
never
> > comes.
> >
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> > > Of Hiram Chirino
> > > Sent: Monday, July 03, 2006 12:58 PM
> > > To: [email protected]
> > > Subject: Re:
> > >
> > > Hi Nathan,
> > >
> > > I'm not so sure about that. I think that AMQ should support
> > > receiving a STOMP frame terminated by \0 without a subsequent
> > > \n. The STOMP spec does say that white space before a frame
> > > should be ignored. Anyways, if anybody can confirm that this
> > > is not the case, then it's a bug with how we implemented STOMP in
AMQ.
> > >
> > > On 7/3/06, Mittler, Nathan <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hi Naveen,
> > > > There are a couple of things that might be causing this.
> > > >
> > > > 1) The stomp frame ending characters have changed in recent
> > > versions
> > > > of AMQ. AMQ now enforces that stomp frames end with \0\n
> > > for all commands.
> > > > If you have an older version of CMS, and a fairly new
> > > version of AMQ
> > > > (e.g. 4.0), they may not play nice together.
> > > >
> > > > 2) I have seen some deadlocking occur on compilers that
> > > don't support
> > > > the PTHREAD_MUTEX_RECURSIVE type for mutexes (the code checks
> > > > __USE_UNIX98 and __APPLE__ flags to make this determination. CMS
> > > > requires recursive mutexes to work properly - it will deadlock
> > > > otherwise.
> > > >
> > > > Regardless of what your particular problem is, I recommend
> > > downloading
> > > > and trying out the activemq-cpp code
> > > >
> > > (
https://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-cp
> > > > p/ ). It solves the mutex problem (since it doesn't use recursive
> > > > mutexes) and has been tested against AMQ 4.0.1 (it actually
> > > requires
> > > > 4.0.1 or greater).
> > > >
> > > > Give that a try and let me know how it goes.
> > > >
> > > > Regards,
> > > > Nate
> > > >
> > > > > -----Original Message-----
> > > > > From: Naveen Rawat [mailto:[EMAIL PROTECTED]
> > > > > Sent: Saturday, July 01, 2006 9:15 AM
> > > > > To: [email protected]; [EMAIL PROTECTED]
> > > > > Subject:
> > > > >
> > > > > Hi there..!!
> > > > >
> > > > >
> > > > >
> > > > > I was trying out CMS OPENWIRE C++ APIs on SUSE Linux 10.0(Kernel
> > > > > release
> > > > > 2.6.13-15.8-default)
> > > > > Whenever I try to execute TestMain.cpp it gives the following
and
> > > > > goes into sleep mode.
> > > > >
> > > > >
> > > > > Connecting to ActiveMQ broker...
> > > > > Opening socket to: 127.0.0.1 on port 61666 Sending command:
> > > > > cmd.id = 1, corr.id = -1, type = CONNECTION_INFO Received
> > > > > command: cmd.id = 0, corr.id = -1, type =
> > > WIRE_FORMAT_INFO Received
> > > > > command: cmd.id = 1, corr.id = -1, type = BROKER_INFO
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > My AMQ Server is running as :
> > > > >
> > > > > ACTIVEMQ_HOME: /home/nrawat/incubator-activemq-4.0
> > > > > Loading message broker from: xbean:activemq.xml Created
> > > MBeanServer
> > > > > with ID: da6bf4:10c2b32b38c:-8000:kuwix:1
> > > > > INFO BrokerService - ActiveMQ 4.0 JMS
> > > > > Message Broker
> > > > > (localhost) is starting
> > > > > INFO BrokerService - For help or more
> > > > > information please
> > > > > see: http://incubator.apache.org/activemq/
> > > > > RMIConnectorServer started at:
> > > > > service:jmx:rmi://kuwix/jndi/rmi://localhost:1099/jmxrmi
> > > > > INFO ManagementContext - JMX consoles can connect
to
> > > > > service:jmx:rmi://kuwix/jndi/rmi://localhost:1099/jmxrmi
> > > > > INFO JDBCPersistenceAdapter - Database driver
recognized:
> > > > > [apache_derby_embedded_jdbc_driver]
> > > > > INFO JournalPersistenceAdapter - Journal Recovery
> > > > > Started from: Active
> > > > > Journal: using 5 x 20.0 Megs at:
> > > > > /home/nrawat/incubator-activemq-4.0/activemq-data/journal
> > > > > INFO JournalPersistenceAdapter - Journal Recovered: 0
> > > > > message(s) in
> > > > > transactions recovered.
> > > > > INFO TransportServerThreadSupport - Listening for
> > > connections at:
> > > > > tcp://kuwix:61666
> > > > > WARN MulticastDiscoveryAgent - brokerName not set
> > > > > INFO TransportConnector - Connector default Started
> > > > > INFO TransportServerThreadSupport - Listening for
> > > connections at:
> > > > > tcp://kuwix:61633?wireFormat=stomp
> > > > > INFO TransportConnector - Connector stomp Started
> > > > > INFO NetworkConnector - Network Connector
> > > > > default Started
> > > > > INFO BrokerService - ActiveMQ JMS Message
Broker
> > > > > (localhost, ID:kuwix-2163-1151775977128-1:0) started
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Hearty Regards,
> > > > >
> > > > > Naveen Rawat
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Regards,
> > > Hiram
> > >
> > > Blog: http://hiramchirino.com
> > >
> >
>
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
