date:20190412

Re: [OPTIONS] Java 11 and Java JDK origin

2019-04-12 Thread Taher Alkhateeb

I would suggest to make the move as soon as ready. This includes a
final patch and an update of README

On Fri, Apr 12, 2019 at 3:28 PM Jacques Le Roux
 wrote:
>
> Hi All,
>
> This is now done. When should we switch the trunk and R18 to Java 11?
>
> Thanks
>
> Jacques
>
> Le 05/03/2019 à 17:53, Nicolas Malin a écrit :
> > I agree with all proposal that make sens :)
> >
> > Nicolas
> >
> > On 04/03/2019 12:31, Jacques Le Roux wrote:
> >> +1
> >>
> >> Jacques
> >>
> >> Le 04/03/2019 à 11:34, Jacopo Cappellato a écrit :
> >>> I think that the simplest way to convey this message is to edit the README
> >>> document with a link to OpenJDK rather than Oracle JDK.
> >>>
> >>> Jacopo
> >>>
> >>> On Mon, Mar 4, 2019 at 10:22 AM Jacques Le Roux <
> >>> jacques.le.r...@les7arts.com> wrote:
> >>>
>  We should then make clear to our users that they will need to switch to
>  OpenJDK if they want free security support.
> 
>  I guess most are aware, but maybe not small companies or single users.
> 
>  Jacques
> 
>  Le 28/02/2019 à 18:48, Michael Brohl a écrit :
> > +1 for Taher's suggestion.
> >
> > Thanks, Michael
> >
> > Am 28.02.19 um 12:32 schrieb Taher Alkhateeb:
> >> Perhaps we can keep ofbiz 17.12 on java 8, and let 18.12 and trunk
> >> switch to java 11 on openjdk. This might provide stability expected by
> >> users as indicated by Michael.
> >>
> >> On Thu, Feb 28, 2019 at 2:27 PM Jacques Le Roux
> >>  wrote:
> >>> Hi,
> >>>
> >>> During discussions in the "Oracle Java release model changes and
>  consequences for the project" thread, we created "Upgrade OFBiz to use 
>  Java
>  JDK
> >>> Version 11" aka OFBIZ-10757.
> >>>
> >>> There we began to discuss not only if we should switch to Java 11 LTS
>  (Long Time Support), which is obviously the best current choice, but also
>  which
> >>> Java JDK origin we should use OOTB.
> >>>
> >>> So we have few options and we should clarify what the community wants.
> >>>
> >>> Options are:
> >>>
> >>>1. Do we agree to use https://adoptopenjdk.net/releases.html as
>  Java JDK origin OOTB?
> >>>2. Which branches should switch to Java1? Obviously the trunk and
>  R18 should. Should R17, which is not yet released, switch also?
> >>> I hope we don't need a vote and will quickly find a consensus.
> >>>
> >>> Thanks
> >>>
> >>> Jacques
> >>>
> >>
> >

Re: [OPTIONS] Java 11 and Java JDK origin

2019-04-12 Thread Jacques Le Roux


Hi All,

This is now done. When should we switch the trunk and R18 to Java 11?

Thanks

Jacques

Le 05/03/2019 à 17:53, Nicolas Malin a écrit :

I agree with all proposal that make sens :)

Nicolas

On 04/03/2019 12:31, Jacques Le Roux wrote:

+1

Jacques

Le 04/03/2019 à 11:34, Jacopo Cappellato a écrit :

I think that the simplest way to convey this message is to edit the README
document with a link to OpenJDK rather than Oracle JDK.

Jacopo

On Mon, Mar 4, 2019 at 10:22 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


We should then make clear to our users that they will need to switch to
OpenJDK if they want free security support.

I guess most are aware, but maybe not small companies or single users.

Jacques

Le 28/02/2019 à 18:48, Michael Brohl a écrit :

+1 for Taher's suggestion.

Thanks, Michael

Am 28.02.19 um 12:32 schrieb Taher Alkhateeb:

Perhaps we can keep ofbiz 17.12 on java 8, and let 18.12 and trunk
switch to java 11 on openjdk. This might provide stability expected by
users as indicated by Michael.

On Thu, Feb 28, 2019 at 2:27 PM Jacques Le Roux
 wrote:

Hi,

During discussions in the "Oracle Java release model changes and

consequences for the project" thread, we created "Upgrade OFBiz to use Java
JDK

