To followup, the TestListenSMTP timeout problems got much better when I changed a questionable DNS setting on the router. They still won't pass within the 5 seconds currently configured in the test, but it was a dramatic change.
I was glad to see I wasn't the only one with this problem. Aldrin and Pierre, are you building on Windows 10 before or after the anniversary update? On Mon, Aug 29, 2016 at 4:45 AM, Andy LoPresto <[email protected]> wrote: > Pierre and Andre, > > Thanks for reporting the issue where I forgot that some European and > Australian time zones are represented as 4 characters. Obviously the test > is overly specific with the regex, as the purpose is to ensure that the > first serialized line is the date and time, and that is still true. I'll > take a look at Andre's PR, but it should be an easy fix. Just another > example of i18n biting us. I'll make more of an effort to test with an eye > towards global users from now on. > > Andy LoPresto > [email protected] > [email protected] > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > > On Aug 28, 2016, at 22:47, Pierre Villard <[email protected]> > wrote: > > > > +1 (non-binding) > > > > Full build with contrib-check on Mac OSX, Windows 10 and CentOS 7. > > > > I had the same issue as reported by Joe on SMTP tests with Windows 10 > > build. Workaround with timeouts works. > > > > I also reported two minor issues related to timezones (NIFI-2682) / > locale > > (NIFI-2683) aspects. > > NIFI-2682 is a duplicate of NIFI-2688 created by Andre. > > > > I ran multiple workflows with a single instance and a three nodes > cluster. > > Checked failover scenario for clustering and exchanges with Kafka > > 0.8/0.9/0.10, with HDFS and with Hive. > > > > Great job! > > > > > > 2016-08-29 7:26 GMT+02:00 Andre <[email protected]>: > > > >> created NIFI-2688 and PR963(master) and PR964 (RC1) to address the regex > >> issue. > >> > >> > >> > >>> On Mon, Aug 29, 2016 at 3:07 PM, Andre <[email protected]> wrote: > >>> > >>> All, > >>> > >>> Had a look in the groovy code and reason is quite obvious: > >>> > >>> System locale does not match what the code expects via regex. > >> >
