[jira] [Closed] (OFBIZ-3583) Resolve two issues with scheduled jobs related to clean-up

[Nicolas Malin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nicolas Malin closed OFBIZ-3583.

Resolution: Not A Problem

Right it is already done on trunk ;)

> Resolve two issues with scheduled jobs related to clean-up
> --
>
> Key: OFBIZ-3583
> URL: https://issues.apache.org/jira/browse/OFBIZ-3583
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Reporter: Bob Morley
>Assignee: Nicolas Malin
> Attachments: OFBIZ-3583_FixsToScheduledJobCleanup.patch
>
>
> Encountered two problems --
> 1) If a semaphore service is executing when the application server goes down 
> (see purgeOldJobs) the reloadCrashedJobs takes over to mark this job as 
> CRASHED.  However, it does not clean-up the ServiceSemaphore record which 
> causes all future jobs to either fail immediately or wait (until semaphore 
> timeout) and then fail.
> 2) When ServiceUtil.purgeOldJobs is invoked it blindly attempts to delete 
> runtimeData and then rollsback if this delete fails (always when other jobs 
> reference the same runtimeData).  This causes a service error log message for 
> what is really typical behavior.
> Solutions --
> 1) When reloading crashed jobs, we look for a rogue ServiceSemaphore for this 
> service name and purge it (on start-up).  This works for multiple application 
> servers because any crashed job would leave behind the semaphore and no other 
> application server running the JobManager could have created it (as they 
> would have been blocked from executing).
> 2) In purgeOldJobs I changed the list of runtimeDataIds from a List to a Set 
> (this remove the redundant delete requests).  When attempting the delete I do 
> a "quick" count on the JobSandbox table to see if there are any jobs still 
> hanging onto the particular RuntimeData instance and only attempt the delete 
> when there are no more remaining jobs.  There is an existing index on the 
> JobSandbox for the runtimeDataId so this count should perform relatively 
> quickly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6783) Refactor start.java

[Taher Alkhateeb (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Taher Alkhateeb updated OFBIZ-6783:
---
Description: 
Looking at the main method and design of Start.java looks ugly. The things I 
would like to fix so far are:

- the file is too long
- some variables are not even needed (loaderArgs?)
- the level of abstraction is wrong
- main throws an exception!
- the arguments processing logic is terrible, need to move it to commons-cli

It's just so messy and ugly to look at. So for me refactoring starts at Start! 
Given that this is an important file, I will provide a patch to be reviewed by 
the community before committing just to be on the safe side.

  was:
Looking at the main method and design of Start.java looks ugly. The things I 
would like to fix so far are:

- the file is too long
- some variables are not even needed (loaderArgs?)
- the level of abstraction is wrong
- main throws an exception!

It's just so messy and ugly to look at. So for me refactoring starts at Start! 
Given that this is an important file, I will provide a patch to be reviewed by 
the community before committing just to be on the safe side.


> Refactor start.java
> ---
>
> Key: OFBIZ-6783
> URL: https://issues.apache.org/jira/browse/OFBIZ-6783
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Upcoming Branch
>Reporter: Taher Alkhateeb
>Assignee: Taher Alkhateeb
>  Labels: framework, main, refactoring, start
>
> Looking at the main method and design of Start.java looks ugly. The things I 
> would like to fix so far are:
> - the file is too long
> - some variables are not even needed (loaderArgs?)
> - the level of abstraction is wrong
> - main throws an exception!
> - the arguments processing logic is terrible, need to move it to commons-cli
> It's just so messy and ugly to look at. So for me refactoring starts at 
> Start! Given that this is an important file, I will provide a patch to be 
> reviewed by the community before committing just to be on the safe side.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Creating the 15.12 release branch

[Deepak Dixit]

I think ecommerce broken due to r1719939, I reverted it and tested it
locally and its working fine.
I am testing it more and if its working properly then I'll revert r1719939.

Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com

On Wed, Dec 30, 2015 at 4:54 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> That's not blocking, once freezed we patch releases branches
>
> Jacques
>
>
> Le 30/12/2015 06:28, Vyom Jain a écrit :
>
>> Hi Jacopo,
>>
>> I've been doing random tests, the major issue that has been noticed &
>> reported is OFBIZ-6781 [https://issues.apache.org/jira/browse/OFBIZ-6781
>> ].
>>
>> Also, I think I did face some issues (after fresh checkout and no local
>> changes) when adding products to cart in the ecommerce application.
>>
>> --
>> Vyom
>>
>> On 29 December 2015 at 22:49, Jacopo Cappellato <
>> jacopo.cappell...@hotwaxsystems.com> wrote:
>>
>> Should we create a 15.12 branch before the end of the year?
>>> I don't have a strong opinion but it may be nice to create since:
>>> 1) the 12.04 is approaching the end of life and we usually keep 3 live
>>> branches
>>> 2) several changes have been introduced since the last (14.12) branch
>>> 3) it is nice to avoid skipping a year
>>>
>>> What do you think?
>>>
>>> Jacopo
>>>
>>>