Version 11" aka OFBIZ-10757.

There we began to discuss not only if we should switch to Java 11 LTS

(Long Time Support), which is obviously the best current choice, but also
which

Java JDK origin we should use OOTB.

So we have few options and we should clarify what the community wants.

Options are:

   1. Do we agree to use https://adoptopenjdk.net/releases.html as

Java JDK origin OOTB?

   2. Which branches should switch to Java1? Obviously the trunk and

R18 should. Should R17, which is not yet released, switch also?

I hope we don't need a vote and will quickly find a consensus.

Thanks

Jacques

Re: svn commit: r1856618 - in /ofbiz/ofbiz-plugins/trunk/msg91: ./ config/ data/ data/helpdata/ documents/ entitydef/ servicedef/ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apa

2019-04-12 Thread Jacques Le Roux


+1, thanks Rishi!

Le 12/04/2019 à 12:02, Rishi Solanki a écrit :

Jacques,
Thanks for pointing this, I made code changes before committing this as
plugin. And as we uses free services from them (by mentioning OFBiz as open
source apache software) so didn't give a thought to name of component and
mentioning of commercial services.

I'm completely agree with you on this, I will change the component name and
all occurrences in the code. Please let me know if we are good if we do so,
or something else needs to be done. Thanks!

Best Regards,
--
*Rishi Solanki* | Sr Manager, Enterprise Software Development
HotWax Systems 
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center, Indore,
M.P 452010
Linkedin: *Rishi Solanki*

Direct: +91-9893287847


On Thu, Apr 11, 2019 at 11:02 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi Rishi,

In understand that this component currently uses "msg91 services to send
sms".

But could we not have another name, more explicit, for this component,
like sms or sendsms for instance?

Services tend to disappear or change (Google is the best example). So I'd
not associate the name of an open source component to a commercial services
provider (with a free SMS quota option). Even if hopefully it will stay as
is...

Thanks

Jacques

Le 30/03/2019 à 13:43, ri...@apache.org a écrit :

Author: rishi
Date: Sat Mar 30 12:43:46 2019
New Revision: 1856618

URL: http://svn.apache.org/viewvc?rev=1856618=rev
Log:
[Implemented] Short Messaging Service(SMS) Gateway Integration. Added

msg91 component to plugins. It uses msg91 services to send sms. An example
to demonstrate how to use SMS gateway integration with OFBiz.

(OFBIZ-10457)
Thanks to Pritam Kute for your contribution and Michael Brohi for review

and feedback.

Added:
  ofbiz/ofbiz-plugins/trunk/msg91/
  ofbiz/ofbiz-plugins/trunk/msg91/config/
  ofbiz/ofbiz-plugins/trunk/msg91/config/Msg91UiLabels.xml   (with

props)

  ofbiz/ofbiz-plugins/trunk/msg91/data/
  ofbiz/ofbiz-plugins/trunk/msg91/data/Msg91DemoData.xml   (with

props)
ofbiz/ofbiz-plugins/trunk/msg91/data/Msg91SecurityGroupDemoData.xml   (with
props)
ofbiz/ofbiz-plugins/trunk/msg91/data/Msg91SecurityPermissionSeedData.xml
  (with props)

  ofbiz/ofbiz-plugins/trunk/msg91/data/helpdata/
  ofbiz/ofbiz-plugins/trunk/msg91/data/helpdata/HELP_Msg91.xml

  (with props)

  ofbiz/ofbiz-plugins/trunk/msg91/documents/
  ofbiz/ofbiz-plugins/trunk/msg91/documents/Msg91.xml   (with props)
  ofbiz/ofbiz-plugins/trunk/msg91/entitydef/
  ofbiz/ofbiz-plugins/trunk/msg91/entitydef/entitymodel.xml   (with

props)

  ofbiz/ofbiz-plugins/trunk/msg91/ofbiz-component.xml   (with props)
  ofbiz/ofbiz-plugins/trunk/msg91/servicedef/
  ofbiz/ofbiz-plugins/trunk/msg91/servicedef/services.xml   (with

props)

  ofbiz/ofbiz-plugins/trunk/msg91/src/
  ofbiz/ofbiz-plugins/trunk/msg91/src/main/
  ofbiz/ofbiz-plugins/trunk/msg91/src/main/java/
  ofbiz/ofbiz-plugins/trunk/msg91/src/main/java/org/
  ofbiz/ofbiz-plugins/trunk/msg91/src/main/java/org/apache/
  ofbiz/ofbiz-plugins/trunk/msg91/src/main/java/org/apache/ofbiz/


