[jira] Commented: (UIMA-1130) Deployment Descriptor should allow setting the number of concurrent listeners for a reply queue
[ https://issues.apache.org/jira/browse/UIMA-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12620271#action_12620271 ] Adam Lally commented on UIMA-1130: -- I think Eddie is probably right that increasing the number of listeners should eliminate my need to set a prefetch 0. A thread that's being used to execute prefetch isn't doing anything that an additional listener thread wouldn't also do, as far as I understand it. So I'm +1 to proceed with the plan as Eddie outlined it. Deployment Descriptor should allow setting the number of concurrent listeners for a reply queue --- Key: UIMA-1130 URL: https://issues.apache.org/jira/browse/UIMA-1130 Project: UIMA Issue Type: Improvement Components: Async Scaleout Affects Versions: 2.2.2 Reporter: Adam Lally The Spring XML allows setting a concurrentConsumers property for a reply queue (either an aggregate's collocated reply queue or a remote reply queue): property name=concurrentConsumers value=1/ The deployment descriptor should allow setting this property. In some deployments where remote delegates are scaled out many times, the bottleneck can become the aggregate deserializing CASes from the reply queue. If the aggregate is running on a multicore machine it helps to increase the number of threads that can process the reply queue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (UIMA-1130) Deployment Descriptor should allow setting the number of concurrent listeners for a reply queue
It looks like we agree on the Eddie's original proposal and Marshall's suggestion to add concurrentConsumers (NOT concurrantConsumers ?) as an attribute to replyQueue element. I will proceed to modify DDE and submit the patch unless someone speaks up :) - Tong On Wed, Aug 6, 2008 at 10:42 AM, Adam Lally (JIRA) uima-dev@incubator.apache.org wrote: [ https://issues.apache.org/jira/browse/UIMA-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12620271#action_12620271] Adam Lally commented on UIMA-1130: -- I think Eddie is probably right that increasing the number of listeners should eliminate my need to set a prefetch 0. A thread that's being used to execute prefetch isn't doing anything that an additional listener thread wouldn't also do, as far as I understand it. So I'm +1 to proceed with the plan as Eddie outlined it. Deployment Descriptor should allow setting the number of concurrent listeners for a reply queue --- Key: UIMA-1130 URL: https://issues.apache.org/jira/browse/UIMA-1130 Project: UIMA Issue Type: Improvement Components: Async Scaleout Affects Versions: 2.2.2 Reporter: Adam Lally The Spring XML allows setting a concurrentConsumers property for a reply queue (either an aggregate's collocated reply queue or a remote reply queue): property name=concurrentConsumers value=1/ The deployment descriptor should allow setting this property. In some deployments where remote delegates are scaled out many times, the bottleneck can become the aggregate deserializing CASes from the reply queue. If the aggregate is running on a multicore machine it helps to increase the number of threads that can process the reply queue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1136) [DDE] Support editing of Prefetch value and set default value to 0 (instead of 1)
[DDE] Support editing of Prefetch value and set default value to 0 (instead of 1) - Key: UIMA-1136 URL: https://issues.apache.org/jira/browse/UIMA-1136 Project: UIMA Issue Type: Improvement Components: Async Scaleout Reporter: Tong Fin Assignee: Tong Fin Priority: Trivial Fix For: 2.3AS For the current version of DDE, to change the value of the Prefetch of the Top AE, the user needs to modify the value in the source XML. Until now, the default value is set to 1. We will modify the DDE as follows: 1. Allow user to modify the prefetch value with GUI (in the 1st page of DDE) 2. Set the default value to 0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (UIMA-1136) [DDE] Support editing of Prefetch value and set default value to 0 (instead of 1)
If we agree that the default value of the prefetch is 0 (instead of 1), we may need to modify the documentation as well. Should I create a new JIRA so that we don't forget ? - Tong On Wed, Aug 6, 2008 at 12:12 PM, Tong Fin (JIRA) uima-dev@incubator.apache.org wrote: [DDE] Support editing of Prefetch value and set default value to 0 (instead of 1) - Key: UIMA-1136 URL: https://issues.apache.org/jira/browse/UIMA-1136 Project: UIMA Issue Type: Improvement Components: Async Scaleout Reporter: Tong Fin Assignee: Tong Fin Priority: Trivial Fix For: 2.3AS For the current version of DDE, to change the value of the Prefetch of the Top AE, the user needs to modify the value in the source XML. Until now, the default value is set to 1. We will modify the DDE as follows: 1. Allow user to modify the prefetch value with GUI (in the 1st page of DDE) 2. Set the default value to 0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Getting ConceptMapper into the sandbox
I am just following up on the status of getting ConceptMapper actually into the sandbox, as it was approved by vote and all paperwork from seems to be in order. What needs to be done next, and is there anything I can do to help?
[jira] Created: (UIMA-1137) Service hangs if deployed before broker is ready
Service hangs if deployed before broker is ready Key: UIMA-1137 URL: https://issues.apache.org/jira/browse/UIMA-1137 Project: UIMA Issue Type: Bug Components: Async Scaleout Affects Versions: 2.2.2 Reporter: Burn Lewis Priority: Minor When both a service and its broker are restarted together (e.g. after a reboot) the service will fail to initialize if the broker is not ready. The service claims it is shutting down, e.g. with 3 lines such as: Terminating Controller:StoryBoundary Unable To Initialize Listener Due to Invalid Broker URL:tcp://telly.watson.ibm.com:61616 but it then hangs. The service should wait for the broker, and log to the console when it has successfully connected. Could also log a still trying indication every minute or so. Would be nice to suppress these spring error msgs: org.springframework.jms.listener.AbstractJmsListeningContainer$SharedConnectionNotInitializedException -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (UIMA-1130) Deployment Descriptor should allow setting the number of concurrent listeners for a reply queue
Marshall Schor (JIRA) uima-dev@incubator.apache.org wrote: are there use cases where the remote delegate would be able to get requests from the remote broker, but possibly not be able to send it replies? (e.g., due to firewall issues?) Yes, when the client is behind a firewall, but the remote delegate [service] and it's broker are outside the firewall. This is one of the motivations for always allocating the reply queue on the service's broker (the other main one being to eliminate the need for a colocated broker to instantiate a local reply queue, again something not possible with many JMS implementations). Well, I meant the other way 'round. So let me try again - are there use cases where the remote broker serves the remote delegate new work OK, but for some reason can't host the reply queue? Let's assume there is a case where the total size of in-transit request + reply messages for a single service are too big for a single broker; the AMQ answer would be to implement distributed queues. See http://activemq.apache.org/how-do-distributed-queues-work.html Putting reply queues on the client will burden every client with an extra memory requirement, and will require that memory planning for each client take into consideration all of its remote delegates. There should only ever be one listener pulling messages off of the reply queue. It is sometimes desirable to have more than one thread doing deserialization of reply messages, which is the original point of this issue. Yes, true - I meant one listener process (perhaps with mutliple threads though). So there's no need to worry about load balancing due to prefetch 0 - or is there? Not sure how these threads for multiple concurrent listeners interact with prefetch. Right, no load balancing issue for a reply queue. Eddie
Re: Getting ConceptMapper into the sandbox
Hi Michael, Thanks for pinging the list about this. It would help a lot if you could enter a Jira issue, and list the current status and tasks that are still needed to be accomplished. Here are the tasks (If some of these are done already, that's great): Do the IP Clearance Form for this (an ASF officer needs to review and commit this) Post a note to the Incubator general list advising of the IP Form, and asking for lazy-consensus approval Create the code base in SVN so it can be maintained (a committer does this) Update the web site - here, could you please draft a paragraph and attach it to the Jira of what it should say? If I left any off, please add them :-) . Thanks for your donation, and your help! -Marshall Michael Tanenblatt wrote: I am just following up on the status of getting ConceptMapper actually into the sandbox, as it was approved by vote and all paperwork from seems to be in order. What needs to be done next, and is there anything I can do to help?
[DISCUSS] holding a vote on the Cas Viewer submission
It looks to me like we're having technical discussions about how to merge the Cas Viewer and Cas Editor functionality, and that it may be time to hold a vote on accepting, officially, the Cas Viewer donation into the sandbox. See http://markmail.org/message/pqzknpc6ywngtiam Does the community wish to have more discussion about this before I call for the vote? -Marshall
Re: [DISCUSS] holding a vote on the Cas Viewer submission
Does the community wish to have more discussion about this before I call for the vote? I think there are still open questions which should be answered before a new vote. I would like to know if we merge with the Cas Editor, does this makes sense for us ? In my opinion this means technically that the Cas Viewer uses multiple views like the Cas Editor. Do we want this ? There is still a discussion about this in another thread. Who will work on the code once it is in the sandbox ? What are our plans for eclipse ui tooling ? How should it be ? Jörn
