This version (2017/05/27 13:44) is a draft.
Approvals: 0/1

[12:48:10] <AlexLehm> temporalfox: I notice you removed the client boolean in NetSocketImpl, I wonder if that was used for something before and is not longer need

[13:01:48] <temporalfox> AlexLehm hi, it was not used by the NetSocketImpl

[13:01:53] <temporalfox> so it's more like cleanup

[13:02:15] <AlexLehm> es I thought so as well, i wasn't sure why it was in there :-)

[13:02:29] <AlexLehm> my Y key is not working properly

[13:03:15] <AlexLehm> i will try the tests I did for socks proxy, when that works, everything is ok from my side I would say

[13:04:56] <temporalfox> I only did it because intellij shown me :-)

[13:05:07] <temporalfox> great

[13:05:09] <temporalfox> let me know

[15:37:34] <dashu> im trying to use vertx mail with starttls.required. but i am not sending the mail to port 25 but to a docker container in which a postfix server is running and port 25 is mapped to port 2525 so i said the port in my mailconfig to port 2525 but then i get an ssl exception. can you guys help me ? i am stuck

[15:38:08] <dashu> typo i meant so i set the port in the mail config to 2525

[15:40:39] <dashu> i am using java

[15:40:41] <dashu> Caused by: No subject alternative names present

[15:41:04] <dashu> Caused by: General SSLEngine problem

[15:50:16] <AlexLehm> are you using a custom certificate or are you accessing a public server like ?

[15:50:59] <AlexLehm> java is enforcing subject alternative names for the certificate check, so if you have created a cert that only has the CN attribute, it will not be used

[15:52:16] <AlexLehm> if everything else fails, you could try with setTrustAll(true), if that works, it might be worth to look at the cert

[15:54:45] <dashu> yeah it kind of works :o but i get another error i look into it

[15:56:32] <dashu> recipient address not accepted

[15:56:47] <dashu> hm

[15:56:54] <dashu> it is a valid mailadress

[15:57:58] <AlexLehm> in the vertx code or on the mail server?

[16:04:17] <dashu> vertx i think

[16:05:14] <dashu> io.vertx.core.impl.NoStackTraceThrowable: recipient address not accepted: 554 5.7.1 <XXXX at XXXX dot de>: Recipient address rejected: Access denied

[16:05:52] <dashu> but it is strange the mail adress

[16:05:56] <dashu> is part of the bcc

[16:06:07] <dashu> not the real to recipient

[16:06:50] <dashu> ill test a not valid mail adress :o

[16:10:09] <dashu> hm

[16:12:44] <dashu> it works if i delete the bcc out of the json object :o

[16:12:56] <dashu> maybe something is wrong with my implementation

[16:22:12] <dashu> maybe the server just doesnt accept bcc ? is that possible ?

[16:25:24] <AlexLehm> the addresses including the bcc are sent to the server before the mail content is sent, so the server does not know if they were to or bcc at the point

[16:26:40] <AlexLehm> vertx-mail currently uses a simple regexp to check if addresses are valid, maybe it is missing some cases, however it should reject most invalid addresses

[16:27:02] <AlexLehm> otoh the server could explicitly deny some addresses, e.g. due to anti-spam rules

[16:28:09] <Lone_Rifle> hello, i'm sorry if this is not the right forum for this. I've filed a PR to rework some of the atomic operations in SharedDataImpl, and would like to receive a review of what i've done.

[16:28:15] <Lone_Rifle>

[16:30:14] <AlexLehm> dashu: if you like, send me the mail address as pm

[16:30:27] <AlexLehm> Lone_Rifle: best ask temporalfox

[16:31:40] <Lone_Rifle> AlexLehm: thanks. I think temporalfox remembers me; he let me sound him out about sending this PR

[16:31:45] <temporalfox> Lone_Rifle it seems good to me but I would like to check how it change contention on the shared data struture

[16:31:47] <Lone_Rifle> s/thiunk/hope/

[16:31:54] <temporalfox> so that would not go in 3.3.3 bur rather in 3.4.0

[16:32:05] <temporalfox> given that it does not make regression