ofbiz/ofbiz-plugins/trunk/msg91/src/main/java/org/apache/ofbiz/msg91/
ofbiz/ofbiz-plugins/trunk/msg91/src/main/java/org/apache/ofbiz/msg91/Msg91Services.java
  (with props)

  ofbiz/ofbiz-plugins/trunk/msg91/webapp/
  ofbiz/ofbiz-plugins/trunk/msg91/webapp/msg91/
  ofbiz/ofbiz-plugins/trunk/msg91/webapp/msg91/WEB-INF/
  ofbiz/ofbiz-plugins/trunk/msg91/webapp/msg91/WEB-INF/actions/


ofbiz/ofbiz-plugins/trunk/msg91/webapp/msg91/WEB-INF/controller.xml   (with
props)

  ofbiz/ofbiz-plugins/trunk/msg91/webapp/msg91/WEB-INF/web.xml

  (with props)

  ofbiz/ofbiz-plugins/trunk/msg91/webapp/msg91/error/
  ofbiz/ofbiz-plugins/trunk/msg91/webapp/msg91/error/error.jsp

  (with props)

  ofbiz/ofbiz-plugins/trunk/msg91/webapp/msg91/index.jsp   (with

props)

  ofbiz/ofbiz-plugins/trunk/msg91/widget/
  ofbiz/ofbiz-plugins/trunk/msg91/widget/CommonScreens.xml   (with

props)

  ofbiz/ofbiz-plugins/trunk/msg91/widget/Msg91Menus.xml   (with props)
  ofbiz/ofbiz-plugins/trunk/msg91/widget/Msg91Screens.xml   (with

props)

Added: ofbiz/ofbiz-plugins/trunk/msg91/config/Msg91UiLabels.xml
URL:

http://svn.apache.org/viewvc/ofbiz/ofbiz-plugins/trunk/msg91/config/Msg91UiLabels.xml?rev=1856618=auto
==

--- ofbiz/ofbiz-plugins/trunk/msg91/config/Msg91UiLabels.xml (added)
+++ ofbiz/ofbiz-plugins/trunk/msg91/config/Msg91UiLabels.xml Sat Mar 30

12:43:46 2019

@@ -0,0 +1,42 @@
+
+
+
+http://www.w3.org/2001/XMLSchema-instance;

xsi:noNamespaceSchemaLocation="
http://ofbiz.apache.org/dtds/ofbiz-properties.xsd;>

+
+Msg91 Application
+Msg91åº”ç”¨ç¨‹åº 
+Msg91æ‡‰ç”¨ç¨‹å¼ 
+
+
+

Re: svn commit: r1856609 - in /ofbiz/ofbiz-framework/trunk/applications/order: groovyScripts/test/OrderTests.groovy testdef/data/OrderTestData.xml

2019-04-12 Thread Jacques Le Roux


Hi Suraj,

Since this commit https://ci.apache.org/builders/ofbizTrunkFramework/builds/729 
the testAddRequirementTask test fails when done in trunk framework only.

https://ci.apache.org/projects/ofbiz/logs/trunk/framework/html/

See also https://ci.apache.org/builders/ofbizTrunkFramework?numbuilds=40

It works when the plugins are also there: 
https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins?numbuilds=25

https://ci.apache.org/projects/ofbiz/logs/trunk/plugins/html/

I have no ideas why. Maybe some data issue (only in a plugin? Maybe project, 
not sure).

|
|

|Thanks|

|Jacques|

|
|

Le 30/03/2019 à 08:12, sur...@apache.org a écrit :

Author: surajk
Date: Sat Mar 30 07:12:25 2019
New Revision: 1856609

URL: http://svn.apache.org/viewvc?rev=1856609=rev
Log:
Added: Unit test case for service - CreateReturnAdjustment.
(OFBIZ-8857)
Thanks Avnindra Sharma for reporting, Pawan Verma for discussion and Vivek 
Singh Bisen for providing the updated patch.

Modified:
 
ofbiz/ofbiz-framework/trunk/applications/order/groovyScripts/test/OrderTests.groovy
 