[jira] [Commented] (OFBIZ-6655) Add session tracking mode and make cookie secure

[Deepak Dixit (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-6655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15075201#comment-15075201
 ] 

Deepak Dixit commented on OFBIZ-6655:
-

Reverted r1719762, as system fails to find the session cookie for ecommerce, 
will debug it in more detail but for now to fix this issue reverting r1719762 
at r#1722379. 

> Add session tracking mode and make cookie secure
> 
>
> Key: OFBIZ-6655
> URL: https://issues.apache.org/jira/browse/OFBIZ-6655
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk, 14.12.01
>Reporter: Deepak Dixit
>Assignee: Deepak Dixit
> Attachments: OFBIA-6655.applications.patch, 
> OFBIZ-6655.framework_themes.patch, OFBIZ-6655_specialpurpose_leftover.patch, 
> sessionConifg_ecommerce.patch
>
>
> Need to enhance security at web-app level. 
> As per current implementation:
> - The cookie containing the session identifier is not secure
> - The session identifier is transmitted in the query string of the URL
> To fix these issue we have to add following session config otpions in web.xml
> {code}
> 
>   
>   true
>   true
>   
>   COOKIE
> 
> {code}
> Also we need to update the web-app servlet specification from 2.3 to 3.0
> {code}
>  xmlns="http://java.sun.com/xml/ns/javaee;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> 
> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd;>
> {code}
> https://tomcat.apache.org/whichversion.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

buildbot failure in ASF Buildbot on ofbiz-trunk-rat

[buildbot]

The Buildbot has detected a new failure on builder ofbiz-trunk-rat while 
building ASF Buildbot. Full details are available at:
http://ci.apache.org/builders/ofbiz-trunk-rat/builds/171

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: lares_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-ofbiz-commit' 
triggered this build
Build Source Stamp: [branch ofbiz/trunk] 1722379
Blamelist: deepak

BUILD FAILED: failed

Sincerely,
 -The Buildbot

[jira] [Created] (OFBIZ-6784) JobSandbox : reload crashed job maybe duplicate pending service

[Nicolas Malin (JIRA)]

Nicolas Malin created OFBIZ-6784:


 Summary: JobSandbox : reload crashed job maybe duplicate pending 
service
 Key: OFBIZ-6784
 URL: https://issues.apache.org/jira/browse/OFBIZ-6784
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: Trunk
Reporter: Nicolas Malin
Assignee: Nicolas Malin


When the JobPoller run reloadCrashedJobs() after an OFBiz restart, if you have 
a large service that crash that already replenish the pool receive a new run 
instant for it.

Example: If you have a service like loadExternalOrder that run each hours. You 
stop your OFBiz during their activity and at restart you have :
* job1 loadExternalOrder RUNINNG
* job2 loadExternalOrder PENDING at t+1h (normal schedule)
* job1.1 loadExternalOrder PENDING at t+1h  (crashed schedule)

I propose to exclude from the process reloadCrashedJobs() all jobs that have 
already a new scheduled instance




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-6784) JobSandbox : reload crashed job maybe duplicate pending service

