Re: handling slow consumers on non-persistent topics and AMQ-688
On 7/4/06, Hiram Chirino [EMAIL PROTECTED] wrote: The problem is there is a high likelyhood that we will need to also extend the MessageStore interface to provide some cursoring ablilities. So the change is not going to just be sefcontained in the broker region package. Ah I see - in that case I completely agree :). How about we only make a branch when we decide we have to do some major surgery, like changing the MessageStore? Maybe we can do a basic spool-to-disk implementation which is not optimal but works without major surgery? Or do you think its better to solve this via changing the MesaageStore contract, to deal with spooling of non-persistent messages anyway? -- James --- http://radio.weblogs.com/0112098/
Re: handling slow consumers on non-persistent topics and AMQ-688
These are all good questions.. And that's why I kinda was think a branch would be good since it would alow folks to go crazy figuring out the best solution and not have to work about breaking things while the changes are in progress. On 7/4/06, James Strachan [EMAIL PROTECTED] wrote: On 7/4/06, Hiram Chirino [EMAIL PROTECTED] wrote: The problem is there is a high likelyhood that we will need to also extend the MessageStore interface to provide some cursoring ablilities. So the change is not going to just be sefcontained in the broker region package. Ah I see - in that case I completely agree :). How about we only make a branch when we decide we have to do some major surgery, like changing the MessageStore? Maybe we can do a basic spool-to-disk implementation which is not optimal but works without major surgery? Or do you think its better to solve this via changing the MesaageStore contract, to deal with spooling of non-persistent messages anyway? -- James --- http://radio.weblogs.com/0112098/ -- Regards, Hiram Blog: http://hiramchirino.com
Re:
+1
Thanks for the patch!
Nate
On 7/4/06, Hiram Chirino [EMAIL PROTECTED] wrote:
It should be on it's way to your gmail account.
On 7/4/06, Nathan Mittler [EMAIL PROTECTED] wrote:
Hey Hiram,
Looks ok at first glance - could you send me the patch file as an
attachment? I seem to be having problems applying the patch through
copy
paste into subclipse.
Thanks,
Nate
On 7/3/06, Hiram Chirino [EMAIL PROTECTED] wrote:
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_castchar*(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_castchar*(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: activemq-dev@geronimo.apache.org
Subject: Re:
Hi Nathan,
I'm not so sure about that. I think that AMQ should support
receiving a STOMP frame terminated
[jira] Created: (AMQ-793) problem with auto-ack and messages being redelivered in Stomp clients
problem with auto-ack and messages being redelivered in Stomp clients - Key: AMQ-793 URL: https://issues.apache.org/activemq/browse/AMQ-793 Project: ActiveMQ Type: Bug Versions: 4.0.1 Reporter: james strachan Assigned to: Hiram Chirino Fix For: 4.0.2, 4.1 For discussion see http://www.nabble.com/Stomp-and-ActiveMessaging-does-not-remove-messages-from-Queue-tf1889402.html#a5165844 -- 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: New refactored STOMP implementation.
Hiram, BTW, did you run the activemq-cpp cpp-unit tests against the broker with the new stomp transport? I took a look at your code and it looks like you still have the request-id/response-id headers in there, so it should work fine. Looks a lot simpler - easier to find your way around. Nate On 7/4/06, James Strachan [EMAIL PROTECTED] wrote: It all looks good to me. Given we've already hit AMQ-793 recently... http://issues.apache.org/activemq/browse/AMQ-793 due to the flow control issues in the stomp implementation under load, I'd say lets get rid of the old version and go with the new. On 7/2/06, Hiram Chirino [EMAIL PROTECTED] wrote: Howdy STOMP developers, Just wantted to let you know that I spent the day doing some major refactoring to the STOMP server side protocol implementation in ActiveMQ. The previous implementation did all the work inside a WireFormat layer. The poll model that it imposed made some things difficult to do and made the code just ugly. I refactored it so that StompWireFormat takes the STOMP frames and produces StompCommand objects which are like a 1:1 mapping (Perhaps I should rename that to StompFrame). Then the stomp transport factory sets up the TcpTransport to be filtered by a StompTransportFilter which converts the StompCommand/Protocol into the ActiveMQ commands and Protocol. Since the Transport is more event based and is also aware of the transport lifecycle, it should let us continue to extend and add more features to the STOMP protocol easier. I implemented this in a new package so that we can easily switch back to the old implementation if needed. Out of the box we are now using the new implementation. But I'd like to get some feed back to see if it introduced any new bugs or if it fixed any old bugs. If all goes well, I'll get rid of the old version soon. -- Regards, Hiram Blog: http://hiramchirino.com -- James --- http://radio.weblogs.com/0112098/
[jira] Resolved: (AMQ-793) problem with auto-ack and messages being redelivered in Stomp clients
[ https://issues.apache.org/activemq/browse/AMQ-793?page=all ] Hiram Chirino resolved AMQ-793: --- Resolution: Fixed new stomp client which fixes this has been backported to 4.0 also. problem with auto-ack and messages being redelivered in Stomp clients - Key: AMQ-793 URL: https://issues.apache.org/activemq/browse/AMQ-793 Project: ActiveMQ Type: Bug Versions: 4.0.1 Reporter: james strachan Assignee: Hiram Chirino Fix For: 4.0.2, 4.1 For discussion see http://www.nabble.com/Stomp-and-ActiveMessaging-does-not-remove-messages-from-Queue-tf1889402.html#a5165844 -- 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-787) The UdpTransport could potentialy fail to bind on linux.. caused the UdpTransportTest to fail sometimes.
[ https://issues.apache.org/activemq/browse/AMQ-787?page=all ] Hiram Chirino updated AMQ-787: -- Fix Version: 4.0.2 The UdpTransport could potentialy fail to bind on linux.. caused the UdpTransportTest to fail sometimes. Key: AMQ-787 URL: https://issues.apache.org/activemq/browse/AMQ-787 Project: ActiveMQ Type: Bug Versions: 4.0 Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 4.1, 4.0.2 [junit] [ERROR] Test org.apache.activemq.transport.udp.UdpTransportTest FAILED -- 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] Commented: (AMQ-787) The UdpTransport could potentialy fail to bind on linux.. caused the UdpTransportTest to fail sometimes.
[ https://issues.apache.org/activemq/browse/AMQ-787?page=comments#action_36523 ] Hiram Chirino commented on AMQ-787: --- Fix also applied to 4.0 branch rev 419025. The UdpTransport could potentialy fail to bind on linux.. caused the UdpTransportTest to fail sometimes. Key: AMQ-787 URL: https://issues.apache.org/activemq/browse/AMQ-787 Project: ActiveMQ Type: Bug Versions: 4.0 Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 4.1, 4.0.2 [junit] [ERROR] Test org.apache.activemq.transport.udp.UdpTransportTest FAILED -- 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] Resolved: (AMQ-794) make the support of advisory messages optional (so that they can be disabled to reduce RAM and boost performance a little)
[ https://issues.apache.org/activemq/browse/AMQ-794?page=all ] james strachan resolved AMQ-794: Resolution: Fixed Done - you can now disable advisory support via broker advisorySupport=false... or BrokerService broker = new BrokerService(); broker.setAdvisorySupport(false); ... broker.start(); make the support of advisory messages optional (so that they can be disabled to reduce RAM and boost performance a little) -- Key: AMQ-794 URL: https://issues.apache.org/activemq/browse/AMQ-794 Project: ActiveMQ Type: Improvement Reporter: james strachan Assignee: james strachan Fix For: 4.1 -- 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-795) security plugin to deal with temporary queue and topics better
security plugin to deal with temporary queue and topics better -- Key: AMQ-795 URL: https://issues.apache.org/activemq/browse/AMQ-795 Project: ActiveMQ Type: Improvement Reporter: james strachan Fix For: 4.1 Allow a role to be specified for read/write/admin of temporary queue and temporary topics -- 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