ofbiz/ofbiz-framework/trunk/applications/order/testdef/data/OrderTestData.xml

Modified: 
ofbiz/ofbiz-framework/trunk/applications/order/groovyScripts/test/OrderTests.groovy
URL: 
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/order/groovyScripts/test/OrderTests.groovy?rev=1856609=1856608=1856609=diff
==
--- 
ofbiz/ofbiz-framework/trunk/applications/order/groovyScripts/test/OrderTests.groovy
 (original)
+++ 
ofbiz/ofbiz-framework/trunk/applications/order/groovyScripts/test/OrderTests.groovy
 Sat Mar 30 07:12:25 2019
@@ -1,6 +1,7 @@
  import org.apache.ofbiz.entity.util.EntityQuery
  import org.apache.ofbiz.service.ServiceUtil
  import org.apache.ofbiz.testtools.GroovyScriptTestCase
+
  class OrderTests extends GroovyScriptTestCase {
  void testAddRequirementTask() {
  Map serviceCtx = [:]
@@ -10,4 +11,13 @@ class OrderTests extends GroovyScriptTes
  Map serviceResult = dispatcher.runSync("addRequirementTask", 
serviceCtx)
  assert ServiceUtil.isSuccess(serviceResult)
  }
-}
+void testCreateReturnAdjustment() {
+Map serviceCtx = [:]
+serviceCtx.amount = '2.'
+serviceCtx.returnId = '1009'
+serviceCtx.userLogin = 
EntityQuery.use(delegator).from('UserLogin').where('userLoginId', 
'system').cache().queryOne()
+Map serviceResult = dispatcher.runSync('createReturnAdjustment', 
serviceCtx)
+assert ServiceUtil.isSuccess(serviceResult)
+assert serviceResult.returnAdjustmentId != null
+}
+}
\ No newline at end of file

Modified: 
ofbiz/ofbiz-framework/trunk/applications/order/testdef/data/OrderTestData.xml
URL: 
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/order/testdef/data/OrderTestData.xml?rev=1856609=1856608=1856609=diff
==
--- 
ofbiz/ofbiz-framework/trunk/applications/order/testdef/data/OrderTestData.xml 
(original)
+++ 
ofbiz/ofbiz-framework/trunk/applications/order/testdef/data/OrderTestData.xml 
Sat Mar 30 07:12:25 2019
@@ -54,5 +54,6 @@ under the License.
  
  
  
+

Re: svn commit: r1856618 - in /ofbiz/ofbiz-plugins/trunk/msg91: ./ config/ data/ data/helpdata/ documents/ entitydef/ servicedef/ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apa

2019-04-12 Thread Rishi Solanki

Jacques,
Thanks for pointing this, I made code changes before committing this as
plugin. And as we uses free services from them (by mentioning OFBiz as open
source apache software) so didn't give a thought to name of component and
mentioning of commercial services.

I'm completely agree with you on this, I will change the component name and
all occurrences in the code. Please let me know if we are good if we do so,
or something else needs to be done. Thanks!

Best Regards,
--
*Rishi Solanki* | Sr Manager, Enterprise Software Development
HotWax Systems 
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center, Indore,
M.P 452010
Linkedin: *Rishi Solanki*

Direct: +91-9893287847