[16:32:32] <temporalfox> but it really seems ok

[16:32:53] <Lone_Rifle> that's fine by me. I'm not actually a vert.x user, but I follow vertx-hazelcast quite closely

[16:33:02] <temporalfox> someone checked that maybe already ?

[16:33:17] <temporalfox> there are lot of discussion with vertx-hazelcast at the moment :-)

[16:33:38] <temporalfox> but now we are talking of in-jvm shared data

[16:34:21] <Lone_Rifle> temporalfox: yup. that happened to be something i spotted while browsing around the repo. I can't even remember how I stumbled upon in

[16:34:43] <temporalfox> that kind of things happens all the time :-)

[16:35:16] <Lone_Rifle> it might be me studying the LocalMap interface, since vertx-hazelcast provides its own cluster-dependent impl or something

[16:35:53] <temporalfox> HZ implements the vertx cluster manager

[16:36:50] <Lone_Rifle> ok, then i really have no idea why i was studying LocalMap =)

[16:37:03] <Lone_Rifle> (i'm not looking at the GitHub at the moment so i don't remember much detail)

[16:39:03] <temporalfox> becuase both are part of Shareddata

[16:39:10] <temporalfox> that provides both clustered and local shred data

[16:39:23] <temporalfox> Cluster Manager is the SPI implementd by HZ that clustred shared data uses

[16:39:31] <temporalfox> getClusterWideMap

[16:39:38] <temporalfox> versus

[16:39:39] <temporalfox> getLocalMap

[16:39:44] <Lone_Rifle> ah, thanks. that rings a bell now.

[16:40:32] <temporalfox> and locks are local

[16:40:33] <temporalfox> in non cluster

[16:40:42] <temporalfox> smae for counters

[16:42:48] <Lone_Rifle> heading out. thanks for fielding my query.

[16:47:23] <AlexLehm> temporalfox: i have run the socks-specific tests, that works correct after the merge

[16:48:08] <AlexLehm> i have run the build on linux and windows, doesn't have new failures

[16:48:24] <AlexLehm> so from my perspective its all good

[16:49:15] <dashu> thanks guys for all the help. i will just leave out the bcc part. it is not essential for my mail implementation

[16:49:24] <dashu> but thanks alot for the help

[16:50:22] <temporalfox> great AlexLehm

[16:56:16] <AlexLehm> i get a lot of failures because openssl is not available in windows, but that is probably a netty issue

[16:56:31] <AlexLehm> or i am missing some dll

[17:26:43] <dashu> another thing. <AlexLehm> if everything else fails, you could try with setTrustAll(true), if that works, it might be worth to look at the cert. is it worrying to use setTrustAll

[17:26:55] <dashu> '?

[17:27:30] <AlexLehm> worrying → working

[17:27:43] <AlexLehm> when the ssl cert stuff is not working, setTrustAll basically turns that off

[17:28:12] <msavy> you could also try switching on ssl debugging

[17:28:34] <msavy> e.g.

[17:28:52] <AlexLehm> temporalfox: the openssl problems in windows are probably a dll issue, we don't need to worry about that i guess, i will ask the netty people

[17:31:32] <temporalfox> where is this problem reported AlexLehm ?

[17:35:03] <AlexLehm> not yet, it occurs only when i run the unit tests locally, the ones with openssl fail

[17:35:13] <AlexLehm> or on windows CI

[18:29:04] <AlexLehm> temporalfox: , that is not a vertx related issue I think

[19:10:02] <temporalfox> it's a duplicate AlexLehm

[19:10:08] <temporalfox> cf norman's comment

[20:25:58] <AlexLehm> temporalfox: yes, i read the comment, i will try to run the tests with the snapshot version of netty

[20:38:40] <AlexLehm> temporalfox: ok, with the snapshot version, openssl works

[20:55:33] <temporalfox> so it's tcnative version 21 ?

[20:57:10] <AlexLehm> no, the error is in netty-common, i changed that to 4.1.6.Final-SNAPSHOT and it worked again

[20:59:02] <AlexLehm> we can probalby ignore that until 4.1.6 is finished and put it in the next version, this is not likely to affect anybody