Re: pear packaging maven plugin documentation question
Marshall Schor wrote: > The current docs for the pear packaging maven plugin say that you need > to make your project depend on the plugin, by adding it to the > dependency set of your project that is using it. > > I don't think this is correct. I think that the maven plugin tools are > specified separately from the project dependencies. So, it should not > be required to add anything to a project's dependency set for this. > Instead, you would just need to include it in the ... > section. > > Is this right? > Test it by removing the dependency from a sandbox project - it built just fine. So I think this is correct. I'll update the doc. -Marshall > -Marshall > > >
Re: generics: additionalParams
Jörn Kottmann wrote: Marshall Schor wrote: Jörn Kottmann wrote: The additionalParams Map has a String key and can contains all kinds of Objects, so the correct generification would be Map. In the uima code base I found one invocation where a Properties object was passed as additionalParams. Properties is a Map which will cause compile errors in user code when they use a Properties object to pass in the additional params. I don't think its common practice to use Properties for additional params. If we fix the one found use cited above, are there any other cases where instances of Properties are passed as additionalParams in our own code? What do we think is the likelyhood that users will use Properties as instances of additional params? Our documentation says "See the Javadocs" for info on the additional parameters. The Javadocs say this is a Map ... Valid parameter names are defined as constants on the XYZ Interface ... and in that interface, these constants are Strings. But users might decide to represent these parameters in a properties file. Here are some considerations (apologies if I get this wrong - please correct): - If we declare as , then you cannot assign a Map to the parameter. - Having the key of the map be an Object is more general, and would accommodate Properties. - declaring as - cannot assign "new Properties()" to it any more, unless you do the double-fisted cast (Map)(Object) If that is the trade off, I think I would rather have it be . +1 from me for Map If there are no objections I would like to start with the change to get it done before our 28th deadline. Jörn
Re: release 2.3.0 plan
One way we have to ensure that the uima core generification is correct is to use our API with generics, thats why I would like to suggest to move our release a few days and use the time to convert existing code outside of the core. That could be done after the code freeze. Jörn Marshall Schor wrote: I'd like to freeze in 3 weeks, if that is reasonable. For all of you with code that you want to have in the release, is 3 weeks (Aug 28 - a Friday) too soon to freeze (stop developing, and see if we can cut a release candidate)? This means: coding of any new things is done, tests written, and everything runs/builds documentation is done As part of the release process, after we do a release candidate, we'll ask everyone to help in testing it. During that time, no new feature work please, just work on getting the candidate into shape to release (fixing bugs). Things that are not ready will be postponed to the next release. Please respond with a +1 if you think you can wrap up any work needed in 3 weeks, and a -1 if you think the release point should be delayed because of something you believe strongly should make this release. See this wiki page for info on the release plan: http://cwiki.apache.org/confluence/display/UIMA/ReleasePlan2.3.0 Thanks to everyone for help in getting this out! -Marshall (volunteering as the release manager this time around)
[jira] Created: (UIMA-1501) more refactoring and updating - parent POMs
more refactoring and updating - parent POMs --- Key: UIMA-1501 URL: https://issues.apache.org/jira/browse/UIMA-1501 Project: UIMA Issue Type: Improvement Components: Build, Packaging and Test Reporter: Marshall Schor Priority: Minor use pluginManagement and dependencyManagement to refactor additional items. Update to javadoc plugin 2.5 (the current level - what the superPom specifies). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: generics: additionalParams
+1 Marshall Jörn Kottmann wrote: > Jörn Kottmann wrote: >> Marshall Schor wrote: >>> Jörn Kottmann wrote: >>> The additionalParams Map has a String key and can contains all kinds of Objects, so the correct generification would be Map. In the uima code base I found one invocation where a Properties object was passed as additionalParams. Properties is a Map which will cause compile errors in user code when they use a Properties object to pass in the additional params. I don't think its common practice to use Properties for additional params. >>> >>> If we fix the one found use cited above, are there any other cases >>> where >>> instances of Properties are passed as additionalParams in our own code? >>> What do we think is the likelyhood that users will use Properties as >>> instances of additional params? >>> Our documentation says "See the Javadocs" for info on the additional >>> parameters. The Javadocs say this is a Map ... Valid parameter names >>> are defined as constants on the XYZ Interface ... and in that >>> interface, >>> these constants are Strings. >>> >>> But users might decide to represent these parameters in a properties >>> file. >>> >>> Here are some considerations (apologies if I get this wrong - please >>> correct): >>> - If we declare as , then you cannot assign a >>> Map to the parameter. >>> - Having the key of the map be an Object is more general, and would >>> accommodate Properties. >>> - declaring as - cannot assign "new Properties()" to >>> it any more, unless you do the double-fisted cast >>> (Map)(Object) >>> >>> If that is the trade off, I think I would rather have it be >> Object>. >>> >> +1 from me for Map > If there are no objections I would like to start with the change > to get it done before our 28th deadline. > > Jörn >
Re: release 2.3.0 plan
+1 I'm for doing testing of the new generification because of the difficulty of doing this correctly... -Marshall Jörn Kottmann wrote: > One way we have to ensure that the uima core generification is > correct is to use our API with generics, thats why I would like to > suggest > to move our release a few days and use the time to convert existing > code outside of the core. That could be done after the code freeze. > > Jörn > > Marshall Schor wrote: >> I'd like to freeze in 3 weeks, if that is reasonable. For all of you >> with code that you want to have in the release, is 3 weeks (Aug 28 - a >> Friday) too soon to freeze (stop developing, and see if we can cut a >> release candidate)? >> >> This means: >> coding of any new things is done, tests written, and everything >> runs/builds >> documentation is done >> >> As part of the release process, after we do a release candidate, we'll >> ask everyone to help in testing it. During that time, no new feature >> work please, just work on getting the candidate into shape to release >> (fixing bugs). >> >> Things that are not ready will be postponed to the next release. >> >> Please respond with a +1 if you think you can wrap up any work needed in >> 3 weeks, and a -1 if you think the release point should be delayed >> because of something you believe strongly should make this release. >> >> See this wiki page for info on the release plan: >> http://cwiki.apache.org/confluence/display/UIMA/ReleasePlan2.3.0 >> >> Thanks to everyone for help in getting this out! >> >> -Marshall (volunteering as the release manager this time around) >> > > >
[jira] Created: (UIMA-1502) Using getSofaDataStream instead of getDocumentText
Using getSofaDataStream instead of getDocumentText -- Key: UIMA-1502 URL: https://issues.apache.org/jira/browse/UIMA-1502 Project: UIMA Issue Type: Improvement Components: Sandbox-WhitespaceTokenizer Reporter: Jérôme Rocheteau Priority: Minor I would like to known if it could be better to get the CAS text content by calling the getSofaDataStream method of the CAS class instead of getting it by the getDocumentText one. Actually, CAS sofas can be set either by calling the setSofaDataString method (aka setDocumentText), or by calling the setSofaDataArray one, or by calling the setSofaDataURI one. However, the getDocumentText method (aka getSofaDataString) provides the content of CASes whose sofas are only set by the first method whereas the getSofaDataStream method retieves content whatever the called method. A method able to get String from an InputStream is then needed. Am I wrong in thinking it's an Improvement? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: release 2.3.0 plan
Marshall Schor wrote: +1 I'm for doing testing of the new generification because of the difficulty of doing this correctly... -Marshall What kind of testing do think of ? Jörn
[jira] Updated: (UIMA-1502) Using getSofaDataStream instead of getDocumentText
[ https://issues.apache.org/jira/browse/UIMA-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jérôme Rocheteau updated UIMA-1502: --- Attachment: wst.patch This is a patch that makes possible to use the Whitespace tokenizer whatever the way sofas are set through collection readers. > Using getSofaDataStream instead of getDocumentText > -- > > Key: UIMA-1502 > URL: https://issues.apache.org/jira/browse/UIMA-1502 > Project: UIMA > Issue Type: Improvement > Components: Sandbox-WhitespaceTokenizer >Reporter: Jérôme Rocheteau >Priority: Minor > Attachments: wst.patch > > Original Estimate: 0.17h > Remaining Estimate: 0.17h > > I would like to known if it could be better to get the CAS text content by > calling the getSofaDataStream method of the CAS class instead of getting it > by the getDocumentText one. > Actually, CAS sofas can be set either by calling the setSofaDataString method > (aka setDocumentText), or by calling the setSofaDataArray one, or by calling > the setSofaDataURI one. However, the getDocumentText method (aka > getSofaDataString) provides the content of CASes whose sofas are only set by > the first method whereas the getSofaDataStream method retieves content > whatever the called method. A method able to get String from an InputStream > is then needed. > Am I wrong in thinking it's an Improvement? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1503) after 2.3.0 release - tasks
after 2.3.0 release - tasks --- Key: UIMA-1503 URL: https://issues.apache.org/jira/browse/UIMA-1503 Project: UIMA Issue Type: Task Reporter: Marshall Schor Priority: Minor Tasks to do after 2.3.0 release (edit as needed to keep this as an active reminder): - update website to include pointer to maven plugin for pear packager -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1503) right after 2.3.0 release - tasks
[ https://issues.apache.org/jira/browse/UIMA-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-1503: - Description: Tasks to do right after 2.3.0 release (edit as needed to keep this as an active reminder): - update website to include pointer to maven plugin for pear packager was: Tasks to do after 2.3.0 release (edit as needed to keep this as an active reminder): - update website to include pointer to maven plugin for pear packager Summary: right after 2.3.0 release - tasks (was: after 2.3.0 release - tasks) > right after 2.3.0 release - tasks > - > > Key: UIMA-1503 > URL: https://issues.apache.org/jira/browse/UIMA-1503 > Project: UIMA > Issue Type: Task >Reporter: Marshall Schor >Priority: Minor > > Tasks to do right after 2.3.0 release (edit as needed to keep this as an > active reminder): > - update website to include pointer to maven plugin for pear packager -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1503) right after 2.3.0 release - tasks
[ https://issues.apache.org/jira/browse/UIMA-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-1503: - Description: Tasks to do right after 2.3.0 release (edit as needed to keep this as an active reminder): - update website to include pointer to maven plugin for pear packager - verify pearPackagerMavenPlugin is in incubator repo and works was: Tasks to do right after 2.3.0 release (edit as needed to keep this as an active reminder): - update website to include pointer to maven plugin for pear packager > right after 2.3.0 release - tasks > - > > Key: UIMA-1503 > URL: https://issues.apache.org/jira/browse/UIMA-1503 > Project: UIMA > Issue Type: Task >Reporter: Marshall Schor >Priority: Minor > > Tasks to do right after 2.3.0 release (edit as needed to keep this as an > active reminder): > - update website to include pointer to maven plugin for pear packager > - verify pearPackagerMavenPlugin is in incubator repo and works -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1497) change build for pear packaging maven plugin
[ https://issues.apache.org/jira/browse/UIMA-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-1497. Resolution: Fixed verification of maven plugin promotion into repo has to wait until we do the release. > change build for pear packaging maven plugin > > > Key: UIMA-1497 > URL: https://issues.apache.org/jira/browse/UIMA-1497 > Project: UIMA > Issue Type: Task > Components: Build, Packaging and Test >Affects Versions: 2.2.2 >Reporter: Marshall Schor >Assignee: Marshall Schor > Fix For: 2.3 > > > Per discussion on uima-dev here: http://markmail.org/thread/5oqscqtwpfnrd53a > the uima pear packaging maven plugin should be changed to enable it to be > "published" as a component to the incubator maven repository. Currently it > is packaged as a part of the sandbox build. > Tasks to accomplish this: > 1) move in SVN out of the sandbox to a new project under the svn "uimaj" > node. > 2) change documentation to indicate it is not a "sandbox" component, but a > full-fledged component. > 3) integrate into uima-docbooks > 4) change build - make part of base uima build. Verify this promotes it to > the incubator maven repository -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1297) Uima AS Service Not Handling Send Failures Correctly
[ https://issues.apache.org/jira/browse/UIMA-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Burn Lewis updated UIMA-1297: - Attachment: uimaj-as-activemq_1297.patch Two of the JUnit test descriptors need to be modified to ignore the new ForcedMessageTimeoutException > Uima AS Service Not Handling Send Failures Correctly > > > Key: UIMA-1297 > URL: https://issues.apache.org/jira/browse/UIMA-1297 > Project: UIMA > Issue Type: Bug > Components: Async Scaleout >Reporter: Jerry Cwiklik >Assignee: Jerry Cwiklik > Attachments: uimaj-as-activemq_1297.patch > > > When a send requst fails due to a lost broker connection, the uima AS > aggregate removes the CAS from the outstanding list. Subsequently, when a > timer pops the Timeout Exception is reported against the wrong CAS. > Fix the code so that the CAS remains in the outstanding list until the timer > pops. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1358) Exceptions on generated CASes are returned to client without parentage information
[ https://issues.apache.org/jira/browse/UIMA-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Burn Lewis updated UIMA-1358: - Attachment: uimaj-as-activemq_1358.patch Yes, works fine now. This patch adds code to the test driver to test if any exceptions come back associated with a child CAS. Also named some of the test threads, and moved some of the "fail" calls so they occur after the service has been shutdown (otherwise test hangs on failure) > Exceptions on generated CASes are returned to client without parentage > information > -- > > Key: UIMA-1358 > URL: https://issues.apache.org/jira/browse/UIMA-1358 > Project: UIMA > Issue Type: Bug > Components: Async Scaleout >Affects Versions: 2.2.2 >Reporter: Burn Lewis >Assignee: Burn Lewis > Fix For: 2.3S > > Attachments: uimaj-as-activemq_1358.patch > > > The client should be told which of its input CASes might have (indirectly) > generated this failing CAS. Also is there any value in sending more than one > exception if many children fail? If the aggregate is not a CM then the > client should just be told that the input CAS failed. > Here is part of a recent email discussion on this problem: > I think I have a somewhat clearer picture of how we might handle errors on > child CASes. > First consider Primitive & Aggregate CMs, and then a non-CM aggregate that > contains a CM. > I can see 3 different ways an application may wish to handle errors on child > CASes: > Primitive CM > Stop generating children/descendants of the input CAS and return an exception > on the input CAS > Generate an "incomplete" CAS -- perhaps marked as "damaged" > (useful when the total count must be preserved and a place-holder provided) > Ignore the error, generate no CAS and carry on to generate the next CAS (if > any) > Aggregate CM > Stop generating any more children/descendants from the input CAS and return > the exception on the input CAS > Allow the CAS to continue in the flow > Quietly drop the CAS, do not return it and do not generate an exception > Simple Aggregate with internal CM > Stop generating any more children/descendants from the input CAS and return > the exception on the input CAS > Allow the CAS to continue in the flow (it will be dropped at the end of the > flow) > Quietly drop the CAS as if it reached the end of the flow, and do not > generate an exception > Currently our aggregate error-handling supports #2, while #3 doesn't depend > on the framework. I have added aggregate support for #3 to the > AdvancedFixedFlowController in the UIMA-AS test suite (as part of Jira 1353) > in the form of a new AllowDropOnFailure option which specifies the delegates > for which a failing CAS can be dropped, i.e. skip to the end of the flow with > the forceCasToBeDropped flag set. (I used it to test the thresholdWindow > error handling to verify that an intermittently failing delegate is disabled > when N of the last M CASes fail.) > But I don't think our docs indicate what should happen in #1 and the current > implementation handles it differently ... the exception is associated with > the child CAS without any reference to the input CAS, and the CM continues to > generate children, so the client can get many exceptions that refer to > unknown CASes. The getParentCasReferenceId() method in the > UimaASProcessStatus (which I could not find in the JavaDocs) can be used to > associate a child CAS with the input CAS that generated it, but it is always > null when an exception is returned. > Consider the information available to the entityProcessComplete callback when > an input CAS successfully generates 2 children: > returnedCAS getCasReferenceId() getParentCasReferenceId() > isException() > > Child1 ID-of-Child1ID-of-Parent > false > Child2 ID-of-Child2ID-of-Parent > false > Parent ID-of-Parentnull > false > If the 2nd child causes an exception then the client might see (Option > A) > returnedCAS getCasReferenceId() getParentCasReferenceId() > isException() > > Child1 ID-of-Child1ID-of-Parent > false > nullID-of-Parentnull > true > Or we could put the failing child's ID in the status (Option B) > returnedCAS getCasReferenceId() getParentCasReferenceId() > isException() > > Child1 ID-of-Child1ID-of-Parent > false > nullID-of-Child2ID-of-Parent > true >
[jira] Created: (UIMA-1504) Generify the additionalParams Map through the uimaj-core codebase
Generify the additionalParams Map through the uimaj-core codebase - Key: UIMA-1504 URL: https://issues.apache.org/jira/browse/UIMA-1504 Project: UIMA Issue Type: Improvement Components: Core Java Framework Reporter: Jörn Kottmann Assignee: Jörn Kottmann Fix For: 2.3 The additionalParams Map has a String key and can contains all kinds of Objects, so the correct generification would be Map. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
generics: AnalysisComponent.getRequiredCasInterface();
Is that the correct generification? Class getRequiredCasInterface(); Implementing classes can then specify the concrete return type. For example: Class JCasAnnotator_ImplBase.getRequiredCasInterface() Class CasAnnotator_ImplBase.getRequiredCasInterface() Jörn
generics: ResourceFactory.produceResource
The current declaration with out generics: public Resource produceResource(Class aResourceClass, ResourceSpecifier aSpecifier, Map aAdditionalParams) throws ResourceInitializationException; Can it be assumed that aResourceClass is always a class which extends Resource, if so it could be declared as Class. There are many places where aResourceClass occurs, we should handle them all identical. Jörn
possibly including the BSFAnnotator in the sandbox release 2.3.0
While working on including the BSFAnnotator in the sandbox release, I noticed it has 6 jar files in its "lib" directory. The NOTICE file says that the project includes some components under MPL and SPL; however, the information needed to associate each of this included 3rd-party jar files with the proper license is missing. Can someone who knows identify the source of the following jars: bsf.jar bsh-bsf.jar bsh.jar commons-logging-api-1.1.jar js.jar log4j-1.2.15.jar I typed bsf.jar into google and got to the Apache Jakarta site. I downloaded and unzipped their release, and found the jars are different - I suspect, due to version / level changes. Do we need to update/upgrade any of these Jars? Is there a better way to package / distribute this in binary form? Also, I noticed that the POM section for building the documentation is commented out - because there is no docbook style documentation. The documentation seems limited to a README and some examples. Is there additional documentation available for this? -Marshall
Re: generics: AnalysisComponent.getRequiredCasInterface();
Jörn Kottmann wrote:
> Is that the correct generification?
> Class getRequiredCasInterface();
>
> Implementing classes can then specify the concrete return
> type.
>
> For example:
> Class JCasAnnotator_ImplBase.getRequiredCasInterface()
> Class CasAnnotator_ImplBase.getRequiredCasInterface()
I tried:
public static void tgrci(AnalysisComponent ac) {
Class x = ac.getRequiredCasInterface();
}
but it doesn't work, gives error:
// error, cannot convert from Class
to Class
This is with the interface AnalysisComponent defining
getRequiredCasInterface as:
Class getRequiredCasInterface();
This works:
public static void tgrci(AnalysisComponent ac) {
Class x = ac.getRequiredCasInterface();
}
and this works too:
public static void tgrci(AnalysisComponent ac) {
Class x = ((JCasAnnotator_ImplBase)ac).getRequiredCasInterface();
}
So, I think we have the correct generification in the interface
AnalysisComponent, of return .
-Marshall.
> Jörn
>
>
>
[jira] Commented: (UIMA-1502) Using getSofaDataStream instead of getDocumentText
[ https://issues.apache.org/jira/browse/UIMA-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12745170#action_12745170 ] Marshall Schor commented on UIMA-1502: -- This approach has trade-offs. On the plus side, it provides a more uniform method of handling various kinds of input. On the minus side, for the very common case where the subject of analysis is the text in the CAS's sofa, it would introduce considerable inefficiencies. When the CAS has had some text set into it as the subject-of-analysis, it is stored as a Java string. If you now ask the Cas for an inputstream using getSofaDataStream - it has to take the string and convert it into an array of bytes, using the UTF-8 character encoding. This byte array is then wrapped into an input stream. Your patch now takes this and reads it (by mistake, in the "default" character encoding - it should be UTF-8), with various new buffers assigned. It also could be changing the manner in which new lines are encoded. Since the string is already available, this seems like quite a poor approach. I'm also not convinced that there is a real use-case which needs this kind of unification. > Using getSofaDataStream instead of getDocumentText > -- > > Key: UIMA-1502 > URL: https://issues.apache.org/jira/browse/UIMA-1502 > Project: UIMA > Issue Type: Improvement > Components: Sandbox-WhitespaceTokenizer >Reporter: Jérôme Rocheteau >Priority: Minor > Attachments: wst.patch > > Original Estimate: 0.17h > Remaining Estimate: 0.17h > > I would like to known if it could be better to get the CAS text content by > calling the getSofaDataStream method of the CAS class instead of getting it > by the getDocumentText one. > Actually, CAS sofas can be set either by calling the setSofaDataString method > (aka setDocumentText), or by calling the setSofaDataArray one, or by calling > the setSofaDataURI one. However, the getDocumentText method (aka > getSofaDataString) provides the content of CASes whose sofas are only set by > the first method whereas the getSofaDataStream method retieves content > whatever the called method. A method able to get String from an InputStream > is then needed. > Am I wrong in thinking it's an Improvement? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: generics: ResourceFactory.produceResource
On Wed, Aug 19, 2009 at 1:54 PM, Jörn Kottmann wrote: > The current declaration with out generics: > > public Resource produceResource(Class aResourceClass, ResourceSpecifier > aSpecifier, > Map aAdditionalParams) throws > ResourceInitializationException; > > Can it be assumed that aResourceClass is always a class which extends > Resource, > if so it could be declared as Class. > Yes, I think that is right. -Adam
[jira] Reopened: (UIMA-1433) UIMA AS service creates too many JMS connections
[ https://issues.apache.org/jira/browse/UIMA-1433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Cwiklik reopened UIMA-1433: - OutputChannel is not caching JMS connections properly leaving stale connections in a broker. > UIMA AS service creates too many JMS connections > - > > Key: UIMA-1433 > URL: https://issues.apache.org/jira/browse/UIMA-1433 > Project: UIMA > Issue Type: Bug > Components: Async Scaleout >Reporter: Jerry Cwiklik >Assignee: Jerry Cwiklik > > UIMA AS service maintains connections to client's reply queue. These > connections are cached and reused. When the connection becomes idle for too > long, it is closed. Current default connection timeout is set to 30 minutes. > This value can be changed via System property -DSessionTimeoutOverride=n. > JMS Connections are expensive, and if too many are created the broker may > become unstable. As optimization, the service should create a single JMS > connection (per broker) and use it to create jms sessions and message > producers for each client. This change will reduce number of threads the > broker needs to manage in deployments where clients and services use a single > broker for messaging. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1433) UIMA AS service creates too many JMS connections
[ https://issues.apache.org/jira/browse/UIMA-1433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Cwiklik closed UIMA-1433. --- Resolution: Fixed Modified JmsEndpointConnection_impl openChannel() method to check if connection exists in the cache before creating a new one. > UIMA AS service creates too many JMS connections > - > > Key: UIMA-1433 > URL: https://issues.apache.org/jira/browse/UIMA-1433 > Project: UIMA > Issue Type: Bug > Components: Async Scaleout >Reporter: Jerry Cwiklik >Assignee: Jerry Cwiklik > > UIMA AS service maintains connections to client's reply queue. These > connections are cached and reused. When the connection becomes idle for too > long, it is closed. Current default connection timeout is set to 30 minutes. > This value can be changed via System property -DSessionTimeoutOverride=n. > JMS Connections are expensive, and if too many are created the broker may > become unstable. As optimization, the service should create a single JMS > connection (per broker) and use it to create jms sessions and message > producers for each client. This change will reduce number of threads the > broker needs to manage in deployments where clients and services use a single > broker for messaging. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