On Thu, Apr 11, 2019 at 11:02 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi Rishi,
>
> In understand that this component currently uses "msg91 services to send
> sms".
>
> But could we not have another name, more explicit, for this component,
> like sms or sendsms for instance?
>
> Services tend to disappear or change (Google is the best example). So I'd
> not associate the name of an open source component to a commercial services
> provider (with a free SMS quota option). Even if hopefully it will stay as
> is...
>
> Thanks
>
> Jacques
>
> Le 30/03/2019 à 13:43, ri...@apache.org a écrit :
> > Author: rishi
> > Date: Sat Mar 30 12:43:46 2019
> > New Revision: 1856618
> >
> > URL: http://svn.apache.org/viewvc?rev=1856618=rev
> > Log:
> > [Implemented] Short Messaging Service(SMS) Gateway Integration. Added
> msg91 component to plugins. It uses msg91 services to send sms. An example
> to demonstrate how to use SMS gateway integration with OFBiz.
> > (OFBIZ-10457)
> > Thanks to Pritam Kute for your contribution and Michael Brohi for review
> and feedback.
> >
> > Added:
> >  ofbiz/ofbiz-plugins/trunk/msg91/
> >  ofbiz/ofbiz-plugins/trunk/msg91/config/
> >  ofbiz/ofbiz-plugins/trunk/msg91/config/Msg91UiLabels.xml   (with
> props)
> >  ofbiz/ofbiz-plugins/trunk/msg91/data/
> >  ofbiz/ofbiz-plugins/trunk/msg91/data/Msg91DemoData.xml   (with
> props)
> >
> ofbiz/ofbiz-plugins/trunk/msg91/data/Msg91SecurityGroupDemoData.xml   (with
> props)
> >
> ofbiz/ofbiz-plugins/trunk/msg91/data/Msg91SecurityPermissionSeedData.xml
>  (with props)
> >  ofbiz/ofbiz-plugins/trunk/msg91/data/helpdata/
> >  ofbiz/ofbiz-plugins/trunk/msg91/data/helpdata/HELP_Msg91.xml
>  (with props)
> >  ofbiz/ofbiz-plugins/trunk/msg91/documents/
> >  ofbiz/ofbiz-plugins/trunk/msg91/documents/Msg91.xml   (with props)
> >  ofbiz/ofbiz-plugins/trunk/msg91/entitydef/
> >  ofbiz/ofbiz-plugins/trunk/msg91/entitydef/entitymodel.xml   (with
> props)
> >  ofbiz/ofbiz-plugins/trunk/msg91/ofbiz-component.xml   (with props)
> >  ofbiz/ofbiz-plugins/trunk/msg91/servicedef/
> >  ofbiz/ofbiz-plugins/trunk/msg91/servicedef/services.xml   (with
> props)
> >  ofbiz/ofbiz-plugins/trunk/msg91/src/
> >  ofbiz/ofbiz-plugins/trunk/msg91/src/main/
> >  ofbiz/ofbiz-plugins/trunk/msg91/src/main/java/
> >  ofbiz/ofbiz-plugins/trunk/msg91/src/main/java/org/
> >  ofbiz/ofbiz-plugins/trunk/msg91/src/main/java/org/apache/
> >  ofbiz/ofbiz-plugins/trunk/msg91/src/main/java/org/apache/ofbiz/
> >
> ofbiz/ofbiz-plugins/trunk/msg91/src/main/java/org/apache/ofbiz/msg91/
> >
> ofbiz/ofbiz-plugins/trunk/msg91/src/main/java/org/apache/ofbiz/msg91/Msg91Services.java
>  (with props)
> >  ofbiz/ofbiz-plugins/trunk/msg91/webapp/
> >  ofbiz/ofbiz-plugins/trunk/msg91/webapp/msg91/
> >  ofbiz/ofbiz-plugins/trunk/msg91/webapp/msg91/WEB-INF/
> >  ofbiz/ofbiz-plugins/trunk/msg91/webapp/msg91/WEB-INF/actions/
> >
> ofbiz/ofbiz-plugins/trunk/msg91/webapp/msg91/WEB-INF/controller.xml   (with
> props)
> >  ofbiz/ofbiz-plugins/trunk/msg91/webapp/msg91/WEB-INF/web.xml
>  (with props)
> >  ofbiz/ofbiz-plugins/trunk/msg91/webapp/msg91/error/
> >  ofbiz/ofbiz-plugins/trunk/msg91/webapp/msg91/error/error.jsp
>  (with props)
> >  ofbiz/ofbiz-plugins/trunk/msg91/webapp/msg91/index.jsp   (with
> props)
> >  ofbiz/ofbiz-plugins/trunk/msg91/widget/
> >  ofbiz/ofbiz-plugins/trunk/msg91/widget/CommonScreens.xml   (with
> props)
> >  ofbiz/ofbiz-plugins/trunk/msg91/widget/Msg91Menus.xml   (with props)
> >  ofbiz/ofbiz-plugins/trunk/msg91/widget/Msg91Screens.xml   (with
> props)
> >
> > Added: ofbiz/ofbiz-plugins/trunk/msg91/config/Msg91UiLabels.xml
> > URL:
> http://svn.apache.org/viewvc/ofbiz/ofbiz-plugins/trunk/msg91/config/Msg91UiLabels.xml?rev=1856618=auto
> >
> ==
> > --- ofbiz/ofbiz-plugins/trunk/msg91/config/Msg91UiLabels.xml (added)
> > +++ ofbiz/ofbiz-plugins/trunk/msg91/config/Msg91UiLabels.xml Sat Mar 30
> 12:43:46 2019
> > @@ -0,0 +1,42 @@
> > +
> > +
> > +
> > +http://www.w3.org/2001/XMLSchema-instance;
>

