We've seen this before as well, it's a bug in the Celery Executor that has
a bunch of different manifestations.
There is at least one open issue relating to this bug:
https://issues.apache.org/jira/browse/AIRFLOW-1463
I have been working on a fix but it's likely to be a few more days before I
What version of airflow? From the top of my mind 1.8.X
1) we do use db locking
2) we check the state after we get the lock
3) I don't think the task sets a state if it finds out it is running somewhere
else
Maybe we do something at the executor/scheduler level. That I need to
investigate if
Can you check 1.8.1? 1.8.0 was a big release after a year so some thing slipped
though. Would be good to know if it persists on 1.8.1.
Bolke
Sent from my iPhone
> On 4 Aug 2017, at 21:02, Marc Weil wrote:
>
> This is on version 1.8.0. I don't recall seeing this behavior
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20170807T17Z
DTEND:20170807T183000Z
DTSTAMP:20170804T193255Z
ORGANIZER;CN=criccomini.apa...@gmail.com:mailto:criccomini.apa...@gmail.com
Good to know.
We do not ship it as part of the release, it would be downloaded at install
time. I misunderstood the ASF restriction as concerning parts which are
deemed essential to the functioning of the tool.
In this case python-nvd3 is used for some of the charting in Airflow, so as
long as
OK! I booked another meeting for Monday at 10am Pacific. Zoom link is in
the invite but just in case:
Join from PC, Mac, Linux, iOS or Android: https://wepay.zoom.us/j/620652517
Or iPhone one-tap (US Toll): +16465588656 <(646)%20558-8656>,,620652517#
or +14086380968
This particular behavior I was reporting isn't related to the browser. The
tasks remain in the incorrect state in the database as well.
On Fri, Aug 4, 2017 at 5:15 PM Arthur Wiedmer
wrote:
> I have noticed the issue more prominently with Chrome after v54, I was
>
I have noticed the issue more prominently with Chrome after v54, I was
wondering if this was related at all. Somehow, airflow seems kinder on
Firefox.
Does anyone else have a similar experience?
Best,
Arthur
On Fri, Aug 4, 2017 at 12:02 PM, Marc Weil wrote:
> This is on
Pretty sure (not 100%) what is happening is:
1. Scheduler bugs result in task getting scheduled twice
2. Worker 1 grabs task
3. Worker 2 grabs task
4. Worker 1 starts task
5. Worker 2 starts task
6. Worker 2 sees that Worker 1 has started and plans to abort
7. Worker 1
This is on version 1.8.0. I don't recall seeing this behavior when I was
running 1.7.x.
On Fri, Aug 4, 2017 at 2:58 PM Bolke de Bruin wrote:
> What version of airflow? From the top of my mind 1.8.X
>
> 1) we do use db locking
> 2) we check the state after we get the lock
> 3)
We don't "statically" link indeed GPL code and don't distribute it either. I
wonder why blue-yonder came to their conclusion (it is already in 1.7 as well).
Bolke
Sent from my iPhone
> On 4 Aug 2017, at 20:13, Arthur Wiedmer wrote:
>
> Good to know.
>
> We do not
reply.ics
Description: application/ics
A PR implementing this is here
https://github.com/apache/incubator-airflow/pull/2489
Cheers,
Diogo
On 30 July 2017 at 14:29, Diogo Franco wrote:
> Hi Maxime,
>
> Awesome, I also believe PythonSensor makes sense in the core package of
> course. These also allow
13 matches
Mail list logo