Re: [VOTE] Release UIMA 2.3.0 RC9 as UIMA 2.3.0 incubating
On 1/11/2010 17:18, Marshall Schor wrote: [ ] +1 Release RC9, it's ready [ ] -1 Don't release yet because of these issues which need to be addressed first: ... +1 --Thilo --Marshall
Re: [VOTE] Release UIMA 2.3.0 RC9 as UIMA 2.3.0 incubating
Hi, On Mon, Jan 11, 2010 at 5:18 PM, Marshall Schor m...@schor.com wrote: Please vote on approving this release. This vote is for all 4 components, together. [x] +1 Release RC9, it's ready Though I should note that the build process is still notoriously complex. It would be really nice if the whole release could be built with a single command form the base directory of the release package. This would help lower the entry barrier for new users. Also, when asking the rest of the IPMC to approve the release, it would be helpful to point out the scripts used to generate the release packages as otherwise the difference between the release packages and the svn tag is quite confusing. For the record, the SHA1 checksums of the source packages I reviewed are: 304599fdc4e057332933ad3718787def6b6b896d uima-as-2.3.0-incubating-src.tar.gz 4e2619ee411f918c00727ae1349723ca9e49b26c uimacpp-2.3.0-incubating-src.tgz 86ceec36ea4dba104ea54236ced68f710b9ef68a uimaj-2.3.0-incubating-src.tar.gz 7d97114531422a1908460f53a02bfb5721a9b9b1 uimaj-annotator-addons-2.3.0-incubating-src.tar.gz BR, Jukka Zitting
Re: [VOTE] Release UIMA 2.3.0 RC9 as UIMA 2.3.0 incubating
Jukka Zitting wrote: Hi, On Mon, Jan 11, 2010 at 5:18 PM, Marshall Schor m...@schor.com wrote: Please vote on approving this release. This vote is for all 4 components, together. [x] +1 Release RC9, it's ready Though I should note that the build process is still notoriously complex. It would be really nice if the whole release could be built with a single command form the base directory of the release package. This would help lower the entry barrier for new users. Thanks, Jukka, good critique. I think this should be a high priority work item for the next release. Also, when asking the rest of the IPMC to approve the release, it would be helpful to point out the scripts used to generate the release packages as otherwise the difference between the release packages and the svn tag is quite confusing. Right, will do. You're speaking of, in particular, the source release package, I presume (not the binary ones), right? -Marshall For the record, the SHA1 checksums of the source packages I reviewed are: 304599fdc4e057332933ad3718787def6b6b896d uima-as-2.3.0-incubating-src.tar.gz 4e2619ee411f918c00727ae1349723ca9e49b26c uimacpp-2.3.0-incubating-src.tgz 86ceec36ea4dba104ea54236ced68f710b9ef68a uimaj-2.3.0-incubating-src.tar.gz 7d97114531422a1908460f53a02bfb5721a9b9b1 uimaj-annotator-addons-2.3.0-incubating-src.tar.gz BR, Jukka Zitting
Re: [VOTE] Release UIMA 2.3.0 RC9 as UIMA 2.3.0 incubating
Hi, On Tue, Jan 12, 2010 at 1:55 PM, Marshall Schor m...@schor.com wrote: Right, will do. You're speaking of, in particular, the source release package, I presume (not the binary ones), right? Correct. BR, Jukka Zitting
release simplification
I'd like to learn more about the recommended simple release processes that Apache projects use. Can those on this list who are familiar with other Apache project, reply with some information and details on what they consider to be the better versions of these simple release processes? Thanks! -Marshall
Why isn't UIMA AS using the JMS message expiration feature ?
Hello, I noticed that messages sent from the client to the service can pill up in the queue in the case the service is not available e.g. down for an update. In the case the client uses a timeout it should also set the JMS message expiration to the timeout, then the broker can remove old messages Should I open a jira for this ? Jörn
Re: Why isn't UIMA AS using the JMS message expiration feature ?
Jorn, the UIMA AS client adds the TTL to each outgoing message as long as
you have the process timeout set. Currently, the UIMA AS client uses the
following logic when adding TTL:
// get process timeout value
long timeoutValue = cacheEntry.getProcessTimeout();
if (timeoutValue 0 addTimeToLive ) {
// Set high time to live value
message.setJMSExpiration(10 * timeoutValue);
}
In the above, addTimeToLive is true by default. The expiration time should
probably be parametrized. :)
Check AMQ forums and you'll see that there are quite a few postings about
TTL logic. If I am not mistaken, the expired messages are not removed until
you connect a consumer to the queue. Try to restart the consumer to see if
the messages disappear. Are the clocks on two machines different?
JC
On Tue, Jan 12, 2010 at 10:00 AM, Jörn Kottmann kottm...@gmail.com wrote:
Hello,
I noticed that messages sent from the client
to the service can pill up in the queue in the
case the service is not available e.g. down for an
update.
In the case the client uses a timeout it should also
set the JMS message expiration to the timeout,
then the broker can remove old messages
Should I open a jira for this ?
Jörn