[Nicolas Malin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-6784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nicolas Malin updated OFBIZ-6784:
-
Attachment: OFBIZ-6784.patch

The patch with my ideao to solve the problem.

We don't reload a crashed service if a child instance is already present on  
status PENDING, RUNNING or QUEUED

> JobSandbox : reload crashed job maybe duplicate pending service
> ---
>
> Key: OFBIZ-6784
> URL: https://issues.apache.org/jira/browse/OFBIZ-6784
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Trunk
>Reporter: Nicolas Malin
>Assignee: Nicolas Malin
>  Labels: jobsandbox
> Attachments: OFBIZ-6784.patch
>
>
> When the JobPoller run reloadCrashedJobs() after an OFBiz restart, if you 
> have a large service that crash that already replenish the pool receive a new 
> run instant for it.
> Example: If you have a service like loadExternalOrder that run each hours. 
> You stop your OFBiz during their activity and at restart you have :
> * job1 loadExternalOrder RUNINNG
> * job2 loadExternalOrder PENDING at t+1h (normal schedule)
> * job1.1 loadExternalOrder PENDING at t+1h  (crashed schedule)
> I propose to exclude from the process reloadCrashedJobs() all jobs that have 
> already a new scheduled instance



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6784) JobSandbox : reload crashed job maybe duplicate pending service

[Nicolas Malin (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-6784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15075240#comment-15075240
 ] 

Nicolas Malin commented on OFBIZ-6784:
--

I have the problem on production site under 13.07 so I will interested to 
backport this on all stables branches.

I open to a review :)

> JobSandbox : reload crashed job maybe duplicate pending service
> ---
>
> Key: OFBIZ-6784
> URL: https://issues.apache.org/jira/browse/OFBIZ-6784
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Trunk
>Reporter: Nicolas Malin
>Assignee: Nicolas Malin
>  Labels: jobsandbox
> Attachments: OFBIZ-6784.patch
>
>
> When the JobPoller run reloadCrashedJobs() after an OFBiz restart, if you 
> have a large service that crash that already replenish the pool receive a new 
> run instant for it.
> Example: If you have a service like loadExternalOrder that run each hours. 
> You stop your OFBiz during their activity and at restart you have :
> * job1 loadExternalOrder RUNINNG
> * job2 loadExternalOrder PENDING at t+1h (normal schedule)
> * job1.1 loadExternalOrder PENDING at t+1h  (crashed schedule)
> I propose to exclude from the process reloadCrashedJobs() all jobs that have 
> already a new scheduled instance



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Creating the 15.12 release branch

[Sharan-F]

+1   It would be nice to do just so we don't miss a year. 

For the 2016 releases it might be good to set a target month to work
towards.

Thanks
Sharan



--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Creating-the-15-12-release-branch-tp4675548p4675577.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: Creating the 15.12 release branch

[Jacques Le Roux]

I did not think much about it, but I can't see a reason why we should not

Jacques

Le 29/12/2015 18:19, Jacopo Cappellato a écrit :

Should we create a 15.12 branch before the end of the year?
I don't have a strong opinion but it may be nice to create since:
1) the 12.04 is approaching the end of life and we usually keep 3 live
branches
2) several changes have been introduced since the last (14.12) branch
3) it is nice to avoid skipping a year

What do you think?

Jacopo

Re: Creating the 15.12 release branch

[Deepak Dixit]

Hi Vyom,

I reverted the suspected commit (r1719762) at r#1722379. I tested it
locally and ecommerce working fine after reverting it.

Could you please test it with ant clean-all?


Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com

On Wed, Dec 30, 2015 at 10:58 AM, Vyom Jain  wrote:

