[jira] Commented: (QPID-1119) [Java] Timeout on consumer creation with large queues
[ https://issues.apache.org/jira/browse/QPID-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12757858#action_12757858 ] Martin Ritchie commented on QPID-1119: -- FAQ Entry http://cwiki.apache.org/confluence/display/qpid/Qpid+Java+FAQ#QpidJavaFAQ-Clientkeepsthrowing%27Serverdidnotrespondinatimelyfashion%27. [Java] Timeout on consumer creation with large queues - Key: QPID-1119 URL: https://issues.apache.org/jira/browse/QPID-1119 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: M2.1 Reporter: Marnie McCormack Assignee: Aidan Skinner Fix For: M4 We've seen consumer timeout (Error registering consumer: org.apache.qpid.AMQTimeoutException: Server did not respond in a timely fashion). This was seen with volume testing, and 45,000 messages in the queue the consumer was attempting to connect to. The issue there is that for every subscription request it needs to go over the whole queue, to work out which messages should go to which subscriber. The broker runs with number of threads == number of cores, so if you have lots of consumers they will queue up behind one another to get processed. One solution is to stagger the consumer starts on the appication side, but we can also expose the connection timeout for configuration so that applications can use this. Thus need to create a configurable timeout for sync responses. Rob Godfrey can advise if further info required. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1119) [Java] Timeout on consumer creation with large queues
[ https://issues.apache.org/jira/browse/QPID-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Ritchie updated QPID-1119: - Fix Version/s: (was: M4) M3 [Java] Timeout on consumer creation with large queues - Key: QPID-1119 URL: https://issues.apache.org/jira/browse/QPID-1119 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: M2.1 Reporter: Marnie McCormack Assignee: Aidan Skinner Fix For: M3 We've seen consumer timeout (Error registering consumer: org.apache.qpid.AMQTimeoutException: Server did not respond in a timely fashion). This was seen with volume testing, and 45,000 messages in the queue the consumer was attempting to connect to. The issue there is that for every subscription request it needs to go over the whole queue, to work out which messages should go to which subscriber. The broker runs with number of threads == number of cores, so if you have lots of consumers they will queue up behind one another to get processed. One solution is to stagger the consumer starts on the appication side, but we can also expose the connection timeout for configuration so that applications can use this. Thus need to create a configurable timeout for sync responses. Rob Godfrey can advise if further info required. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1766) Implemention of selector using Xquery
[ https://issues.apache.org/jira/browse/QPID-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chenta lee updated QPID-1766: - Attachment: prime_number.diff Here is an example that use selector to get the prime number between 1~100 Implemention of selector using Xquery - Key: QPID-1766 URL: https://issues.apache.org/jira/browse/QPID-1766 Project: Qpid Issue Type: Improvement Components: C++ Broker, C++ Client Environment: Linux Reporter: chenta lee Attachments: chenta.diff, Makefile.patch, Makefile.patch, message_selector_pytest.patch, prime_number.diff, selector.diff, selector.diff, selector.patch, selector.patch, selector_broker.patch, selector_client.patch, selector_client.patch, selector_example.zip, selector_new.diff, selector_pytest.diff I implemented the message selector for C++ broker and client using Xquery. I will attach an example later. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [QPID-1871] Java Client Dispatcher change proposal.
Martin Ritchie wrote: Hi, Following on from looking at QPID-1871. I believe that there is quite a significant change required to ensure that the message order or rollback is maintained. I propose that we extract the Dispatcher from AMQSession, which will simplify our biggest class (3100+ lines!) and show clear responsibility for incoming message processing. This will simplify rollback as the Dispatcher thread can be given full responsibility for clearing up the state that it knows best. Rather than the current situation where the calling thread does some work on AMQSession whilst the Dispatcher is running/stopping, then calls the the Dispatcher code directly clean up the remainder. All this while the Dispatcher may be processing a message. Change design posted here: http://cwiki.apache.org/confluence/display/qpid/0.6+Java+Client+Dispatcher+Changes Comments on the investigation, implications and design welcome. I'll capture the details on the wiki so we don't lose track of comments Hey Martin, Sorry I didn't pick up on this earlier. We hit this issue a while back in the 0-10 code path. That's why we added RollbackOrderTest, and that's why it doesn't fail for 0-10 brokers. You should probably check out AMQSession.syncDispatchQueue, this method pretty much solves the problem you're describing. It will block until the dispatch queue is empty... or more precisely it will block until everything that is currently in the dispatch queue has been processed by the dispatcher thread, which if done after stopping incoming message flow means it will block until the dispatch queue is empty. This method is used in a few places in the 0-10 codepath where it is necessary to clean out the dispatch queue prior to proceeding (e.g. during failover), however the key place here is AMQSession_0_10.releaseForRollback. If you look at this you'll notice that it is called before the release is actually done. If AMQSession_0_8.releaseForRollback were to do the same, or preferrably if we were to move the syncDispatchQueue call up to AMQSession.java then I suspect this problem would go away without the need for a large refactor. --Rafael - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [QPID-1871] Java Client Dispatcher change proposal.
2009/9/21 Rafael Schloming rafa...@redhat.com: Martin Ritchie wrote: Hi, Following on from looking at QPID-1871. I believe that there is quite a significant change required to ensure that the message order or rollback is maintained. I propose that we extract the Dispatcher from AMQSession, which will simplify our biggest class (3100+ lines!) and show clear responsibility for incoming message processing. This will simplify rollback as the Dispatcher thread can be given full responsibility for clearing up the state that it knows best. Rather than the current situation where the calling thread does some work on AMQSession whilst the Dispatcher is running/stopping, then calls the the Dispatcher code directly clean up the remainder. All this while the Dispatcher may be processing a message. Change design posted here: http://cwiki.apache.org/confluence/display/qpid/0.6+Java+Client+Dispatcher+Changes Comments on the investigation, implications and design welcome. I'll capture the details on the wiki so we don't lose track of comments Hey Martin, Sorry I didn't pick up on this earlier. We hit this issue a while back in the 0-10 code path. That's why we added RollbackOrderTest, and that's why it doesn't fail for 0-10 brokers. You should probably check out AMQSession.syncDispatchQueue, this method pretty much solves the problem you're describing. It will block until the dispatch queue is empty... or more precisely it will block until everything that is currently in the dispatch queue has been processed by the dispatcher thread, which if done after stopping incoming message flow means it will block until the dispatch queue is empty. This method is used in a few places in the 0-10 codepath where it is necessary to clean out the dispatch queue prior to proceeding (e.g. during failover), however the key place here is AMQSession_0_10.releaseForRollback. If you look at this you'll notice that it is called before the release is actually done. If AMQSession_0_8.releaseForRollback were to do the same, or preferrably if we were to move the syncDispatchQueue call up to AMQSession.java then I suspect this problem would go away without the need for a large refactor. --Rafael Hi Rafi, I saw the syncDispatchQueue method but I don't think waiting for the _queue to clear is not the right solution, IMO, for rollback, even on 0-10. When rollback is called you don't want the dispatcher to process any more messages. Your client may have MessageListeners setup that will take a long time to process, so the Dispatcher should stop processing messages and perform the Rollback. I've attached a new test for RollbackOrderTest that blocks because the syncDispatchQueue waits for the Dispatcher to empty the _queue. However, when called via the MessageListener.onMessage(), you end up blocking the Dispatcher. I can understand that you may wish to do the block for 0-10 Failover as there may still be useful data in the _queue. Also with failover you are guaranteed that it is not going to be the Dispatcher thread that is calling syncDispatchQueue. I think extracting the Dispatcher will make it clearer to show that the message processing varies in each protocol and will allow the Session classes to focus on the creation and control of Consumer/Producers. This will allow Dispatchers for each protocol to be cleaner and highlight the protocol differences at failover; A 0-8 Dispatcher that simply drops all pending messages compared to the 0-10 Dispatcher that attempts to process all the messages it has received. I think it is a significant change but I think it is worth it as it will improve the readability of the Client code as well as improving the testability. Currently AMQSession is not exactly easy to unit test so splitting it in to more discrete components and unit testing them will be beneficial. The change boils down to: - Extract Dispatcher Logic to Dispatcher_0_8 , Dispatcher_0_10 - Update AMQSession to use new Dispatcher - Update Dispatcher to be able to stop processing the _queue of messages and perform rollback. Cheers Martin -- Martin Ritchie Dispatcher-Channel-1 daemon prio=10 tid=0x083dc800 nid=0x2e65 waiting on condition [0x8e952000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0xb2000e78 (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:905) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1217) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:207) at
[jira] Commented: (QPID-2102) Exceeding reject queue policy under a transaction causes broker crash
[ https://issues.apache.org/jira/browse/QPID-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12757925#action_12757925 ] Gordon Sim commented on QPID-2102: -- Also, the policy check incorrectly comes after the enqueue on disk. Exceeding reject queue policy under a transaction causes broker crash -- Key: QPID-2102 URL: https://issues.apache.org/jira/browse/QPID-2102 Project: Qpid Issue Type: Bug Affects Versions: 0.5 Reporter: Gordon Sim Fix For: 0.6 To reproduce: Start a broker. Use qpid-tool to create a queue with a reject policy and a count limit of 5. Enqueue 10 records under a single transaction to that queue. Prepare and commit the transaction. Broker crashes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2102) Exceeding reject queue policy under a transaction causes broker crash
[ https://issues.apache.org/jira/browse/QPID-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated QPID-2102: - Attachment: QPID-2102.patch Candidate fix, also addresses QPID-2101. Exceeding reject queue policy under a transaction causes broker crash -- Key: QPID-2102 URL: https://issues.apache.org/jira/browse/QPID-2102 Project: Qpid Issue Type: Bug Affects Versions: 0.5 Reporter: Gordon Sim Fix For: 0.6 Attachments: QPID-2102.patch To reproduce: Start a broker. Use qpid-tool to create a queue with a reject policy and a count limit of 5. Enqueue 10 records under a single transaction to that queue. Prepare and commit the transaction. Broker crashes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2101) flow-to-disk not handled correctly for persistent messages that are enqueued on both durable and non-durable queues
[ https://issues.apache.org/jira/browse/QPID-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12757928#action_12757928 ] Gordon Sim commented on QPID-2101: -- See patch for QPID-2101 which addresses this issue also. flow-to-disk not handled correctly for persistent messages that are enqueued on both durable and non-durable queues --- Key: QPID-2101 URL: https://issues.apache.org/jira/browse/QPID-2101 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.5 Reporter: Gordon Sim Fix For: 0.6 If a persistent message is published to an exchange that routes that message to more than one queue, and if some of those queues are durable with flow-to-disk as the active policy and some are not, then its possible that the broker will release the content for the message due to exceeding the limit configured for the flow to disk policy on one queue. This will mean that delivery of the message from transient queues will fail as they are unable to reload the content. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-1766) Implemention of selector using Xquery
[ https://issues.apache.org/jira/browse/QPID-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12757977#action_12757977 ] Gordon Sim commented on QPID-1766: -- SelectorModule.h does not appear to be part of the latest patch. The use of a sequence number assigned from the position of the consumer that never gets updated for the consume case will be a problem for wrap-around of the sequence number I think. Implemention of selector using Xquery - Key: QPID-1766 URL: https://issues.apache.org/jira/browse/QPID-1766 Project: Qpid Issue Type: Improvement Components: C++ Broker, C++ Client Environment: Linux Reporter: chenta lee Attachments: chenta.diff, Makefile.patch, Makefile.patch, message_selector_pytest.patch, prime_number.diff, selector.diff, selector.diff, selector.patch, selector.patch, selector_broker.patch, selector_client.patch, selector_client.patch, selector_example.zip, selector_new.diff, selector_pytest.diff I implemented the message selector for C++ broker and client using Xquery. I will attach an example later. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2112) C++ Client: Facility needed for app to extract the user-ID in use for a connection
C++ Client: Facility needed for app to extract the user-ID in use for a connection --- Key: QPID-2112 URL: https://issues.apache.org/jira/browse/QPID-2112 Project: Qpid Issue Type: Improvement Components: C++ Client Affects Versions: 0.5 Reporter: Ted Ross Priority: Minor Fix For: 0.6 When using GSSAPI as the authentication mechanism, the client application does not know the identity used for an AMQP connection. This is because the SASL library automatically gets the identity from a keytab file and uses it to authenticate with the broker. If the application wishes to place the userID into the message properties for a produced message, it needs to be able to get the information from somewhere. I propose that the information be copied into the negotiated settings for a connection at the completion of the authentication exchange. Then, the client can get the identity string be calling getNegotiatedSettings on the connection. This change does not affect the API or ABI of the interface. It only enhances the meaning of the username field in negotiated settings. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2112) C++ Client: Facility needed for app to extract the user-ID in use for a connection
[ https://issues.apache.org/jira/browse/QPID-2112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated QPID-2112: --- Attachment: QPID-2112.patch This patch implements the proposal. Note that a hook has been provided for Windows (but not tested). C++ Client: Facility needed for app to extract the user-ID in use for a connection --- Key: QPID-2112 URL: https://issues.apache.org/jira/browse/QPID-2112 Project: Qpid Issue Type: Improvement Components: C++ Client Affects Versions: 0.5 Reporter: Ted Ross Priority: Minor Fix For: 0.6 Attachments: QPID-2112.patch When using GSSAPI as the authentication mechanism, the client application does not know the identity used for an AMQP connection. This is because the SASL library automatically gets the identity from a keytab file and uses it to authenticate with the broker. If the application wishes to place the userID into the message properties for a produced message, it needs to be able to get the information from somewhere. I propose that the information be copied into the negotiated settings for a connection at the completion of the authentication exchange. Then, the client can get the identity string be calling getNegotiatedSettings on the connection. This change does not affect the API or ABI of the interface. It only enhances the meaning of the username field in negotiated settings. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: svn commit: r813825 [1/2] - in /qpid/trunk/qpid/cpp/src: ./ qpid/broker/ qpid/sys/ qpid/xml/ tests/
On Mon, 2009-09-21 at 16:39 +0100, Gordon Sim wrote: On 09/17/2009 06:21 PM, Gordon Sim wrote: I don't mind how many Jiras we use to track the issues. I have created two already, but don't mind if those get augmented or replaced, providing we make the problems being solved clear. Carl, Kim, I have attached a candidate fix to QPID-2102 that also address QPID-2101. Have a look and let me know what you think. If we are all happy with this, I can commit it. Else we can keep seeking something agreeable to all. --Gordon The code looks good. One question, however: I do not see isPersistent() in PersisbableMessage - this will be needed for setting the transient flag correctly when enqueuing on the store. Did you handle it another way (by casting, for example)? I'll make a separate checkin of the exchange route() refactorisation from the previous (subsequently rolled out) checkin 813825, which is a helpful change, but it is no longer needed for this issue. Kim - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: svn commit: r813825 [1/2] - in /qpid/trunk/qpid/cpp/src: ./ qpid/broker/ qpid/sys/ qpid/xml/ tests/
On 09/21/2009 08:24 PM, Kim van der Riet wrote: On Mon, 2009-09-21 at 16:39 +0100, Gordon Sim wrote: On 09/17/2009 06:21 PM, Gordon Sim wrote: I don't mind how many Jiras we use to track the issues. I have created two already, but don't mind if those get augmented or replaced, providing we make the problems being solved clear. Carl, Kim, I have attached a candidate fix to QPID-2102 that also address QPID-2101. Have a look and let me know what you think. If we are all happy with this, I can commit it. Else we can keep seeking something agreeable to all. --Gordon The code looks good. One question, however: I do not see isPersistent() in PersisbableMessage - this will be needed for setting the transient flag correctly when enqueuing on the store. Did you handle it another way (by casting, for example)? I did not make that change. It sounds like a separate issue? - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[FYI] Found project - JavaScript bindings for AMQP 0-10 (Kamaloka-js)
Here is an interesting implementation of AMQP 0-10 in JavaScript. It is called Kamaloka-js. http://www.j5live.com/2009/09/03/introducing-kamaloka-js-amqp-javascript-bindings/ ---BeginMessage--- http://www.j5live.com/2009/09/03/introducing-kamaloka-js-amqp-javascript-bindings/ ---End Message--- - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2113) JMS client's default logging level should be WARN not DEBUG
JMS client's default logging level should be WARN not DEBUG
---
Key: QPID-2113
URL: https://issues.apache.org/jira/browse/QPID-2113
Project: Qpid
Issue Type: Bug
Components: Java Client
Affects Versions: 0.6
Reporter: Rajith Attapattu
Assignee: Rajith Attapattu
Fix For: 0.6
The way log4j works is as follows.
It will try to look for log4j.xml within the classpath.
Failing which it will try to look for log4j.properties within the classpath.
In our qpid-common-xx.jar we have a log4j.properties and the log level is
configured as follows.
log4j.logger.org.apache.qpid=${amqj.logging.level}, console
So unless the system property amqj.logging.level is set, it will default to
DEBUG. (log4j unfortunately defaults to DEBUG instead of WARN).
This causes an issue as out of the box performance for the JMS client is slow
due to the excessive logging.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-2113) JMS client's default logging level should be WARN not DEBUG
[
https://issues.apache.org/jira/browse/QPID-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajith Attapattu resolved QPID-2113.
Resolution: Fixed
A log4j.xml file for the client module was added in rev 817457 on qpid trunk.
I didn't meddle with the existing log4j.properties file present in the common
module as it maybe used in the broker.
However a cursory glance at the etc directory revealed that the the broker too
has a log4j.xml file.
So perhaps the log4j.properties files in the common module is not really needed.
(The settings given i the log4j.xml under the client module could be overridden
by explicitly specifying a log4.xml file using -Dlog.configuration property)
JMS client's default logging level should be WARN not DEBUG
---
Key: QPID-2113
URL: https://issues.apache.org/jira/browse/QPID-2113
Project: Qpid
Issue Type: Bug
Components: Java Client
Affects Versions: 0.6
Reporter: Rajith Attapattu
Assignee: Rajith Attapattu
Fix For: 0.6
The way log4j works is as follows.
It will try to look for log4j.xml within the classpath.
Failing which it will try to look for log4j.properties within the classpath.
In our qpid-common-xx.jar we have a log4j.properties and the log level is
configured as follows.
log4j.logger.org.apache.qpid=${amqj.logging.level}, console
So unless the system property amqj.logging.level is set, it will default to
DEBUG. (log4j unfortunately defaults to DEBUG instead of WARN).
This causes an issue as out of the box performance for the JMS client is slow
due to the excessive logging.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2114) The JMS Client does not default to the correct priority as specified in the spec
The JMS Client does not default to the correct priority as specified in the spec Key: QPID-2114 URL: https://issues.apache.org/jira/browse/QPID-2114 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.6 Reporter: Rajith Attapattu Assignee: Rajith Attapattu Priority: Minor Fix For: 0.6 The JMS Client does not default to the correct priority as specified in the spec. Currently it defaults to 0, but should be 4 (Message.DEFAULT_PRIORITY) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-2114) The JMS Client does not default to the correct priority as specified in the spec
[ https://issues.apache.org/jira/browse/QPID-2114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajith Attapattu resolved QPID-2114. Resolution: Fixed A fixed has been committed to rev 817478 on qpid trunk. I have also added a simple check for the default message priority in an existing test in JMSPropertiesTest. The JMS Client does not default to the correct priority as specified in the spec Key: QPID-2114 URL: https://issues.apache.org/jira/browse/QPID-2114 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.6 Reporter: Rajith Attapattu Assignee: Rajith Attapattu Priority: Minor Fix For: 0.6 The JMS Client does not default to the correct priority as specified in the spec. Currently it defaults to 0, but should be 4 (Message.DEFAULT_PRIORITY) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: Fwd: Requesting a project proposal for an Undergraduate 12 week project proposal
Hi Ishara, Hi Carl, Thanks a lot for your reply.I,m interested to contribute to the C# client. That would be great. I would be happy to give you any help to get started. Carl Trieloff wrote: - Cliff from Microsoft has submitted a C# client over the C++ client. This client is written in both C# (pure managed) and C++/CLI (mixed mode), so the language choice may influence which tasks are attractive to you. From qpid/wcf/ReadMe.txt: 2. Planned features (not yet available) === 1. Full AMQP type support, including maps and arrays 2. System.Transactions integration (local and distributed with dynamic escalation) 3. Prefetch window for inbound messages 4. Shared sessions 5. Connection failover with AMQP broker clusters 6. Temporary queues 7. Broker management 8. System logging and tracing 9. CMake build system support 10. Transport and message based security Carl's suggestion regarding QMF is a good one. It requires #1 as a prerequisite, but the two together should leave plenty of room for GUI flourishes too. It would be 90% C# and 10% C++/CLI (with simple boiler plate mixed mode needs). #4 is essentially straight forward, but exposes some of the nuanced differences between AMQP and WCF. Combined with #8 and some NUnit tests, this could also be a reasonable selection (99% C#). Broker management (#7), is a broader topic than QMF. If you have an interest in PowerShell programming or Management Console snap-ins, there are additional options to look at in this area. Brief notes about the others: #3 is already complete (QPID-2110). #2 should have a first cut ready in a week or so, and I am also actively working on #6. #5 requires that you have access to a Linux cluster of brokers. #9 is all about build scripts and compiler/linker options. #10 which is largely about completing missing bits in the native C++ client on Windows (SSL and SASL). Cliff -Original Message- From: ishara karunarathna [mailto:isharaar...@gmail.com] Sent: Monday, September 21, 2009 9:06 AM To: dev@qpid.apache.org; cctriel...@redhat.com Subject: Re: Fwd: Requesting a project proposal for an Undergraduate 12 week project proposal Hi Carl, Thanks a lot for your reply.I,m interested to contribute to the C# client. As I'm new to Apache Qpid I haven't proper idea on that, so can you suggest me where I can find more information on that. Regards Ishara - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1766) Implemention of selector using Xquery
[ https://issues.apache.org/jira/browse/QPID-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chenta lee updated QPID-1766: - Attachment: selector_patch_20090922.diff I forgot the add the header files before creating the new patch. Actually I didn't use any new algorithm, I just follow the original algorithm (the one before apply the selector patch), and change a little implemetation detail. So I think it won't be a problem. What do you mean by wrap-around the sequence number? It will be helpful if you could provide an example. If I update the position property of consumer, it will be troublesome to requeue the message. Implemention of selector using Xquery - Key: QPID-1766 URL: https://issues.apache.org/jira/browse/QPID-1766 Project: Qpid Issue Type: Improvement Components: C++ Broker, C++ Client Environment: Linux Reporter: chenta lee Attachments: chenta.diff, Makefile.patch, Makefile.patch, message_selector_pytest.patch, prime_number.diff, selector.diff, selector.diff, selector.patch, selector.patch, selector_broker.patch, selector_client.patch, selector_client.patch, selector_example.zip, selector_new.diff, selector_patch_20090922.diff, selector_pytest.diff I implemented the message selector for C++ broker and client using Xquery. I will attach an example later. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
