[jira] [Commented] (FINERACT-982) Completely ditch use of Drizzle JDBC Driver after all
[ https://issues.apache.org/jira/browse/FINERACT-982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17205986#comment-17205986 ] Yemdjih Kaze Nasser commented on FINERACT-982: -- (y) > Completely ditch use of Drizzle JDBC Driver after all > - > > Key: FINERACT-982 > URL: https://issues.apache.org/jira/browse/FINERACT-982 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Michael Vorburger >Assignee: Yemdjih Kaze Nasser >Priority: Major > Labels: scalability > > Fineract's use of the un-maintained Drizzle JDBC driver continues to cause > confusion and pains like FINERACT-980, and note e.g. the proposed removal of > the alternative MySQL JDBC driver in > [https://github.com/apache/fineract/pull/887.] > Some of the background to this is recorded e.g. in FINCN-26, FINERACT-761 and > LEGAL-462. > LEGAL-462 has clarified that the Fineract ZIP distribution must include > Drizzle and cannot distribute the MariaDB or MySQL JDBC clients. We CAN, and > currently (given the confusion in FINERACT-980 apparently do?!) use it for > tests. > What if to reduce variability we just removed that old Drizzle JDBC driver > after all? We could run our tests using (preferably) the very well maintained > MariaDB JDBC driver client (the actual DB server is a totally separate > discussion, see FINERACT-896). We would (have to) distribute the ZIP for > download without a JDBC driver, and just some documentation inviting users to > DL and add one. > But the exact situation about distributing in a Docker container image isn't > clear, to me... > FYI [~awasum], [~ptuomola], [~xurror] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-1125) Integrate Alternative Reporting tool for Fineract 1.x without Apache License violations
[ https://issues.apache.org/jira/browse/FINERACT-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17205836#comment-17205836 ] James Dailey commented on FINERACT-1125: BIRT, by the way is a Category B in Apache. [https://apache.org/legal/resolved.html]. Cat B needs to be included only as binary. I think we should avoid this at Apache Fineract. It would complicate matters. > Integrate Alternative Reporting tool for Fineract 1.x without Apache License > violations > --- > > Key: FINERACT-1125 > URL: https://issues.apache.org/jira/browse/FINERACT-1125 > Project: Apache Fineract > Issue Type: Improvement > Components: Build >Affects Versions: 1.4.0 >Reporter: Francis Guchie >Priority: Major > Labels: hard > > read here [https://github.com/apache/fineract/pull/1262] > and > [https://www.apache.org/legal/resolved.html#category-x] > and > [https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License] > We need a reporting support that will not have licensing violations > for example the following > h1. BIRT > [https://www.eclipse.org/birt/about/] their license details are > [https://en.wikipedia.org/wiki/Eclipse_Public_License] > h1. KNIME > [|https://www.knime.com/downloads/full-license] > [https://www.knime.com/knime-report-designer > |https://www.knime.com/knime-report-designer]their licence details are > [https://www.knime.com/downloads/full-license] > h1. METABASE > [https://www.metabase.com/] and their license is > [https://www.metabase.com/license/] > h1. SEAL REPORT > [https://sealreport.org/] and their License is > [https://sealreport.org/#lineRequirements] > [https://www.spagobi.org/] and their license is > [https://www.spagobi.org/communities/license/] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-1125) Integrate Alternative Reporting tool for Fineract 1.x without Apache License violations
[ https://issues.apache.org/jira/browse/FINERACT-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17205805#comment-17205805 ] Michael Vorburger commented on FINERACT-1125: - FYI people watching this issue, FINERACT-1127 is now progressing re. how we can use Pentaho with Fineract. > Integrate Alternative Reporting tool for Fineract 1.x without Apache License > violations > --- > > Key: FINERACT-1125 > URL: https://issues.apache.org/jira/browse/FINERACT-1125 > Project: Apache Fineract > Issue Type: Improvement > Components: Build >Affects Versions: 1.4.0 >Reporter: Francis Guchie >Priority: Major > Labels: hard > > read here [https://github.com/apache/fineract/pull/1262] > and > [https://www.apache.org/legal/resolved.html#category-x] > and > [https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License] > We need a reporting support that will not have licensing violations > for example the following > h1. BIRT > [https://www.eclipse.org/birt/about/] their license details are > [https://en.wikipedia.org/wiki/Eclipse_Public_License] > h1. KNIME > [|https://www.knime.com/downloads/full-license] > [https://www.knime.com/knime-report-designer > |https://www.knime.com/knime-report-designer]their licence details are > [https://www.knime.com/downloads/full-license] > h1. METABASE > [https://www.metabase.com/] and their license is > [https://www.metabase.com/license/] > h1. SEAL REPORT > [https://sealreport.org/] and their License is > [https://sealreport.org/#lineRequirements] > [https://www.spagobi.org/] and their license is > [https://www.spagobi.org/communities/license/] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-1170) Automated Load Testing scenarios & tooling
[ https://issues.apache.org/jira/browse/FINERACT-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17205798#comment-17205798 ] James Dailey commented on FINERACT-1170: When looking at this, I want to also focus on maintainability. 1) It needs to be "integrated" in the build (CI) and be triggered at the appropriate times. If not, then I think we agree, it won't be used and if not used, then not maintained. 2) We should use a toolset with a future path. I have found something that can convert Postman collections to JMeter. [https://github.com/fangls/postman2jmx]. MIT License. (Which is a category A type license and so compatible) 3) We should start small with something very accessible to a group of devs that may be new to this. or If a group has already built something and can please contribute that code, then we could start with that. > Automated Load Testing scenarios & tooling > -- > > Key: FINERACT-1170 > URL: https://issues.apache.org/jira/browse/FINERACT-1170 > Project: Apache Fineract > Issue Type: New Feature >Reporter: Michael Vorburger >Priority: Blocker > Labels: scalability > > During [ApacheCon @Home Sep 29 - Oct 1, > 2020|https://apachecon.com/acah2020/index.html], in a number of [sessions on > the Fineract track|https://apachecon.com/acah2020/tracks/fineract.html], > including: > * the BOFs, > * the "[To Infinity and Beyond: Scaling Fineract for the > Enterprise|https://docs.google.com/document/d/18pdICOm8jEZN5VI7MuHJK_jLO2UCu_NJMYivm0QAQOo/edit]; > panel > * the "[Running > Fineract.dev|https://docs.google.com/presentation/d/1-VP4bNkc5kZ3B0yme_vYLiY1qpswnfz8ainnX5fp3l8/]; > presentation > We have spoken about Fineract scalability ideas, and possible next steps. > We have identified that what we require most as a community to progress on > Fineract scalability (see [our JIRA issues with 'scalability' > label|https://issues.apache.org/jira/issues/?jql=labels%20%3D%20scalability%20and%20project%20%3D%22Apache%20Fineract%22%20]) > is a Automated Load Testing scenarios & tooling. > Tools suitable to build this include [JMeter|https://jmeter.apache.org], > [Gatling.io|https://gatling.io], perhaps even simply > [Postman|https://www.postman.com/] with > [Newman|https://github.com/postmanlabs/newman]. > We would, ideally, like for this to eventually run in our CI. > FYI [~avikg] ([~avikganguly]? [~avikganguly010]?), [~vromero] > ([~Fintecheando]?), [~aleks], [~edcable], [~jdailey] ([~jamespdailey]), > Istvan not on JIRA? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-982) Completely ditch use of Drizzle JDBC Driver after all
[ https://issues.apache.org/jira/browse/FINERACT-982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17205790#comment-17205790 ] Michael Vorburger commented on FINERACT-982: [~kaze]I would keep it simpler.. just entirely remove Drizzle - completely. Then make sure that Unit and Integration Tests run with [https://mariadb.com/kb/en/about-mariadb-connector-j/] ... BUT never include that JAR in the Fineract JAR/WAR distribution - it has always be test scope only, and added to the the classpath for tests. For end-users, the README doc has to clarify how to separately download and add the JAR. > Completely ditch use of Drizzle JDBC Driver after all > - > > Key: FINERACT-982 > URL: https://issues.apache.org/jira/browse/FINERACT-982 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Michael Vorburger >Assignee: Yemdjih Kaze Nasser >Priority: Major > Labels: scalability > > Fineract's use of the un-maintained Drizzle JDBC driver continues to cause > confusion and pains like FINERACT-980, and note e.g. the proposed removal of > the alternative MySQL JDBC driver in > [https://github.com/apache/fineract/pull/887.] > Some of the background to this is recorded e.g. in FINCN-26, FINERACT-761 and > LEGAL-462. > LEGAL-462 has clarified that the Fineract ZIP distribution must include > Drizzle and cannot distribute the MariaDB or MySQL JDBC clients. We CAN, and > currently (given the confusion in FINERACT-980 apparently do?!) use it for > tests. > What if to reduce variability we just removed that old Drizzle JDBC driver > after all? We could run our tests using (preferably) the very well maintained > MariaDB JDBC driver client (the actual DB server is a totally separate > discussion, see FINERACT-896). We would (have to) distribute the ZIP for > download without a JDBC driver, and just some documentation inviting users to > DL and add one. > But the exact situation about distributing in a Docker container image isn't > clear, to me... > FYI [~awasum], [~ptuomola], [~xurror] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FINERACT-834) documenting Swagger use on README
[ https://issues.apache.org/jira/browse/FINERACT-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Vorburger updated FINERACT-834: --- Summary: documenting Swagger use on README (was: Minor quick win: Please raise very small PR documenting Swagger use on README) > documenting Swagger use on README > - > > Key: FINERACT-834 > URL: https://issues.apache.org/jira/browse/FINERACT-834 > Project: Apache Fineract > Issue Type: Improvement >Affects Versions: 1.2.0, 1.3.0, 1.4.0 >Reporter: Michael Vorburger >Assignee: Manthan Surkar >Priority: Trivial > Labels: beginner, documentation, swagger > Fix For: 1.5.0 > > > Based on some of the discussion in > https://github.com/apache/fineract/pull/629 (which got superseded by > https://github.com/apache/fineract/pull/695), I think it would be very useful > to have a short line (or a or two paragraph, max) in > https://github.com/apache/fineract/blob/develop/README.md#apache-fineract-platform-api > which simply explains how one actually may currently use the Swagger UI, as > it currently is. > I will just be completely honest and admit that personally I do not actually > know how! ;-) Is there a special URL one has to access? Does one need to > locally install anything? > [~kangbreder] would you like to do this? Please do raise 1 small PR with ONLY > this README change. > [~awasum] [~sanyam] ([~sanyam96] ?) FYI -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (FINERACT-877) Release Apache Fineract v1.3.1
[ https://issues.apache.org/jira/browse/FINERACT-877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Vorburger reopened FINERACT-877: > Release Apache Fineract v1.3.1 > -- > > Key: FINERACT-877 > URL: https://issues.apache.org/jira/browse/FINERACT-877 > Project: Apache Fineract > Issue Type: Bug >Reporter: Michael Vorburger >Assignee: Michael Vorburger >Priority: Major > Fix For: 1.5.0 > > > In JIRA, there is a 1.3.1 version, but it was never released. > I doubt a 1.3.1 will be released (anyone?) - if anything, a 1.4.0, see > FINERACT-873. > There were 3 issues marked Fixed Version 1.3.1 today: FINERACT-755, and > FINERACT-848 & FINERACT-832. The latter two have no PRs and so certainly > never were for 1.3.1, the Report must have just not known which Fix Version > to set; so I've just removed 1.3.1 from those two. > The FINERACT-755 is more interesting - I don't fully understand yet is that > is also in develop, or not. > Shall we delete the 1.3.1 version in JIRA? And in git, after clarifying > FINERACT-755 ? > [~vishwasbabu] [~angelboxes] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (FINERACT-877) Release Apache Fineract v1.3.1
[ https://issues.apache.org/jira/browse/FINERACT-877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Vorburger resolved FINERACT-877. Resolution: Won't Fix > Release Apache Fineract v1.3.1 > -- > > Key: FINERACT-877 > URL: https://issues.apache.org/jira/browse/FINERACT-877 > Project: Apache Fineract > Issue Type: Bug >Reporter: Michael Vorburger >Assignee: Michael Vorburger >Priority: Major > Fix For: 1.5.0 > > > In JIRA, there is a 1.3.1 version, but it was never released. > I doubt a 1.3.1 will be released (anyone?) - if anything, a 1.4.0, see > FINERACT-873. > There were 3 issues marked Fixed Version 1.3.1 today: FINERACT-755, and > FINERACT-848 & FINERACT-832. The latter two have no PRs and so certainly > never were for 1.3.1, the Report must have just not known which Fix Version > to set; so I've just removed 1.3.1 from those two. > The FINERACT-755 is more interesting - I don't fully understand yet is that > is also in develop, or not. > Shall we delete the 1.3.1 version in JIRA? And in git, after clarifying > FINERACT-755 ? > [~vishwasbabu] [~angelboxes] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-877) Release Apache Fineract v1.3.1
[ https://issues.apache.org/jira/browse/FINERACT-877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17205775#comment-17205775 ] Michael Vorburger commented on FINERACT-877: With 1.4.0 out of the way, this doesn't make sense anymore, so closing as WONTFIX now. FINERACT-1154 clarifies something more general about our branching strategy. > Release Apache Fineract v1.3.1 > -- > > Key: FINERACT-877 > URL: https://issues.apache.org/jira/browse/FINERACT-877 > Project: Apache Fineract > Issue Type: Bug >Reporter: Michael Vorburger >Assignee: Michael Vorburger >Priority: Major > Fix For: 1.5.0 > > > In JIRA, there is a 1.3.1 version, but it was never released. > I doubt a 1.3.1 will be released (anyone?) - if anything, a 1.4.0, see > FINERACT-873. > There were 3 issues marked Fixed Version 1.3.1 today: FINERACT-755, and > FINERACT-848 & FINERACT-832. The latter two have no PRs and so certainly > never were for 1.3.1, the Report must have just not known which Fix Version > to set; so I've just removed 1.3.1 from those two. > The FINERACT-755 is more interesting - I don't fully understand yet is that > is also in develop, or not. > Shall we delete the 1.3.1 version in JIRA? And in git, after clarifying > FINERACT-755 ? > [~vishwasbabu] [~angelboxes] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (FINERACT-877) Release Apache Fineract v1.3.1
[ https://issues.apache.org/jira/browse/FINERACT-877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Vorburger resolved FINERACT-877. Resolution: Fixed > Release Apache Fineract v1.3.1 > -- > > Key: FINERACT-877 > URL: https://issues.apache.org/jira/browse/FINERACT-877 > Project: Apache Fineract > Issue Type: Bug >Reporter: Michael Vorburger >Assignee: Michael Vorburger >Priority: Major > Fix For: 1.5.0 > > > In JIRA, there is a 1.3.1 version, but it was never released. > I doubt a 1.3.1 will be released (anyone?) - if anything, a 1.4.0, see > FINERACT-873. > There were 3 issues marked Fixed Version 1.3.1 today: FINERACT-755, and > FINERACT-848 & FINERACT-832. The latter two have no PRs and so certainly > never were for 1.3.1, the Report must have just not known which Fix Version > to set; so I've just removed 1.3.1 from those two. > The FINERACT-755 is more interesting - I don't fully understand yet is that > is also in develop, or not. > Shall we delete the 1.3.1 version in JIRA? And in git, after clarifying > FINERACT-755 ? > [~vishwasbabu] [~angelboxes] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FINERACT-877) Release Apache Fineract v1.3.1
[ https://issues.apache.org/jira/browse/FINERACT-877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Vorburger updated FINERACT-877: --- Fix Version/s: 1.5.0 > Release Apache Fineract v1.3.1 > -- > > Key: FINERACT-877 > URL: https://issues.apache.org/jira/browse/FINERACT-877 > Project: Apache Fineract > Issue Type: Bug >Reporter: Michael Vorburger >Assignee: Michael Vorburger >Priority: Major > Fix For: 1.5.0 > > > In JIRA, there is a 1.3.1 version, but it was never released. > I doubt a 1.3.1 will be released (anyone?) - if anything, a 1.4.0, see > FINERACT-873. > There were 3 issues marked Fixed Version 1.3.1 today: FINERACT-755, and > FINERACT-848 & FINERACT-832. The latter two have no PRs and so certainly > never were for 1.3.1, the Report must have just not known which Fix Version > to set; so I've just removed 1.3.1 from those two. > The FINERACT-755 is more interesting - I don't fully understand yet is that > is also in develop, or not. > Shall we delete the 1.3.1 version in JIRA? And in git, after clarifying > FINERACT-755 ? > [~vishwasbabu] [~angelboxes] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-1145) OAuth Support documentation is missing
[
https://issues.apache.org/jira/browse/FINERACT-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17205773#comment-17205773
]
Michael Vorburger commented on FINERACT-1145:
-
https://github.com/apache/fineract/blob/develop/docs/deployment/oauth.md
> OAuth Support documentation is missing
> ---
>
> Key: FINERACT-1145
> URL: https://issues.apache.org/jira/browse/FINERACT-1145
> Project: Apache Fineract
> Issue Type: Bug
> Components: Security
>Reporter: Michael Vorburger
>Assignee: Michael Vorburger
>Priority: Major
> Fix For: 1.5.0
>
>
> We have a number of open issues related to apparent OAuth support in Fineract.
> There is 0 documentation available on the Apache Fineract project [Git
> repo|https://github.com/apache/fineract/search?q=oauth_q=oauth] or
> [Wiki|https://cwiki.apache.org/confluence/dosearchsite.action?cql=siteSearch+~+%22oauth%22+and+space+%3D+%22FINERACT%22+and+type+in+(%22space%22%2C%22user%22%2C%22page%22%2C%22blogpost%22%2C%22attachment%22%2C%22com.atlassian.confluence.plugins.confluence-mail-archiving%3Amail%22)=oauth].
> (One can "deduct" that it can be activated by
> {{{color:#22}_-Psecurity=oauth_{color}}} at build - but then what?)
> IMHO it would be valuable both for end users deployment, integrators and new
> and old contributors to the project to have this feature documented.
> So the goal of this issue is to have comprehensive documentation about
> Fineract's OAuth support in
> [https://github.com/apache/fineract/tree/develop/docs/deployment/security.md].
> This feature may be (apparently?) actually currently be broken on the develop
> branch as of today (and in 1.4.0), see FINERACT-1144, but that shouldn't
> someone from contribution documentation of how it should work. That
> documentation should be able to be followed e.g. on 1.2.0 or 1.3.0 (but I
> think that's broken due to FINERACT-755, so build 1.3.1 from git).
> [~saransh] or [~aleks] or [~avikganguly010] or [~josenavarro] would any of
> you like to contribute such documentation to this wonderful project?
> PS: Once there is documentation, someone could then build an IT - that's
> unlocking FINERACT-1143.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (FINERACT-1145) OAuth Support documentation is missing
[
https://issues.apache.org/jira/browse/FINERACT-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vorburger resolved FINERACT-1145.
-
Resolution: Fixed
> OAuth Support documentation is missing
> ---
>
> Key: FINERACT-1145
> URL: https://issues.apache.org/jira/browse/FINERACT-1145
> Project: Apache Fineract
> Issue Type: Bug
> Components: Security
>Reporter: Michael Vorburger
>Assignee: Michael Vorburger
>Priority: Major
> Fix For: 1.5.0
>
>
> We have a number of open issues related to apparent OAuth support in Fineract.
> There is 0 documentation available on the Apache Fineract project [Git
> repo|https://github.com/apache/fineract/search?q=oauth_q=oauth] or
> [Wiki|https://cwiki.apache.org/confluence/dosearchsite.action?cql=siteSearch+~+%22oauth%22+and+space+%3D+%22FINERACT%22+and+type+in+(%22space%22%2C%22user%22%2C%22page%22%2C%22blogpost%22%2C%22attachment%22%2C%22com.atlassian.confluence.plugins.confluence-mail-archiving%3Amail%22)=oauth].
> (One can "deduct" that it can be activated by
> {{{color:#22}_-Psecurity=oauth_{color}}} at build - but then what?)
> IMHO it would be valuable both for end users deployment, integrators and new
> and old contributors to the project to have this feature documented.
> So the goal of this issue is to have comprehensive documentation about
> Fineract's OAuth support in
> [https://github.com/apache/fineract/tree/develop/docs/deployment/security.md].
> This feature may be (apparently?) actually currently be broken on the develop
> branch as of today (and in 1.4.0), see FINERACT-1144, but that shouldn't
> someone from contribution documentation of how it should work. That
> documentation should be able to be followed e.g. on 1.2.0 or 1.3.0 (but I
> think that's broken due to FINERACT-755, so build 1.3.1 from git).
> [~saransh] or [~aleks] or [~avikganguly010] or [~josenavarro] would any of
> you like to contribute such documentation to this wonderful project?
> PS: Once there is documentation, someone could then build an IT - that's
> unlocking FINERACT-1143.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FINERACT-1170) Automated Load Testing scenarios & tooling
[ https://issues.apache.org/jira/browse/FINERACT-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Vorburger updated FINERACT-1170: Priority: Blocker (was: Major) > Automated Load Testing scenarios & tooling > -- > > Key: FINERACT-1170 > URL: https://issues.apache.org/jira/browse/FINERACT-1170 > Project: Apache Fineract > Issue Type: New Feature >Reporter: Michael Vorburger >Priority: Blocker > Labels: scalability > > During [ApacheCon @Home Sep 29 - Oct 1, > 2020|https://apachecon.com/acah2020/index.html], in a number of [sessions on > the Fineract track|https://apachecon.com/acah2020/tracks/fineract.html], > including: > * the BOFs, > * the "[To Infinity and Beyond: Scaling Fineract for the > Enterprise|https://docs.google.com/document/d/18pdICOm8jEZN5VI7MuHJK_jLO2UCu_NJMYivm0QAQOo/edit]; > panel > * the "[Running > Fineract.dev|https://docs.google.com/presentation/d/1-VP4bNkc5kZ3B0yme_vYLiY1qpswnfz8ainnX5fp3l8/]; > presentation > We have spoken about Fineract scalability ideas, and possible next steps. > We have identified that what we require most as a community to progress on > Fineract scalability (see [our JIRA issues with 'scalability' > label|https://issues.apache.org/jira/issues/?jql=labels%20%3D%20scalability%20and%20project%20%3D%22Apache%20Fineract%22%20]) > is a Automated Load Testing scenarios & tooling. > Tools suitable to build this include [JMeter|https://jmeter.apache.org], > [Gatling.io|https://gatling.io], perhaps even simply > [Postman|https://www.postman.com/] with > [Newman|https://github.com/postmanlabs/newman]. > We would, ideally, like for this to eventually run in our CI. > FYI [~avikg] ([~avikganguly]? [~avikganguly010]?), [~vromero] > ([~Fintecheando]?), [~aleks], [~edcable], [~jdailey] ([~jamespdailey]), > Istvan not on JIRA? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-982) Completely ditch use of Drizzle JDBC Driver after all
[ https://issues.apache.org/jira/browse/FINERACT-982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17205765#comment-17205765 ] Yemdjih Kaze Nasser commented on FINERACT-982: -- This is a good place where we could leverage multiple application profiles. I suggest we reinstate the production and development profiles separation. I could look into that. > Completely ditch use of Drizzle JDBC Driver after all > - > > Key: FINERACT-982 > URL: https://issues.apache.org/jira/browse/FINERACT-982 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Michael Vorburger >Assignee: Yemdjih Kaze Nasser >Priority: Major > Labels: scalability > > Fineract's use of the un-maintained Drizzle JDBC driver continues to cause > confusion and pains like FINERACT-980, and note e.g. the proposed removal of > the alternative MySQL JDBC driver in > [https://github.com/apache/fineract/pull/887.] > Some of the background to this is recorded e.g. in FINCN-26, FINERACT-761 and > LEGAL-462. > LEGAL-462 has clarified that the Fineract ZIP distribution must include > Drizzle and cannot distribute the MariaDB or MySQL JDBC clients. We CAN, and > currently (given the confusion in FINERACT-980 apparently do?!) use it for > tests. > What if to reduce variability we just removed that old Drizzle JDBC driver > after all? We could run our tests using (preferably) the very well maintained > MariaDB JDBC driver client (the actual DB server is a totally separate > discussion, see FINERACT-896). We would (have to) distribute the ZIP for > download without a JDBC driver, and just some documentation inviting users to > DL and add one. > But the exact situation about distributing in a Docker container image isn't > clear, to me... > FYI [~awasum], [~ptuomola], [~xurror] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (FINERACT-982) Completely ditch use of Drizzle JDBC Driver after all
[ https://issues.apache.org/jira/browse/FINERACT-982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yemdjih Kaze Nasser reassigned FINERACT-982: Assignee: Yemdjih Kaze Nasser > Completely ditch use of Drizzle JDBC Driver after all > - > > Key: FINERACT-982 > URL: https://issues.apache.org/jira/browse/FINERACT-982 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Michael Vorburger >Assignee: Yemdjih Kaze Nasser >Priority: Major > Labels: scalability > > Fineract's use of the un-maintained Drizzle JDBC driver continues to cause > confusion and pains like FINERACT-980, and note e.g. the proposed removal of > the alternative MySQL JDBC driver in > [https://github.com/apache/fineract/pull/887.] > Some of the background to this is recorded e.g. in FINCN-26, FINERACT-761 and > LEGAL-462. > LEGAL-462 has clarified that the Fineract ZIP distribution must include > Drizzle and cannot distribute the MariaDB or MySQL JDBC clients. We CAN, and > currently (given the confusion in FINERACT-980 apparently do?!) use it for > tests. > What if to reduce variability we just removed that old Drizzle JDBC driver > after all? We could run our tests using (preferably) the very well maintained > MariaDB JDBC driver client (the actual DB server is a totally separate > discussion, see FINERACT-896). We would (have to) distribute the ZIP for > download without a JDBC driver, and just some documentation inviting users to > DL and add one. > But the exact situation about distributing in a Docker container image isn't > clear, to me... > FYI [~awasum], [~ptuomola], [~xurror] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-867) Scalability & Performance Enhancements for Supporting Millions of Clients, High TPS, and Concurrent Users
[ https://issues.apache.org/jira/browse/FINERACT-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17205757#comment-17205757 ] Michael Vorburger commented on FINERACT-867: see FINERACT-1170 - IMHO that's really the most important / useful next step here. > Scalability & Performance Enhancements for Supporting Millions of Clients, > High TPS, and Concurrent Users > - > > Key: FINERACT-867 > URL: https://issues.apache.org/jira/browse/FINERACT-867 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Sanyam Goel >Priority: Major > Labels: gsoc, gsoc2020, scalability, technical > > |*Overview & Objectives* > As Mifos X has matured as a core banking platform, it's been adopted and used > by larger institutions serving hundreds of thousands and even millions of > clients. Partners operating cloud-hosted subscription models are also > supporting hundreds of thousands of clients across their multi-tenant > installations. Most recently, more and more digital-first fintechs are using > the platforms for highly scalable wallet accounts needing hundreds and > thousands of TPS. We need to benchmark, analyze and improve the performance > and scalability of the system.| > |*Description* > Enhancements to the back-end platform will include parallelization of all the > jobs with a configurable amount of concurrency, look at the explain plans of > the queries being used in the jobs, paginate input queries for jobs, put lazy > fetching where required, node-aware scheduler and cache, office-wise > configurable jobs to distribute job-load across servers and write some tests > to prove that the concurrency will work for a decent amount of scale. > In addition, you'll provide some metrics which can help mid-sized MFIs (those > having around a million active loans) in adopting Mifos X. > | > |*Helpful Skills* > Java, Javascript, Spring, JAX-RS, JPA,| > |*Impact* > Higher outreach to the unbanked by supporting larger institutions and scaling > more rapidly.| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FINERACT-1170) Automated Load Testing scenarios & tooling
Michael Vorburger created FINERACT-1170: --- Summary: Automated Load Testing scenarios & tooling Key: FINERACT-1170 URL: https://issues.apache.org/jira/browse/FINERACT-1170 Project: Apache Fineract Issue Type: New Feature Reporter: Michael Vorburger During [ApacheCon @Home Sep 29 - Oct 1, 2020|https://apachecon.com/acah2020/index.html], in a number of [sessions on the Fineract track|https://apachecon.com/acah2020/tracks/fineract.html], including: * the BOFs, * the "[To Infinity and Beyond: Scaling Fineract for the Enterprise|https://docs.google.com/document/d/18pdICOm8jEZN5VI7MuHJK_jLO2UCu_NJMYivm0QAQOo/edit]; panel * the "[Running Fineract.dev|https://docs.google.com/presentation/d/1-VP4bNkc5kZ3B0yme_vYLiY1qpswnfz8ainnX5fp3l8/]; presentation We have spoken about Fineract scalability ideas, and possible next steps. We have identified that what we require most as a community to progress on Fineract scalability (see [our JIRA issues with 'scalability' label|https://issues.apache.org/jira/issues/?jql=labels%20%3D%20scalability%20and%20project%20%3D%22Apache%20Fineract%22%20]) is a Automated Load Testing scenarios & tooling. Tools suitable to build this include [JMeter|https://jmeter.apache.org], [Gatling.io|https://gatling.io], perhaps even simply [Postman|https://www.postman.com/] with [Newman|https://github.com/postmanlabs/newman]. We would, ideally, like for this to eventually run in our CI. FYI [~avikg] ([~avikganguly]? [~avikganguly010]?), [~vromero] ([~Fintecheando]?), [~aleks], [~edcable], [~jdailey] ([~jamespdailey]), Istvan not on JIRA? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FINERACT-1170) Automated Load Testing scenarios & tooling
[ https://issues.apache.org/jira/browse/FINERACT-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Vorburger updated FINERACT-1170: Labels: scalability (was: ) > Automated Load Testing scenarios & tooling > -- > > Key: FINERACT-1170 > URL: https://issues.apache.org/jira/browse/FINERACT-1170 > Project: Apache Fineract > Issue Type: New Feature >Reporter: Michael Vorburger >Priority: Major > Labels: scalability > > During [ApacheCon @Home Sep 29 - Oct 1, > 2020|https://apachecon.com/acah2020/index.html], in a number of [sessions on > the Fineract track|https://apachecon.com/acah2020/tracks/fineract.html], > including: > * the BOFs, > * the "[To Infinity and Beyond: Scaling Fineract for the > Enterprise|https://docs.google.com/document/d/18pdICOm8jEZN5VI7MuHJK_jLO2UCu_NJMYivm0QAQOo/edit]; > panel > * the "[Running > Fineract.dev|https://docs.google.com/presentation/d/1-VP4bNkc5kZ3B0yme_vYLiY1qpswnfz8ainnX5fp3l8/]; > presentation > We have spoken about Fineract scalability ideas, and possible next steps. > We have identified that what we require most as a community to progress on > Fineract scalability (see [our JIRA issues with 'scalability' > label|https://issues.apache.org/jira/issues/?jql=labels%20%3D%20scalability%20and%20project%20%3D%22Apache%20Fineract%22%20]) > is a Automated Load Testing scenarios & tooling. > Tools suitable to build this include [JMeter|https://jmeter.apache.org], > [Gatling.io|https://gatling.io], perhaps even simply > [Postman|https://www.postman.com/] with > [Newman|https://github.com/postmanlabs/newman]. > We would, ideally, like for this to eventually run in our CI. > FYI [~avikg] ([~avikganguly]? [~avikganguly010]?), [~vromero] > ([~Fintecheando]?), [~aleks], [~edcable], [~jdailey] ([~jamespdailey]), > Istvan not on JIRA? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FINERACT-912) Tune JPA Eager/Lazy loading for performance
[ https://issues.apache.org/jira/browse/FINERACT-912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Vorburger updated FINERACT-912: --- Labels: scalability (was: ) > Tune JPA Eager/Lazy loading for performance > --- > > Key: FINERACT-912 > URL: https://issues.apache.org/jira/browse/FINERACT-912 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Michael Vorburger >Priority: Major > Labels: scalability > > as part of the overall FINERACT-867, tuning JPA Eager/Lazy loading for > performance is always fun. > FINERACT-902 is worth reading re. this topic. The goal of this issue would > be to: > 1. measure numbers of SQL queries per API call > 2. measure the time of each such query, on "full" (non-demo) real database > 3. see if throwing in a few more fetch=FetchType.LAZY annotation at the right > place can help > 4. use more fine grained per operation Fetch Plans instead annotations, based > on measues -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FINERACT-426) Filter to optionally compress response with gzip
[
https://issues.apache.org/jira/browse/FINERACT-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vorburger updated FINERACT-426:
---
Labels: easyfix gsoc newbie p2 scalability (was: easyfix gsoc newbie p2
performance scalability)
> Filter to optionally compress response with gzip
>
>
> Key: FINERACT-426
> URL: https://issues.apache.org/jira/browse/FINERACT-426
> Project: Apache Fineract
> Issue Type: Improvement
>Reporter: Avik Ganguly
>Assignee: Avik Ganguly
>Priority: Minor
> Labels: easyfix, gsoc, newbie, p2, scalability
> Fix For: 1.3.0
>
>
> Accept a query parameter like isCompressionRequired. If this query param is
> present, compress the response using gzip. This will ensure less bandwidth
> usage if field apps are using mobile data.
> Sample Code for response filter :-
> Inside filter method :-
> if
> (request.getRequestHeaders().getFirst(HttpHeaders.ACCEPT_ENCODING).contains("gzip"))
> {
>
> response.getHttpHeaders().add(HttpHeaders.CONTENT_ENCODING, "gzip");
> response.setContainerResponseWriter(
> new
> Adapter(response.getContainerResponseWriter()));
> }
> private static final class Adapter implements ContainerResponseWriter {
> private final ContainerResponseWriter crw;
> private GZIPOutputStream gos;
> Adapter(ContainerResponseWriter crw) {
> this.crw = crw;
> }
>
> public OutputStream writeStatusAndHeaders(long contentLength,
> ContainerResponse response) throws IOException {
>gos = new GZIPOutputStream(crw.writeStatusAndHeaders(-1,
> response));
>return gos;
> }
> public void finish() throws IOException {
> gos.finish();
> crw.finish();
> }
> }
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FINERACT-426) Filter to optionally compress response with gzip
[
https://issues.apache.org/jira/browse/FINERACT-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vorburger updated FINERACT-426:
---
Labels: easyfix gsoc newbie p2 performance scalability (was: easyfix gsoc
newbie p2 performance)
> Filter to optionally compress response with gzip
>
>
> Key: FINERACT-426
> URL: https://issues.apache.org/jira/browse/FINERACT-426
> Project: Apache Fineract
> Issue Type: Improvement
>Reporter: Avik Ganguly
>Assignee: Avik Ganguly
>Priority: Minor
> Labels: easyfix, gsoc, newbie, p2, performance, scalability
> Fix For: 1.3.0
>
>
> Accept a query parameter like isCompressionRequired. If this query param is
> present, compress the response using gzip. This will ensure less bandwidth
> usage if field apps are using mobile data.
> Sample Code for response filter :-
> Inside filter method :-
> if
> (request.getRequestHeaders().getFirst(HttpHeaders.ACCEPT_ENCODING).contains("gzip"))
> {
>
> response.getHttpHeaders().add(HttpHeaders.CONTENT_ENCODING, "gzip");
> response.setContainerResponseWriter(
> new
> Adapter(response.getContainerResponseWriter()));
> }
> private static final class Adapter implements ContainerResponseWriter {
> private final ContainerResponseWriter crw;
> private GZIPOutputStream gos;
> Adapter(ContainerResponseWriter crw) {
> this.crw = crw;
> }
>
> public OutputStream writeStatusAndHeaders(long contentLength,
> ContainerResponse response) throws IOException {
>gos = new GZIPOutputStream(crw.writeStatusAndHeaders(-1,
> response));
>return gos;
> }
> public void finish() throws IOException {
> gos.finish();
> crw.finish();
> }
> }
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FINERACT-425) Jobs configurable by loans / savings product and office.
[ https://issues.apache.org/jira/browse/FINERACT-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Vorburger updated FINERACT-425: --- Labels: features gsoc p2 scalability (was: features gsoc p2 performance) > Jobs configurable by loans / savings product and office. > > > Key: FINERACT-425 > URL: https://issues.apache.org/jira/browse/FINERACT-425 > Project: Apache Fineract > Issue Type: Improvement > Components: Organization >Reporter: Avik Ganguly >Priority: Major > Labels: features, gsoc, p2, scalability > Fix For: 1.5.0 > > > Allow saving key-value pairs against each job. Key populated in front-end can > be a free text field or an enum consisting of Loan Product / Savings Product > / Office. If pre-defined key is selected, populate corresponding list of > existing loan product / savings product / office in value field's dropdown. > The jobs can receive this key-value pair as a function parameter by setting > arguments on the jobDetailFactoryBean created in the function > createJobDetail(ScheduledJobDetail) in the class JobRegisterServiceImpl. > If the following jobs has above parameters passed to it, it should add > corresponding office/product filter where clause to its read query. > Add Accrual Transactions > Add Periodic Accrual Transactions > Add Accrual Transactions For Loans With Income Posted As Transactions > Generate Loan Loss Provisioning > Post Interest for Savings > Update Loan Summary > This feature can be made more useful with node-aware scheduler as different > nodes can be configured to perform the job for different products/offices > resulting in distribution of load. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FINERACT-127) Journal entry performance improvement
[
https://issues.apache.org/jira/browse/FINERACT-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vorburger updated FINERACT-127:
---
Labels: beginner scalability technical (was: beginner performance
technical)
> Journal entry performance improvement
> -
>
> Key: FINERACT-127
> URL: https://issues.apache.org/jira/browse/FINERACT-127
> Project: Apache Fineract
> Issue Type: Improvement
>Reporter: Emmanuel Nnaa
>Priority: Major
> Labels: beginner, scalability, technical
>
> The improvements will make the "accounting running balance update" job more
> efficient in handling the update of journal entries.
> If you reset the "is_running_balance_calculated" property to 0 for all
> journal entries, running the following SQL statement will update the running
> balances much faster than the "accounting running balance update" job:
> {code}
> SET @running_balance := 0;
> SET @account_id := 0;
> update acc_gl_journal_entry as je
> SET
> organization_running_balance = if(@account_id = je.account_id,
> @running_balance := @running_balance + IF(type_enum =
> 1, IF(je.account_id IN (SELECT id from acc_gl_account where `account_usage`
> IN (1,5)), amount * -1, amount), IF(je.account_id IN (SELECT id from
> acc_gl_account where `account_usage` IN (1,5)), amount, amount * -1)),
> @running_balance := IF(type_enum = 1, IF(je.account_id
> IN (SELECT id from acc_gl_account where `account_usage` IN (1,5)), amount *
> -1, amount), IF(je.account_id IN (SELECT id from acc_gl_account where
> `account_usage` IN (1,5)), amount, amount * -1))),
> account_id = IF(@account_id <> je.account_id,
> @account_id:=account_id, account_id)
> order by account_id, entry_date, id;
> COMMIT;
> UNLOCK TABLES;
> SET @running_balance := 0;
> SET @account_id := 0;
> SET @office_id := 0;
> UPDATE acc_gl_journal_entry as je SET office_running_balance =
> if( @office_id = je.office_id AND @account_id = je.account_id,
> @running_balance := @running_balance + IF(type_enum = 1, IF(je.account_id IN
> (SELECT id from acc_gl_account where `account_usage` IN (1,5)), amount * -1,
> amount), IF(je.account_id IN (SELECT id from acc_gl_account where
> `account_usage` IN (1,5)), amount, amount * -1)),
> @running_balance := IF(type_enum = 1, IF(je.account_id IN (SELECT id from
> acc_gl_account where `account_usage` IN (1,5)), amount * -1, amount),
> IF(je.account_id IN (SELECT id from acc_gl_account where `account_usage` IN
> (1,5)), amount, amount * -1))),
> account_id = IF(@account_id <> je.account_id, @account_id:=account_id,
> account_id),
> office_id = IF(@office_id <> je.office_id, @office_id:=office_id, office_id)
> order by office_id, account_id, entry_date, id;
> COMMIT;
> update acc_gl_journal_entry set is_running_balance_calculated = 1;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FINERACT-72) Speed up the retrieval of journal entries when "transactionDetails" is set to true
[ https://issues.apache.org/jira/browse/FINERACT-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Vorburger updated FINERACT-72: -- Labels: scalability (was: performance) > Speed up the retrieval of journal entries when "transactionDetails" is set to > true > -- > > Key: FINERACT-72 > URL: https://issues.apache.org/jira/browse/FINERACT-72 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Emmanuel Nnaa >Priority: Major > Labels: scalability > > It takes a little over 3 minutes to retrieve about 360 journal entries if the > "transactionDetails" parameter is set to true. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (FINERACT-426) Filter to optionally compress response with gzip
[
https://issues.apache.org/jira/browse/FINERACT-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vorburger resolved FINERACT-426.
Resolution: Fixed
> Filter to optionally compress response with gzip
>
>
> Key: FINERACT-426
> URL: https://issues.apache.org/jira/browse/FINERACT-426
> Project: Apache Fineract
> Issue Type: Improvement
>Reporter: Avik Ganguly
>Assignee: Avik Ganguly
>Priority: Minor
> Labels: easyfix, gsoc, newbie, p2, scalability
> Fix For: 1.3.0
>
>
> Accept a query parameter like isCompressionRequired. If this query param is
> present, compress the response using gzip. This will ensure less bandwidth
> usage if field apps are using mobile data.
> Sample Code for response filter :-
> Inside filter method :-
> if
> (request.getRequestHeaders().getFirst(HttpHeaders.ACCEPT_ENCODING).contains("gzip"))
> {
>
> response.getHttpHeaders().add(HttpHeaders.CONTENT_ENCODING, "gzip");
> response.setContainerResponseWriter(
> new
> Adapter(response.getContainerResponseWriter()));
> }
> private static final class Adapter implements ContainerResponseWriter {
> private final ContainerResponseWriter crw;
> private GZIPOutputStream gos;
> Adapter(ContainerResponseWriter crw) {
> this.crw = crw;
> }
>
> public OutputStream writeStatusAndHeaders(long contentLength,
> ContainerResponse response) throws IOException {
>gos = new GZIPOutputStream(crw.writeStatusAndHeaders(-1,
> response));
>return gos;
> }
> public void finish() throws IOException {
> gos.finish();
> crw.finish();
> }
> }
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FINERACT-427) Paginate input queries for jobs.
[ https://issues.apache.org/jira/browse/FINERACT-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Vorburger updated FINERACT-427: --- Labels: gsoc p2 scalability (was: gsoc p2 performance) > Paginate input queries for jobs. > > > Key: FINERACT-427 > URL: https://issues.apache.org/jira/browse/FINERACT-427 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Avik Ganguly >Priority: Minor > Labels: gsoc, p2, scalability > > Paginate read queries for following jobs : > Add Accrual Transactions > Add Periodic Accrual Transactions > Add Accrual Transactions For Loans With Income Posted As Transactions > Generate Loan Loss Provisioning > Post Interest for Savings > Update Loan Summary > Add arbitrary page size (32000) for now which can be later replaced by the > product of two configurations (batch size * thread count for that executor > service pool) when jobs are made concurrent. > If paginating the query outside can split a loan across pages, paginate the > primary entity, i.e. loans or savings. > Ex :- If accrual read query will fetch 3 rows for same loan (3 repayment > schedule entries for which accrual is pending) and page size is 2, loan will > get split across 2 pages. Avoid this by paginating the loan entity inside the > query. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FINERACT-762) Use of (unmaintained) Drizzle JDBC driver in Fineract at run-time (not build) is sub-optimal for performance
[ https://issues.apache.org/jira/browse/FINERACT-762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Vorburger updated FINERACT-762: --- Labels: scalability technical (was: performance technical) > Use of (unmaintained) Drizzle JDBC driver in Fineract at run-time (not build) > is sub-optimal for performance > > > Key: FINERACT-762 > URL: https://issues.apache.org/jira/browse/FINERACT-762 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Michael Vorburger >Assignee: Michael Vorburger >Priority: Major > Labels: scalability, technical > Fix For: 1.4.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Creating this issue to clarify that while FINERACT-761 is focused on (only) > the build time use of the Drizzle JDBC driver (which does not lead to it > being included in the final Fineract end-user distribution), this is re. the > use of it at run-time, which is packaged in the distribution. > The two uses are technically unrelated. While the use of Drizzle instead of > Connector/J in the build is a a blocking issue, the use at run-time is not a > blocking problem, currently. It's perhaps still not ideal to maintain on a > completely unmaintained library (Drizzle) for database access, e.g. for > performance. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FINERACT-428) Parallelization of Jobs
[
https://issues.apache.org/jira/browse/FINERACT-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vorburger updated FINERACT-428:
---
Labels: gsoc p2 scalability (was: gsoc p2 performance)
> Parallelization of Jobs
> ---
>
> Key: FINERACT-428
> URL: https://issues.apache.org/jira/browse/FINERACT-428
> Project: Apache Fineract
> Issue Type: Improvement
> Components: Loan, Savings
>Affects Versions: 1.1.0
>Reporter: Avik Ganguly
>Assignee: Shruthi M R
>Priority: Major
> Labels: gsoc, p2, scalability
> Fix For: 1.4.0
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> For starters, it will be useful to have some technical configuration added as
> job parameter for each of the below jobs, that is batch size and thread pool
> size for executor service so this has a dependency on FINERACT-425.
> Add migration script to add those 2 configurations to each of the following
> jobs with the value of batch size being 500 and thread pool size being 16 :-
> Add Accrual Transactions
> Add Periodic Accrual Transactions
> Add Accrual Transactions For Loans With Income Posted As Transactions
> Generate Loan Loss Provisioning
> Post Interest for Savings
> Update Loan Summary
> This would require separation of core functionality to a separate class.
> Simplified example :-
> ```
> final ExecutorService executor = Executors.newFixedThreadPool(threadPoolSize);
>
> final LocalDate dueDate = DateUtils.getLocalDateOfTenant();
> final Collection loansToBeRepaidData =
> this.loanReadPlatformService
> .retrieveLoansToBeRepaidFromAdvancePayment(dueDate);
> Iterable> loansToBeRepaid =
> Iterables.partition(loansToBeRepaidData, batchSize);
> final Authentication authentication =
> SecurityContextHolder.getContext().getAuthentication();
> List> advancePaymentPosters = new
> ArrayList>();
>
> for (List subList : loansToBeRepaid) {
> AdvancePaymentPoster poster = (AdvancePaymentPoster)
> this.applicationContext.getBean("advancePaymentPoster");
> poster.setLoans(subList);
> poster.setTenant(ThreadLocalContextUtil.getTenant());
> poster.setAuthentication(authentication);
> poster.setCommandService(commandService);
> advancePaymentPosters.add(Executors.callable(poster));
> }
> try {
> List> responses =
> executor.invokeAll(advancePaymentPosters);
> for(Future f : responses) {
> f.get();
> }
> } catch (InterruptedException e1) {
> e1.printStackTrace();
> }
>
> executor.shutdown();
> ```
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Reopened] (FINERACT-426) Filter to optionally compress response with gzip
[
https://issues.apache.org/jira/browse/FINERACT-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vorburger reopened FINERACT-426:
> Filter to optionally compress response with gzip
>
>
> Key: FINERACT-426
> URL: https://issues.apache.org/jira/browse/FINERACT-426
> Project: Apache Fineract
> Issue Type: Improvement
>Reporter: Avik Ganguly
>Assignee: Avik Ganguly
>Priority: Minor
> Labels: easyfix, gsoc, newbie, p2, performance
> Fix For: 1.3.0
>
>
> Accept a query parameter like isCompressionRequired. If this query param is
> present, compress the response using gzip. This will ensure less bandwidth
> usage if field apps are using mobile data.
> Sample Code for response filter :-
> Inside filter method :-
> if
> (request.getRequestHeaders().getFirst(HttpHeaders.ACCEPT_ENCODING).contains("gzip"))
> {
>
> response.getHttpHeaders().add(HttpHeaders.CONTENT_ENCODING, "gzip");
> response.setContainerResponseWriter(
> new
> Adapter(response.getContainerResponseWriter()));
> }
> private static final class Adapter implements ContainerResponseWriter {
> private final ContainerResponseWriter crw;
> private GZIPOutputStream gos;
> Adapter(ContainerResponseWriter crw) {
> this.crw = crw;
> }
>
> public OutputStream writeStatusAndHeaders(long contentLength,
> ContainerResponse response) throws IOException {
>gos = new GZIPOutputStream(crw.writeStatusAndHeaders(-1,
> response));
>return gos;
> }
> public void finish() throws IOException {
> gos.finish();
> crw.finish();
> }
> }
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FINERACT-1114) Slow Query
[ https://issues.apache.org/jira/browse/FINERACT-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Vorburger updated FINERACT-1114: Labels: scalability (was: performance) > Slow Query > -- > > Key: FINERACT-1114 > URL: https://issues.apache.org/jira/browse/FINERACT-1114 > Project: Apache Fineract > Issue Type: Bug > Components: Performance > Environment: Server configuration is 16 vCPU, 64GB RAM and 250GB SSD > storage. > Mifos 17.07.01 setup has been done using AWS-AMI >Reporter: Roshan Ratnaweera >Priority: Critical > Labels: scalability > Attachments: Slow Query Loan Disbursement.sql, Slow Query Teller Cash > Management Transactions.sql > > > I am using the 17.07.01 version. Server configuration is *16 vCPU, 64GB RAM* > and SSD storage. There are maximum concurrent user count is 30 (from 15 > branches) > # Loan disbursement > # viewing the net amount of teller (Teller cash management) > Above two tasks are taking a long time to process. When a bunch of these two > tasks are running, server CPU are 100% utilized by relevant sql select > queries. > When the server is not going to normal status, I am killing frozen select > queries. Then suddenly the server is going back to normal. > I have noticed that these delayed two queries, read all transactions of > relevant users. I think, that is why it takes a long time to process. Are any > solutions available for this ? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FINERACT-854) Use prepared statements instead of string concatenated SQL everywhere
[
https://issues.apache.org/jira/browse/FINERACT-854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vorburger updated FINERACT-854:
---
Labels: beginner scalability security technical (was: beginner scalability
technical)
> Use prepared statements instead of string concatenated SQL everywhere
> -
>
> Key: FINERACT-854
> URL: https://issues.apache.org/jira/browse/FINERACT-854
> Project: Apache Fineract
> Issue Type: Improvement
> Components: Security
>Reporter: Michael Vorburger
>Assignee: Manthan Surkar
>Priority: Major
> Labels: beginner, scalability, security, technical
> Fix For: 1.5.0
>
>
> The Fineract code base in many places creates SQL statements through String
> concatenation. This is prone to SQL injection. This is mitigated by the use
> of helpers utilities such as
> {{org.apache.fineract.infrastructure.core.api.ApiParameterHelper.sqlEncodeString(String)}}
> and
> {{org.apache.fineract.infrastructure.security.utils.SQLInjectionValidator.validateSQLInput(String)}}
> but I opine that those are workarounds... the better solution, both for
> security and likely also helping with performance (at least a little bit,
> knowing how much would require measuring it...), would be to use JDBC
> prepared statements with '?' placeholders and passing all raw arguments,
> instead of embedding them in the query String.
> FINERACT-808 root cause analysis brought this up, and I'm about to raise a PR
> for FINERACT-808 which makes a start; the goal of this issue is to use the
> new {{org.apache.fineract.infrastructure.security.utils.SQLBuilder}}
> everywhere, and eventually be able to get completely rid of
> {{ApiParameterHelper}} and {{SQLInjectionValidator}}.
> This issue should also include work to scan the code base for places where
> SQL Strings are concatenated without even using the existing helpers.
> FINERACT-853 could potentially help with that.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FINERACT-854) Use prepared statements instead of string concatenated SQL everywhere
[
https://issues.apache.org/jira/browse/FINERACT-854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vorburger updated FINERACT-854:
---
Labels: beginner scalability technical (was: beginner performance
technical)
> Use prepared statements instead of string concatenated SQL everywhere
> -
>
> Key: FINERACT-854
> URL: https://issues.apache.org/jira/browse/FINERACT-854
> Project: Apache Fineract
> Issue Type: Improvement
> Components: Security
>Reporter: Michael Vorburger
>Assignee: Manthan Surkar
>Priority: Major
> Labels: beginner, scalability, technical
> Fix For: 1.5.0
>
>
> The Fineract code base in many places creates SQL statements through String
> concatenation. This is prone to SQL injection. This is mitigated by the use
> of helpers utilities such as
> {{org.apache.fineract.infrastructure.core.api.ApiParameterHelper.sqlEncodeString(String)}}
> and
> {{org.apache.fineract.infrastructure.security.utils.SQLInjectionValidator.validateSQLInput(String)}}
> but I opine that those are workarounds... the better solution, both for
> security and likely also helping with performance (at least a little bit,
> knowing how much would require measuring it...), would be to use JDBC
> prepared statements with '?' placeholders and passing all raw arguments,
> instead of embedding them in the query String.
> FINERACT-808 root cause analysis brought this up, and I'm about to raise a PR
> for FINERACT-808 which makes a start; the goal of this issue is to use the
> new {{org.apache.fineract.infrastructure.security.utils.SQLBuilder}}
> everywhere, and eventually be able to get completely rid of
> {{ApiParameterHelper}} and {{SQLInjectionValidator}}.
> This issue should also include work to scan the code base for places where
> SQL Strings are concatenated without even using the existing helpers.
> FINERACT-853 could potentially help with that.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FINERACT-982) Completely ditch use of Drizzle JDBC Driver after all
[ https://issues.apache.org/jira/browse/FINERACT-982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Vorburger updated FINERACT-982: --- Labels: scalability (was: performance) > Completely ditch use of Drizzle JDBC Driver after all > - > > Key: FINERACT-982 > URL: https://issues.apache.org/jira/browse/FINERACT-982 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Michael Vorburger >Priority: Major > Labels: scalability > > Fineract's use of the un-maintained Drizzle JDBC driver continues to cause > confusion and pains like FINERACT-980, and note e.g. the proposed removal of > the alternative MySQL JDBC driver in > [https://github.com/apache/fineract/pull/887.] > Some of the background to this is recorded e.g. in FINCN-26, FINERACT-761 and > LEGAL-462. > LEGAL-462 has clarified that the Fineract ZIP distribution must include > Drizzle and cannot distribute the MariaDB or MySQL JDBC clients. We CAN, and > currently (given the confusion in FINERACT-980 apparently do?!) use it for > tests. > What if to reduce variability we just removed that old Drizzle JDBC driver > after all? We could run our tests using (preferably) the very well maintained > MariaDB JDBC driver client (the actual DB server is a totally separate > discussion, see FINERACT-896). We would (have to) distribute the ZIP for > download without a JDBC driver, and just some documentation inviting users to > DL and add one. > But the exact situation about distributing in a Docker container image isn't > clear, to me... > FYI [~awasum], [~ptuomola], [~xurror] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FINERACT-890) Custom slf4j integrated logger for the (optional!) MySQL JDBC driver support in Fineract
[
https://issues.apache.org/jira/browse/FINERACT-890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vorburger updated FINERACT-890:
---
Labels: scalability technical (was: perfomance technical)
> Custom slf4j integrated logger for the (optional!) MySQL JDBC driver support
> in Fineract
>
>
> Key: FINERACT-890
> URL: https://issues.apache.org/jira/browse/FINERACT-890
> Project: Apache Fineract
> Issue Type: Improvement
>Reporter: Michael Vorburger
>Priority: Major
> Labels: scalability, technical
>
> While working on FINERACT-762, I've stumbled upon:
> {code}Caused by:
> com.zaxxer.hikari.pool.HikariPool$PoolInitializationException: Failed to
> initialize pool: Unable to load class for logger
> 'com.mysql.jdbc.log.StandardLogger'
> at
> com.zaxxer.hikari.pool.HikariPool.throwPoolInitializationException(HikariPool.java:589)
> at com.zaxxer.hikari.pool.HikariPool.checkFailFast(HikariPool.java:575)
> at com.zaxxer.hikari.pool.HikariPool.(HikariPool.java:115)
> at com.zaxxer.hikari.HikariDataSource.(HikariDataSource.java:81)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:203)
> ... 161 more
> Caused by: java.sql.SQLException: Unable to load class for logger
> 'com.mysql.jdbc.log.StandardLogger'
> at
> com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:129)
> at
> com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:97)
> at
> com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:89)
> at
> com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:63)
> at
> com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:73)
> at
> com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:85)
> at com.mysql.cj.jdbc.ConnectionImpl.(ConnectionImpl.java:452)
> at com.mysql.cj.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:246)
> at
> com.mysql.cj.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:197)
> at
> com.zaxxer.hikari.util.DriverDataSource.getConnection(DriverDataSource.java:138)
> at com.zaxxer.hikari.pool.PoolBase.newConnection(PoolBase.java:354)
> at com.zaxxer.hikari.pool.PoolBase.newPoolEntry(PoolBase.java:202)
> at
> com.zaxxer.hikari.pool.HikariPool.createPoolEntry(HikariPool.java:473)
> at com.zaxxer.hikari.pool.HikariPool.checkFailFast(HikariPool.java:554)
> ... 168 more
> Caused by: com.mysql.cj.exceptions.WrongArgumentException: Unable to load
> class for logger 'com.mysql.jdbc.log.StandardLogger'
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> com.mysql.cj.exceptions.ExceptionFactory.createException(ExceptionFactory.java:61)
> at
> com.mysql.cj.exceptions.ExceptionFactory.createException(ExceptionFactory.java:105)
> at com.mysql.cj.log.LogFactory.getLogger(LogFactory.java:77)
> at com.mysql.cj.CoreSession.(CoreSession.java:95)
> at com.mysql.cj.NativeSession.(NativeSession.java:131)
> at com.mysql.cj.jdbc.ConnectionImpl.(ConnectionImpl.java:402)
> ... 175 more
> Caused by: java.lang.ClassNotFoundException:
> com.mysql.cj.log.com.mysql.jdbc.log.StandardLogger
> at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at com.mysql.cj.log.LogFactory.getLogger(LogFactory.java:70)
> ... 178 more{code}
> This seems to be due to us setting the Hikari DataSource logger property to
> com.mysql.jdbc.log.StandardLogger, in both
> org.apache.fineract.infrastructure.core.service.TomcatJdbcDataSourcePerTenantService
> and META-INF/spring/hikariDataSource.xml.
> That classname seems to be wrong (outdated?), at least for the latest
> mysql-connector-java version
[jira] [Updated] (FINERACT-867) Scalability & Performance Enhancements for Supporting Millions of Clients, High TPS, and Concurrent Users
[ https://issues.apache.org/jira/browse/FINERACT-867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Vorburger updated FINERACT-867: --- Labels: gsoc gsoc2020 scalability technical (was: gsoc gsoc2020 perfomance technical) > Scalability & Performance Enhancements for Supporting Millions of Clients, > High TPS, and Concurrent Users > - > > Key: FINERACT-867 > URL: https://issues.apache.org/jira/browse/FINERACT-867 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Sanyam Goel >Priority: Major > Labels: gsoc, gsoc2020, scalability, technical > > |*Overview & Objectives* > As Mifos X has matured as a core banking platform, it's been adopted and used > by larger institutions serving hundreds of thousands and even millions of > clients. Partners operating cloud-hosted subscription models are also > supporting hundreds of thousands of clients across their multi-tenant > installations. Most recently, more and more digital-first fintechs are using > the platforms for highly scalable wallet accounts needing hundreds and > thousands of TPS. We need to benchmark, analyze and improve the performance > and scalability of the system.| > |*Description* > Enhancements to the back-end platform will include parallelization of all the > jobs with a configurable amount of concurrency, look at the explain plans of > the queries being used in the jobs, paginate input queries for jobs, put lazy > fetching where required, node-aware scheduler and cache, office-wise > configurable jobs to distribute job-load across servers and write some tests > to prove that the concurrency will work for a decent amount of scale. > In addition, you'll provide some metrics which can help mid-sized MFIs (those > having around a million active loans) in adopting Mifos X. > | > |*Helpful Skills* > Java, Javascript, Spring, JAX-RS, JPA,| > |*Impact* > Higher outreach to the unbanked by supporting larger institutions and scaling > more rapidly.| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FINERACT-982) Completely ditch use of Drizzle JDBC Driver after all
[ https://issues.apache.org/jira/browse/FINERACT-982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Vorburger updated FINERACT-982: --- Labels: performance (was: ) > Completely ditch use of Drizzle JDBC Driver after all > - > > Key: FINERACT-982 > URL: https://issues.apache.org/jira/browse/FINERACT-982 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Michael Vorburger >Priority: Major > Labels: performance > > Fineract's use of the un-maintained Drizzle JDBC driver continues to cause > confusion and pains like FINERACT-980, and note e.g. the proposed removal of > the alternative MySQL JDBC driver in > [https://github.com/apache/fineract/pull/887.] > Some of the background to this is recorded e.g. in FINCN-26, FINERACT-761 and > LEGAL-462. > LEGAL-462 has clarified that the Fineract ZIP distribution must include > Drizzle and cannot distribute the MariaDB or MySQL JDBC clients. We CAN, and > currently (given the confusion in FINERACT-980 apparently do?!) use it for > tests. > What if to reduce variability we just removed that old Drizzle JDBC driver > after all? We could run our tests using (preferably) the very well maintained > MariaDB JDBC driver client (the actual DB server is a totally separate > discussion, see FINERACT-896). We would (have to) distribute the ZIP for > download without a JDBC driver, and just some documentation inviting users to > DL and add one. > But the exact situation about distributing in a Docker container image isn't > clear, to me... > FYI [~awasum], [~ptuomola], [~xurror] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (FINERACT-1111) Fetch Credit Report from ThitsaWorks CB
[ https://issues.apache.org/jira/browse/FINERACT-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rahul Pawar reassigned FINERACT-: - Assignee: Rahul Pawar > Fetch Credit Report from ThitsaWorks CB > --- > > Key: FINERACT- > URL: https://issues.apache.org/jira/browse/FINERACT- > Project: Apache Fineract > Issue Type: Sub-task >Reporter: Rahul Pawar >Assignee: Rahul Pawar >Priority: Major > > This sub-module will get the NRC number from the user and it will send the > request to the API and based on the NRC, it will get the Unique ID, this > fetched Unique ID will be further used for fetching Credit Records of the > clients. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FINERACT-1169) fix for broken credit bureau loan-product mapping module
[ https://issues.apache.org/jira/browse/FINERACT-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rahul Pawar updated FINERACT-1169: -- Description: The mapping of a loan product with the credit bureau module is broken in the develop branch. Error : Unknown column 'ocb.is_active' in 'field_list'. was:The mapping of a loan product with the credit bureau module is broken in the develop branch. > fix for broken credit bureau loan-product mapping module > > > Key: FINERACT-1169 > URL: https://issues.apache.org/jira/browse/FINERACT-1169 > Project: Apache Fineract > Issue Type: Bug >Reporter: Rahul Pawar >Assignee: Rahul Pawar >Priority: Major > Fix For: 1.5.0 > > Attachments: Capture.PNG > > > The mapping of a loan product with the credit bureau module is broken in the > develop branch. > Error : Unknown column 'ocb.is_active' in 'field_list'. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FINERACT-1169) fix for broken credit bureau loan-product mapping module
[ https://issues.apache.org/jira/browse/FINERACT-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rahul Pawar updated FINERACT-1169: -- Fix Version/s: 1.5.0 > fix for broken credit bureau loan-product mapping module > > > Key: FINERACT-1169 > URL: https://issues.apache.org/jira/browse/FINERACT-1169 > Project: Apache Fineract > Issue Type: Bug >Reporter: Rahul Pawar >Assignee: Rahul Pawar >Priority: Major > Fix For: 1.5.0 > > Attachments: Capture.PNG > > > The mapping of a loan product with the credit bureau module is broken in the > develop branch. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (FINERACT-1169) fix for broken credit bureau loan-product mapping module
[ https://issues.apache.org/jira/browse/FINERACT-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rahul Pawar reassigned FINERACT-1169: - Assignee: Rahul Pawar > fix for broken credit bureau loan-product mapping module > > > Key: FINERACT-1169 > URL: https://issues.apache.org/jira/browse/FINERACT-1169 > Project: Apache Fineract > Issue Type: Bug >Reporter: Rahul Pawar >Assignee: Rahul Pawar >Priority: Major > Attachments: Capture.PNG > > > The mapping of a loan product with the credit bureau module is broken in the > develop branch. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-1169) fix for broken credit bureau loan-product mapping module
[ https://issues.apache.org/jira/browse/FINERACT-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17205506#comment-17205506 ] Rahul Pawar commented on FINERACT-1169: --- fix for this issue : https://github.com/apache/fineract/pull/1361 > fix for broken credit bureau loan-product mapping module > > > Key: FINERACT-1169 > URL: https://issues.apache.org/jira/browse/FINERACT-1169 > Project: Apache Fineract > Issue Type: Bug >Reporter: Rahul Pawar >Priority: Major > Attachments: Capture.PNG > > > The mapping of a loan product with the credit bureau module is broken in the > develop branch. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FINERACT-1169) fix for broken credit bureau loan-product mapping module
Rahul Pawar created FINERACT-1169: - Summary: fix for broken credit bureau loan-product mapping module Key: FINERACT-1169 URL: https://issues.apache.org/jira/browse/FINERACT-1169 Project: Apache Fineract Issue Type: Bug Reporter: Rahul Pawar Attachments: Capture.PNG The mapping of a loan product with the credit bureau module is broken in the develop branch. -- This message was sent by Atlassian Jira (v8.3.4#803005)