Re: Visit/Visitor specific client IPs tracking exclusion

2019-04-12 Thread Nicolas Malin


Hello,

To manage own load balancer we use a dedicate uri like this :

   track-visit="false">


It would be help to redirect your monitoring traffic.

Nicolas

On 12/04/2019 08:49, Arun Patidar wrote:

Hello Giulio,

Thanks for the the detailed and clear message. My understanding with your
proposal is as below:

1) We should enable configuration settings to ignore visit entries for
Internal IPs and known requests (like HaProxy/load balancer, monitoring
requests) etc.
2) For large DB size due to visits and hits, we can use a separate Stats
database for visit entity group.
3) Also, idea to purge old visits using a scheduled job is good, We can set
number of days configurable as per need.



--
Best Regards,
Arun Patidar
www.hotwax.co



On Fri, Apr 12, 2019 at 5:17 AM Giulio Speri - MpStyle Srl <
giulio.sp...@mpstyle.it> wrote:


Hello devs,

I'm writing because I would like to explain a problem my company, MpStyle,
faced with an OFBiz installation with two active ecommerce sites, for one
of our customers.
I am writing this email to the dev mailing list, because I could not find
any reference in the mailings to the kind of problem we faced, and I think
that the solution we built, could be an improvement to the OFBiz
visit/visitor tracking capabilites.

I shortly explain the server architecture on which OFBiz is running: hosted
by a third party supplier, there are two (virtual) machines where Apache
OFBiz 13.07.03 is running behind Apache2 web server (so we have two web
fronts).
On other two different machines there are the database (MariaDB) and
HaProxy has a load balancer.
HaProxy is configured to perform its Health Checks on the backend servers
with a Http GET on the Home Page of one of the two sites.
Visit and Visitor tracking are enabled, for BI and analytics purposes, so
we cannot turn them off.
These two combined things caused the Visit and Visitor tables to explode in
dimensions (we counted about 19M records of Visit and about 67M of
Visitors, with the 86% of those caused by the load balancer), since each
hit of the HaProxy store a Visit and a Visitor record on the db (plus some
other record of other entities, like ShoppingList, due to  and
 events).
A bad side effect of this situation, on the long run, is an overall
performance degradation, and an increase in webfront unavailability time
windows during the day: it's not necessary to say that our customer was not
so happy about this.

The difficult part of figuring out this problem, was that we did not have
direct access to HaProxy and DB machines, to check logs.

The solution we thought and implemented, was to exclude from Visit/Visitor
tracking specific IP addresses (for our case we were interested in HaProxy
IP).
The Visit and Visitor records (along with firstvisit and preprocessor
events) are created mainly in the ControlServlet class, using VisitHandler
getVisit/getVisitor/getVisitId methods.

Our idea consist in reading from a .properties file one or more IP
addresses we would like to exclude from tracking and then check them
against the client ip address the request is coming from.
If the client ip address is in the "exclusion list", then do not persist
visit/visitor and do not run firstvisit events neither for it.

The idea is quite simple, but we noticed in few days, a meaningful
improvement in overall system performance and stability/availability.

This kind of exclusion could be also useful in case we do not want to track
or register internal IP addresses (ie: mainly used for testing).

However this solution, should be integrated with a service (cron or
scheduled in ofbiz) that keeps the number of records in the tables limited
(for example keep only the last month of visit/visitor); I think that these
two solutions together, could do the job well.

I hope my explanation was clear enough and I would be happy to know what do
you think about this.

Thank you all for the attention!

Regards,

Giulio



























--
Giulio Speri


*Mp Styl**e Srl*
via Antonio Meucci, 37
41019 Limidi di Soliera (MO)
T 059/684916
M 334/3779851

www.mpstyle.it

Re: Visit/Visitor specific client IPs tracking exclusion

2019-04-12 Thread Arun Patidar

Hello Giulio,

Thanks for the the detailed and clear message. My understanding with your
proposal is as below:

