[jira] Created: (UIMA-1642) Regex rule file parameter should allow wildcard expressions when using the datapath to locate rule files
Regex rule file parameter should allow wildcard expressions when using the datapath to locate rule files Key: UIMA-1642 URL: https://issues.apache.org/jira/browse/UIMA-1642 Project: UIMA Issue Type: Improvement Components: Sandbox-RegexAnnotator Affects Versions: 2.2.2 Reporter: Thilo Goetz Assignee: Thilo Goetz Priority: Minor Fix For: 2.3S Improve the regex annotator so it can load rule files with wildcard expressions such as ruledir/*.rule -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1642) Regex rule file parameter should allow wildcard expressions when using the datapath to locate rule files
[ https://issues.apache.org/jira/browse/UIMA-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thilo Goetz closed UIMA-1642. - Resolution: Fixed Done. Also added test cases and updated documentation. Regex rule file parameter should allow wildcard expressions when using the datapath to locate rule files Key: UIMA-1642 URL: https://issues.apache.org/jira/browse/UIMA-1642 Project: UIMA Issue Type: Improvement Components: Sandbox-RegexAnnotator Affects Versions: 2.2.2 Reporter: Thilo Goetz Assignee: Thilo Goetz Priority: Minor Fix For: 2.3S Improve the regex annotator so it can load rule files with wildcard expressions such as ruledir/*.rule -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1643) UIMA AS client does not recover correctly when the connection to a broker fails
UIMA AS client does not recover correctly when the connection to a broker fails --- Key: UIMA-1643 URL: https://issues.apache.org/jira/browse/UIMA-1643 Project: UIMA Issue Type: Bug Components: Async Scaleout Reporter: Jerry Cwiklik Priority: Blocker Fix For: 2.3AS When the connection to the broker is lost, the UIMA AS client does not attempt to reconnect as it is done in the UIMA AS service. When the jms send() fails due to a lost connection, the UIMA AS client notifies the application but in addition should log a single message that the connection was lost and enter a recovery loop attempting to reconnect at regular intervals. Any failures during this recovery should be silently handled. If the application does not want to recover from a bad connection it should call stop() on the client API which will stop the recovery, cleanup resources and terminate the UIMA AS client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1643) UIMA AS client does not recover correctly when the connection to a broker fails
[ https://issues.apache.org/jira/browse/UIMA-1643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12771483#action_12771483 ] Jörn Kottmann commented on UIMA-1643: - Isn't that the behavior you get when the broker URL is wrapped with failover:() e.g. failover:(tcp://broker:61616) ? UIMA AS client does not recover correctly when the connection to a broker fails --- Key: UIMA-1643 URL: https://issues.apache.org/jira/browse/UIMA-1643 Project: UIMA Issue Type: Bug Components: Async Scaleout Reporter: Jerry Cwiklik Priority: Blocker Fix For: 2.3AS When the connection to the broker is lost, the UIMA AS client does not attempt to reconnect as it is done in the UIMA AS service. When the jms send() fails due to a lost connection, the UIMA AS client notifies the application but in addition should log a single message that the connection was lost and enter a recovery loop attempting to reconnect at regular intervals. Any failures during this recovery should be silently handled. If the application does not want to recover from a bad connection it should call stop() on the client API which will stop the recovery, cleanup resources and terminate the UIMA AS client. -- 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-1643) UIMA AS client does not recover correctly when the connection to a broker fails
Initially this is exactly what I thought of doing. But we need finer level of control. Dont want to be stuck in the AMQ send method until the broker becomes available. Instead the code will silently retry connection indefinitely similar to Spring Listener's waitUntilSuccessfull(). 2009/10/29 Jörn Kottmann (JIRA) uima-dev@incubator.apache.org [ https://issues.apache.org/jira/browse/UIMA-1643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12771483#action_12771483] Jörn Kottmann commented on UIMA-1643: - Isn't that the behavior you get when the broker URL is wrapped with failover:() e.g. failover:(tcp://broker:61616) ? UIMA AS client does not recover correctly when the connection to a broker fails --- Key: UIMA-1643 URL: https://issues.apache.org/jira/browse/UIMA-1643 Project: UIMA Issue Type: Bug Components: Async Scaleout Reporter: Jerry Cwiklik Priority: Blocker Fix For: 2.3AS When the connection to the broker is lost, the UIMA AS client does not attempt to reconnect as it is done in the UIMA AS service. When the jms send() fails due to a lost connection, the UIMA AS client notifies the application but in addition should log a single message that the connection was lost and enter a recovery loop attempting to reconnect at regular intervals. Any failures during this recovery should be silently handled. If the application does not want to recover from a bad connection it should call stop() on the client API which will stop the recovery, cleanup resources and terminate the UIMA AS client. -- 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-1643) UIMA AS client does not recover correctly when the connection to a broker fails
Jaroslaw Cwiklik wrote: Initially this is exactly what I thought of doing. But we need finer level of control. Dont want to be stuck in the AMQ send method until the broker becomes available. Instead the code will silently retry connection indefinitely similar to Spring Listener's waitUntilSuccessfull() In our system we plan to use a Pure Master Slave ActiveMQ Broker. In the case the Master fails the clients just reconnect to the Slave. More information can be found here: http://activemq.apache.org/pure-master-slave.html The broker URL for this configuration looks like this: failover://(tcp://masterhost:61616,tcp://slavehost:61616)?randomize=false If the code retires to connect it must be able to detect that the broker is not available, maybe the send method just throws an exception, which is then handled. Does non-blocking sending in case of an error also work if failover is used ? Jörn
Re: [jira] Commented: (UIMA-1643) UIMA AS client does not recover correctly when the connection to a broker fails
As I understand it, when you use failover around the AMQ URL and the named broker(s) is/are not available, the send blocks. The latest AMQ release 5.3 has support for timeouts using this notation: failover:(tcp://primary:61616)?timeout=3000 This is a new release that I have not tried yet. Besides, we are releasing UIMA AS with AMQ 4.1.1 support and our code should be backwards compatible. Having said that, I had problems with correct failover behaviour with 4.1.1 while 5.2 worked fine. On Thu, Oct 29, 2009 at 2:26 PM, Jörn Kottmann kottm...@gmail.com wrote: Jaroslaw Cwiklik wrote: Initially this is exactly what I thought of doing. But we need finer level of control. Dont want to be stuck in the AMQ send method until the broker becomes available. Instead the code will silently retry connection indefinitely similar to Spring Listener's waitUntilSuccessfull() In our system we plan to use a Pure Master Slave ActiveMQ Broker. In the case the Master fails the clients just reconnect to the Slave. More information can be found here: http://activemq.apache.org/pure-master-slave.html The broker URL for this configuration looks like this: failover://(tcp://masterhost:61616,tcp://slavehost:61616)?randomize=false If the code retires to connect it must be able to detect that the broker is not available, maybe the send method just throws an exception, which is then handled. Does non-blocking sending in case of an error also work if failover is used ? Jörn
Re: [jira] Commented: (UIMA-1643) UIMA AS client does not recover correctly when the connection to a broker fails
Jaroslaw Cwiklik wrote: As I understand it, when you use failover around the AMQ URL and the named broker(s) is/are not available, the send blocks. The latest AMQ release 5.3 has support for timeouts using this notation: failover:(tcp://primary:61616)?timeout=3000 This is a new release that I have not tried yet. Besides, we are releasing UIMA AS with AMQ 4.1.1 support and our code should be backwards compatible. Having said that, I had problems with correct failover behaviour with 4.1.1 while 5.2 worked fine. Ok, we use 5.3, so I will just add the timeout to the client (when this issue is closed) and deployment descriptor. Thanks, Jörn
