Call for Presentations now open: Community over Code EU 2024
(Note: You are receiving this because you are subscribed to the dev@ list for one or more projects of the Apache Software Foundation.) It's back *and* it's new! We're excited to announce that the first edition of Community over Code Europe (formerly known as ApacheCon EU) which will be held at the Radisson Blu Carlton Hotel in Bratislava, Slovakia from June 03-05, 2024! This eagerly anticipated event will be our first live EU conference since 2019. The Call for Presentations (CFP) for Community Over Code EU 2024 is now open at https://eu.communityovercode.org/blog/cfp-open/, and will close 2024/01/12 23:59:59 GMT. We welcome submissions on any topic related to the Apache Software Foundation, Apache projects, or the communities around those projects. We are specifically looking for presentations in the following categories: * API & Microservices * Big Data Compute * Big Data Storage * Cassandra * CloudStack * Community * Data Engineering * Fintech * Groovy * Incubator * IoT * Performance Engineering * Search * Tomcat, Httpd and other servers Additionally, we are thrilled to introduce a new feature this year: a poster session. This addition will provide an excellent platform for showcasing high-level projects and incubator initiatives in a visually engaging manner. We believe this will foster lively discussions and facilitate networking opportunities among participants. All my best, and thanks so much for your participation, Ryan Skraba (on behalf of the program committee) [Countdown]: https://www.timeanddate.com/countdown/to?iso=20240112T2359&p0=1440
Re: [VOTE] Apache OFBiz 18.12.09
Hi Michael, This did no happen to me. And yes the plugins are part of the release. Also as you know attachments rarely works for Apache ML. Le 30/10/2023 à 14:41, Michael Brohl a écrit : -1 The build fails with some exceptions for converters, solr-server and others (see attached log). I'm not completely sure but I do not expect the plugins to be shipped in the framework distribution? Best regards, Michael Brohl ecomify GmbH - www.ecomify.de Am 29.10.23 um 13:16 schrieb Jacopo Cappellato: This is the vote thread to publish "Apache OFBiz 18.12.09", ninth release from the release18.12 branch. The release files can be downloaded from here: https://dist.apache.org/repos/dist/dev/ofbiz/ and are: * apache-ofbiz-18.12.09.zip * KEYS: text file with keys * apache-ofbiz-18.12.09.zip.asc: the detached signature file * apache-ofbiz-18.12.09.zip.sha512: checksum file Please download and test the zip file and its signatures (for instructions on testing the signatures see http://www.apache.org/info/verification.html). Vote: [ +1] release as Apache OFBiz 18.12.09 [ -1] do not release This vote is open for at least 5 days. For more details about this process please refer to http://www.apache.org/foundation/voting.html
Re: Issue with OFBiz Job Scheduler and Daylight Saving Time
Here is the PR for reference
https://github.com/apache/ofbiz-framework/pull/674/files
Please review and share your feedback!!
Thanks & Regards
--
Deepak Dixit
ofbiz.apache.org
On Mon, Oct 30, 2023 at 6:53 PM Michael Brohl
wrote:
> +1
>
> Thanks Deepak,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 30.10.23 um 14:03 schrieb Deepak Dixit:
> > The issue occurs when DST changes, and OFBiz fails to schedule recurring
> > jobs properly.
> > This is due to a condition in the PersistedServiceJob.createRecurrence
> > method where it compares the next scheduled time (next) with the start
> time
> > (startTime) for the job.
> >
> >
> > *Proposed Solution:*To address the issue, adding a new field named
> > JobSandbox.runTimeEpoch. This field would store the UTC epoch
> milliseconds
> > of the runtime date.
> > When scheduling or rescheduling recurring jobs, the system would use the
> > UTC epoch stored in JobSandbox.runTimeEpoch for recurring job comparison.
> >
> > This solution ensures that the system uses a consistent, UTC-based time
> for
> > scheduling and rescheduling recurring jobs, even when DST changes affect
> > the local time.
> >
> > To implement this solution, we need to do following things:
> >
> > - Modify the PersistedServiceJob.createRecurrence method to calculate and
> > store the UTC epoch milliseconds in the JobSandbox.runTimeEpoch field.
> > - Update the code responsible for polling and rescheduling jobs to use
> the
> > JobSandbox.runTimeEpoch field when it is set. If the field is not set, It
> > would fall back to getting the runtime date to filter the jobs.
> >
> > By using this approach, the system should be able to handle recurring job
> > scheduling more reliably, especially when DST changes are involved, as it
> > ensures that all time comparisons are made in a consistent UTC format.
> >
> >
> > Thanks & Regards
> > --
> > Deepak Dixit
> > ofbiz.apache.org
> >
> >
> > On Tue, Oct 17, 2023 at 11:00 AM Deepak Dixit wrote:
> >
> >> Hi Dev,
> >>
> >> I wanted to draw your attention to an issue we've encountered with the
> >> OFBiz job scheduler, particularly when it comes to handling Daylight
> Saving
> >> Time (DST) changes.
> >>
> >> It appears that the job scheduler fails to create new recurring jobs
> when
> >> DST ends, especially when the tempExprTypeId is set to FREQUENCY (e.g.,
> 15
> >> minutes, 30 minutes).
> >>
> >> Upon further investigation, we've identified that the following
> condition
> >> in PersistedServiceJob.createRecurrence might be the root of the issue:
> >>
> >> java
> >>
> >> if (next > startTime) {
> >> // ...
> >> // ...
> >> }
> >>
> >> I'm curious to know if anyone else has encountered a similar problem or
> if
> >> you have any insights to share regarding this issue.
> >>
> >> Thanks & Regards
> >>
> >> --
> >> Deepak Dixit
> >> ofbiz.apache.org
> >>
>
Re: [VOTE] Apache OFBiz 18.12.09
-1 The build fails with some exceptions for converters, solr-server and others (see attached log). I'm not completely sure but I do not expect the plugins to be shipped in the framework distribution? Best regards, Michael Brohl ecomify GmbH - www.ecomify.de Am 29.10.23 um 13:16 schrieb Jacopo Cappellato: This is the vote thread to publish "Apache OFBiz 18.12.09", ninth release from the release18.12 branch. The release files can be downloaded from here: https://dist.apache.org/repos/dist/dev/ofbiz/ and are: * apache-ofbiz-18.12.09.zip * KEYS: text file with keys * apache-ofbiz-18.12.09.zip.asc: the detached signature file * apache-ofbiz-18.12.09.zip.sha512: checksum file Please download and test the zip file and its signatures (for instructions on testing the signatures see http://www.apache.org/info/verification.html). Vote: [ +1] release as Apache OFBiz 18.12.09 [ -1] do not release This vote is open for at least 5 days. For more details about this process please refer to http://www.apache.org/foundation/voting.html
Re: Issue with OFBiz Job Scheduler and Daylight Saving Time
+1
Thanks Deepak,
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 30.10.23 um 14:03 schrieb Deepak Dixit:
The issue occurs when DST changes, and OFBiz fails to schedule recurring
jobs properly.
This is due to a condition in the PersistedServiceJob.createRecurrence
method where it compares the next scheduled time (next) with the start time
(startTime) for the job.
*Proposed Solution:*To address the issue, adding a new field named
JobSandbox.runTimeEpoch. This field would store the UTC epoch milliseconds
of the runtime date.
When scheduling or rescheduling recurring jobs, the system would use the
UTC epoch stored in JobSandbox.runTimeEpoch for recurring job comparison.
This solution ensures that the system uses a consistent, UTC-based time for
scheduling and rescheduling recurring jobs, even when DST changes affect
the local time.
To implement this solution, we need to do following things:
- Modify the PersistedServiceJob.createRecurrence method to calculate and
store the UTC epoch milliseconds in the JobSandbox.runTimeEpoch field.
- Update the code responsible for polling and rescheduling jobs to use the
JobSandbox.runTimeEpoch field when it is set. If the field is not set, It
would fall back to getting the runtime date to filter the jobs.
By using this approach, the system should be able to handle recurring job
scheduling more reliably, especially when DST changes are involved, as it
ensures that all time comparisons are made in a consistent UTC format.
Thanks & Regards
--
Deepak Dixit
ofbiz.apache.org
On Tue, Oct 17, 2023 at 11:00 AM Deepak Dixit wrote:
Hi Dev,
I wanted to draw your attention to an issue we've encountered with the
OFBiz job scheduler, particularly when it comes to handling Daylight Saving
Time (DST) changes.
It appears that the job scheduler fails to create new recurring jobs when
DST ends, especially when the tempExprTypeId is set to FREQUENCY (e.g., 15
minutes, 30 minutes).
Upon further investigation, we've identified that the following condition
in PersistedServiceJob.createRecurrence might be the root of the issue:
java
if (next > startTime) {
// ...
// ...
}
I'm curious to know if anyone else has encountered a similar problem or if
you have any insights to share regarding this issue.
Thanks & Regards
--
Deepak Dixit
ofbiz.apache.org
Re: Issue with OFBiz Job Scheduler and Daylight Saving Time
Here is the task for reference
https://issues.apache.org/jira/browse/OFBIZ-12864
Thanks & Regards
--
Deepak Dixit
ofbiz.apache.org
On Mon, Oct 30, 2023 at 6:33 PM Deepak Dixit wrote:
> The issue occurs when DST changes, and OFBiz fails to schedule recurring
> jobs properly.
> This is due to a condition in the PersistedServiceJob.createRecurrence
> method where it compares the next scheduled time (next) with the start time
> (startTime) for the job.
>
>
> *Proposed Solution:*To address the issue, adding a new field named
> JobSandbox.runTimeEpoch. This field would store the UTC epoch milliseconds
> of the runtime date.
> When scheduling or rescheduling recurring jobs, the system would use the
> UTC epoch stored in JobSandbox.runTimeEpoch for recurring job comparison.
>
> This solution ensures that the system uses a consistent, UTC-based time
> for scheduling and rescheduling recurring jobs, even when DST changes
> affect the local time.
>
> To implement this solution, we need to do following things:
>
> - Modify the PersistedServiceJob.createRecurrence method to calculate and
> store the UTC epoch milliseconds in the JobSandbox.runTimeEpoch field.
> - Update the code responsible for polling and rescheduling jobs to use the
> JobSandbox.runTimeEpoch field when it is set. If the field is not set, It
> would fall back to getting the runtime date to filter the jobs.
>
> By using this approach, the system should be able to handle recurring job
> scheduling more reliably, especially when DST changes are involved, as it
> ensures that all time comparisons are made in a consistent UTC format.
>
>
> Thanks & Regards
> --
> Deepak Dixit
> ofbiz.apache.org
>
>
> On Tue, Oct 17, 2023 at 11:00 AM Deepak Dixit wrote:
>
>> Hi Dev,
>>
>> I wanted to draw your attention to an issue we've encountered with the
>> OFBiz job scheduler, particularly when it comes to handling Daylight Saving
>> Time (DST) changes.
>>
>> It appears that the job scheduler fails to create new recurring jobs when
>> DST ends, especially when the tempExprTypeId is set to FREQUENCY (e.g., 15
>> minutes, 30 minutes).
>>
>> Upon further investigation, we've identified that the following condition
>> in PersistedServiceJob.createRecurrence might be the root of the issue:
>>
>> java
>>
>> if (next > startTime) {
>> // ...
>> // ...
>> }
>>
>> I'm curious to know if anyone else has encountered a similar problem or
>> if you have any insights to share regarding this issue.
>>
>> Thanks & Regards
>>
>> --
>> Deepak Dixit
>> ofbiz.apache.org
>>
>
Re: Issue with OFBiz Job Scheduler and Daylight Saving Time
The issue occurs when DST changes, and OFBiz fails to schedule recurring
jobs properly.
This is due to a condition in the PersistedServiceJob.createRecurrence
method where it compares the next scheduled time (next) with the start time
(startTime) for the job.
*Proposed Solution:*To address the issue, adding a new field named
JobSandbox.runTimeEpoch. This field would store the UTC epoch milliseconds
of the runtime date.
When scheduling or rescheduling recurring jobs, the system would use the
UTC epoch stored in JobSandbox.runTimeEpoch for recurring job comparison.
This solution ensures that the system uses a consistent, UTC-based time for
scheduling and rescheduling recurring jobs, even when DST changes affect
the local time.
To implement this solution, we need to do following things:
- Modify the PersistedServiceJob.createRecurrence method to calculate and
store the UTC epoch milliseconds in the JobSandbox.runTimeEpoch field.
- Update the code responsible for polling and rescheduling jobs to use the
JobSandbox.runTimeEpoch field when it is set. If the field is not set, It
would fall back to getting the runtime date to filter the jobs.
By using this approach, the system should be able to handle recurring job
scheduling more reliably, especially when DST changes are involved, as it
ensures that all time comparisons are made in a consistent UTC format.
Thanks & Regards
--
Deepak Dixit
ofbiz.apache.org
On Tue, Oct 17, 2023 at 11:00 AM Deepak Dixit wrote:
> Hi Dev,
>
> I wanted to draw your attention to an issue we've encountered with the
> OFBiz job scheduler, particularly when it comes to handling Daylight Saving
> Time (DST) changes.
>
> It appears that the job scheduler fails to create new recurring jobs when
> DST ends, especially when the tempExprTypeId is set to FREQUENCY (e.g., 15
> minutes, 30 minutes).
>
> Upon further investigation, we've identified that the following condition
> in PersistedServiceJob.createRecurrence might be the root of the issue:
>
> java
>
> if (next > startTime) {
> // ...
> // ...
> }
>
> I'm curious to know if anyone else has encountered a similar problem or if
> you have any insights to share regarding this issue.
>
> Thanks & Regards
>
> --
> Deepak Dixit
> ofbiz.apache.org
>
Re: [VOTE] Apache OFBiz 18.12.09
+1 Thanks & Regards -- Deepak Dixit ofbiz.apache.org On Mon, Oct 30, 2023 at 3:45 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Thanks Jacopo, > > +1, all works for me > > Jacques > > Le 29/10/2023 à 13:16, Jacopo Cappellato a écrit : > > This is the vote thread to publish "Apache OFBiz 18.12.09", ninth > > release from the release18.12 branch. > > > > The release files can be downloaded from here: > > https://dist.apache.org/repos/dist/dev/ofbiz/ > > and are: > > * apache-ofbiz-18.12.09.zip > > * KEYS: text file with keys > > * apache-ofbiz-18.12.09.zip.asc: the detached signature file > > * apache-ofbiz-18.12.09.zip.sha512: checksum file > > > > Please download and test the zip file and its signatures (for > > instructions on testing the signatures see > > http://www.apache.org/info/verification.html). > > > > Vote: > > [ +1] release as Apache OFBiz 18.12.09 > > [ -1] do not release > > > > This vote is open for at least 5 days. > > > > For more details about this process please refer to > > http://www.apache.org/foundation/voting.html >
Re: [VOTE] Apache OFBiz 18.12.09
Thanks Jacopo, +1, all works for me Jacques Le 29/10/2023 à 13:16, Jacopo Cappellato a écrit : This is the vote thread to publish "Apache OFBiz 18.12.09", ninth release from the release18.12 branch. The release files can be downloaded from here: https://dist.apache.org/repos/dist/dev/ofbiz/ and are: * apache-ofbiz-18.12.09.zip * KEYS: text file with keys * apache-ofbiz-18.12.09.zip.asc: the detached signature file * apache-ofbiz-18.12.09.zip.sha512: checksum file Please download and test the zip file and its signatures (for instructions on testing the signatures see http://www.apache.org/info/verification.html). Vote: [ +1] release as Apache OFBiz 18.12.09 [ -1] do not release This vote is open for at least 5 days. For more details about this process please refer to http://www.apache.org/foundation/voting.html