1) We should enable configuration settings to ignore visit entries for
Internal IPs and known requests (like HaProxy/load balancer, monitoring
requests) etc.
2) For large DB size due to visits and hits, we can use a separate Stats
database for visit entity group.
3) Also, idea to purge old visits using a scheduled job is good, We can set
number of days configurable as per need.



--
Best Regards,
Arun Patidar
www.hotwax.co



On Fri, Apr 12, 2019 at 5:17 AM Giulio Speri - MpStyle Srl <
giulio.sp...@mpstyle.it> wrote:

> Hello devs,
>
> I'm writing because I would like to explain a problem my company, MpStyle,
> faced with an OFBiz installation with two active ecommerce sites, for one
> of our customers.
> I am writing this email to the dev mailing list, because I could not find
> any reference in the mailings to the kind of problem we faced, and I think
> that the solution we built, could be an improvement to the OFBiz
> visit/visitor tracking capabilites.
>
> I shortly explain the server architecture on which OFBiz is running: hosted
> by a third party supplier, there are two (virtual) machines where Apache
> OFBiz 13.07.03 is running behind Apache2 web server (so we have two web
> fronts).
> On other two different machines there are the database (MariaDB) and
> HaProxy has a load balancer.
> HaProxy is configured to perform its Health Checks on the backend servers
> with a Http GET on the Home Page of one of the two sites.
> Visit and Visitor tracking are enabled, for BI and analytics purposes, so
> we cannot turn them off.
> These two combined things caused the Visit and Visitor tables to explode in
> dimensions (we counted about 19M records of Visit and about 67M of
> Visitors, with the 86% of those caused by the load balancer), since each
> hit of the HaProxy store a Visit and a Visitor record on the db (plus some
> other record of other entities, like ShoppingList, due to  and
>  events).
> A bad side effect of this situation, on the long run, is an overall
> performance degradation, and an increase in webfront unavailability time
> windows during the day: it's not necessary to say that our customer was not
> so happy about this.
>
> The difficult part of figuring out this problem, was that we did not have
> direct access to HaProxy and DB machines, to check logs.
>
> The solution we thought and implemented, was to exclude from Visit/Visitor
> tracking specific IP addresses (for our case we were interested in HaProxy
> IP).
> The Visit and Visitor records (along with firstvisit and preprocessor
> events) are created mainly in the ControlServlet class, using VisitHandler
> getVisit/getVisitor/getVisitId methods.
>
> Our idea consist in reading from a .properties file one or more IP
> addresses we would like to exclude from tracking and then check them
> against the client ip address the request is coming from.
> If the client ip address is in the "exclusion list", then do not persist
> visit/visitor and do not run firstvisit events neither for it.
>
> The idea is quite simple, but we noticed in few days, a meaningful
> improvement in overall system performance and stability/availability.
>
> This kind of exclusion could be also useful in case we do not want to track
> or register internal IP addresses (ie: mainly used for testing).
>
> However this solution, should be integrated with a service (cron or
> scheduled in ofbiz) that keeps the number of records in the tables limited
> (for example keep only the last month of visit/visitor); I think that these
> two solutions together, could do the job well.
>
> I hope my explanation was clear enough and I would be happy to know what do
> you think about this.
>
> Thank you all for the attention!
>
> Regards,
>
> Giulio
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
> Giulio Speri
>
>
> *Mp Styl**e Srl*
> via Antonio Meucci, 37
> 41019 Limidi di Soliera (MO)
> T 059/684916
> M 334/3779851
>
> www.mpstyle.it
>

Re: [OPTIONS] Java 11 and Java JDK origin

Re: [OPTIONS] Java 11 and Java JDK origin

Re: svn commit: r1856618 - in /ofbiz/ofbiz-plugins/trunk/msg91: ./ config/ data/ data/helpdata/ documents/ entitydef/ servicedef/ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apa

Re: svn commit: r1856609 - in /ofbiz/ofbiz-framework/trunk/applications/order: groovyScripts/test/OrderTests.groovy testdef/data/OrderTestData.xml

Re: svn commit: r1856618 - in /ofbiz/ofbiz-plugins/trunk/msg91: ./ config/ data/ data/helpdata/ documents/ entitydef/ servicedef/ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apa

Re: Visit/Visitor specific client IPs tracking exclusion

Re: Visit/Visitor specific client IPs tracking exclusion

7 matches

Site Navigation

Mail list logo

Footer information