> Hi Jacopo,
>
> I've been doing random tests, the major issue that has been noticed &
> reported is OFBIZ-6781 [https://issues.apache.org/jira/browse/OFBIZ-6781
> ].
>
> Also, I think I did face some issues (after fresh checkout and no local
> changes) when adding products to cart in the ecommerce application.
>
> --
> Vyom
>
> On 29 December 2015 at 22:49, Jacopo Cappellato <
> jacopo.cappell...@hotwaxsystems.com> wrote:
>
> > Should we create a 15.12 branch before the end of the year?
> > I don't have a strong opinion but it may be nice to create since:
> > 1) the 12.04 is approaching the end of life and we usually keep 3 live
> > branches
> > 2) several changes have been introduced since the last (14.12) branch
> > 3) it is nice to avoid skipping a year
> >
> > What do you think?
> >
> > Jacopo
> >
>

Re: Creating the 15.12 release branch

[Nicolas Malin]

I see one other advantage, create the last stable branche efore the 
framework refactoring.


So +1

Nicolas

Le 29/12/2015 18:19, Jacopo Cappellato a écrit :

Should we create a 15.12 branch before the end of the year?
I don't have a strong opinion but it may be nice to create since:
1) the 12.04 is approaching the end of life and we usually keep 3 live
branches
2) several changes have been introduced since the last (14.12) branch
3) it is nice to avoid skipping a year

What do you think?

Jacopo

Re: Creating the 15.12 release branch

[Jacques Le Roux]

That's not blocking, once freezed we patch releases branches

Jacques

Le 30/12/2015 06:28, Vyom Jain a écrit :

Hi Jacopo,

I've been doing random tests, the major issue that has been noticed &
reported is OFBIZ-6781 [https://issues.apache.org/jira/browse/OFBIZ-6781
].

Also, I think I did face some issues (after fresh checkout and no local
changes) when adding products to cart in the ecommerce application.

--
Vyom

On 29 December 2015 at 22:49, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:


Should we create a 15.12 branch before the end of the year?
I don't have a strong opinion but it may be nice to create since:
1) the 12.04 is approaching the end of life and we usually keep 3 live
branches
2) several changes have been introduced since the last (14.12) branch
3) it is nice to avoid skipping a year

What do you think?

Jacopo

[jira] [Updated] (OFBIZ-6783) Refactor start.java

[Taher Alkhateeb (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Taher Alkhateeb updated OFBIZ-6783:
---
Description: 
Looking at the main method and design of Start.java looks ugly. The things I 
would like to fix so far are:

- the file is too long
- some variables are not even needed (loaderArgs?)
- the level of abstraction is wrong
- main throws an exception!

It's just so messy and ugly to look at. So for me refactoring starts at Start! 
Given that this is an important file, I will provide a patch to be reviewed by 
the community before committing just to be on the safe side.

  was:
Looking at the main method and design of Start.java looks ugly. The things I 
would like to fix so far are:

- the file is too long
- some variables are not even needed (loaderArgs?)
- the level of abstraction is wrong

It's just so messy and ugly to look at. So for me refactoring starts at Start! 
Given that this is an important file, I will provide a patch to be reviewed by 
the community before committing just to be on the safe side.


> Refactor start.java
> ---
>
> Key: OFBIZ-6783
> URL: https://issues.apache.org/jira/browse/OFBIZ-6783
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Upcoming Branch
>Reporter: Taher Alkhateeb
>Assignee: Taher Alkhateeb
>  Labels: framework, main, refactoring, start
>
> Looking at the main method and design of Start.java looks ugly. The things I 
> would like to fix so far are:
> - the file is too long
> - some variables are not even needed (loaderArgs?)
> - the level of abstraction is wrong
> - main throws an exception!
> It's just so messy and ugly to look at. So for me refactoring starts at 
> Start! Given that this is an important file, I will provide a patch to be 
> reviewed by the community before committing just to be on the safe side.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)