#haraka

morning

morning

[13Haraka] 15smfreegard pushed 1 new commit to 06master: 02https://github.com/haraka/Haraka/commit/0da1a...

13Haraka/06master 140da1afb 15Matt Simerson: add node.js version to issue template (#1643)

baudehlo: can you take a quick glance at #1639 when you get a chance.

Yeah that seems wrong, and just breaks graceful shutdown, no?

baudehlo: Nope; as it stands, if you run the current code in master; it never exits gracefully in non-cluster mode. It always hits the timeout.

With this, it does. You don't need the unref()'s because worker.disconnect() always calls server.close()

And in non-cluster mode; I call it implicitly to do the same.

OK

baudehlo: didn't realise until now but node 4.x made process.send and worker.send async: https://github.com/nodejs/node/commit/56d9584a0...

_smf_: probably fine then. I assume all that code is just where it's non-clustered then?

(testing that stuff is a nightmare btw).

Yeah

It looked pretty tricky.

I've tested it pretty thoroughly in both clustered and non-clustered modes and it works fine here.

as long as it actually gracefully DTRT when a connection is present, it's all good.

Yeah; tested both, if there's a connection active - it doesn't exit until it completes or the timer fires.

That didn't work in non-clustered before, it would always fail and have to wait for the timer.

ok

Looks like Zone MTA is really coming along too.

I'm still confused why andris felt the need to create that - he knew about Haraka.

NIH syndrome

He's added a comment in the README now.

Some of it cleans up a lot of the mistakes I feel I made in Haraka design.

like a plugin's register() method not having a callback.

[13Haraka] 15msimerson pushed 1 new commit to 06master: 02https://github.com/haraka/Haraka/commit/34fec...

13Haraka/06master 1434fecb2 15Steve Freegard: Tidy-up graceful shutdown and fix for non-cluster mode (#1639)

_smf_: app.addRewriteHook(filter, handler);

filter is a function that is called for every found mime node. If the function returns true, than this node will be processed, otherwise it is skipped. The function gets two arguments: envelope and node

So basically the same way we do things with attachments, only better.

basically it's a filter that gets a read stream and a write stream as params.

baudehlo: yeah; that's basically what I was suggesting the other day that we do.

Ideally we'd have a Input stream -> decode stream (QP/Base64) -> (optional) Modifier stream -> Re-encode Stream -> Output stream

The input -> decode streams would automatically be connected directly to the output stream *unless* we have modifier filters that need to change something.

It's simply a question of how to do it efficiently whilst making the API as simple to use as possible.

exactly.

I mean we basically already do all this stuff, just without streams.

*nod*

The problem I can see is that our current plugin infrastructure doesn't lend itself to streams.

e.g. All the hook_data_post plugins that require access to the data, would need to be in a stream pipeline.

And that implies that they'd run concurrently instead of how we do it now.

well bannering and attachment processing both require setting up in that manner, so it's not all bad.

Yeah

[13Haraka] 15msimerson 04deleted 06outbound_pool_bugfix at 140055085: 02https://github.com/haraka/Haraka/commit/0055085

[13Haraka] 15msimerson opened pull request #1644: remove ./net_utils to haraka-net-utils (06master...06external-net-utils) 02https://github.com/haraka/Haraka/pull/1644