Sending large files via AS4 takes minutes

[OysteinLq]

We haven't yet logged the numbers, but we're experiencing that sending fairly large documents (read: 30+ MB) can take minutes.

Is anyone else experiencing this?
Is there something to the AS4 protocol that just generally makes it slow, or is this an implementation detail that it might be possible to improve?

We're experiencing this in our production and test environments.
We've also pointed Oxalis Standalone at our test server, and seen that it too takes minutes and minutes on a large file.

(We're running on the same servers and network that we ran AS2 on, and haven't had any major issues of the same sort with that)

[FrodeBjerkholt]

Do you have an example file you can email to me?

[FrodeBjerkholt]

I have made myself a large file generator, so I have something to test with. I will get back to you later.

[OysteinLq]

Sorry about my late response -- we've been trying to get a better overview of the issue on our end. We have found that the speed does vary a lot between access points, so it can't be as simple as just an AS4/Oxalis issue.

E.g. transmitting a 200K file to endpoint A takes half a second, while to endpoint B takes 10 seconds. On increasing file sizes, we see a linear increase in transmission time, which obviously leads to a problem when sending a 78MB file to the endpoint B.

We have a number of sizable files (30 - 150 MB) that are more or less getting nowhere right now, so I figured it was worth checking around a bit, in case there was something /we/ could do, and also find out if others had problems of the same sort.

I made a test file of roughly 78 MB that I tried to send to our own test accesspoint, and it too took ages, hence why I started wondering if it was a more general issue.

[OysteinLq]

We have contacted the AP that's causing us most trouble in this regard. (nslookup shows us they're hosted in Azure, so we'll see how that goes)

Sorry if this is a waste of your time; it might not be as widespread an issue as we first thought.

[FrodeBjerkholt]

I see that MTOM is not enabled, so I will try experimenting with it next week, to see if I am able to speed up the sending time.

[FrodeBjerkholt]

I have some good news. It seems to be related to the SecurityProvider and the implementation of AES/GCM/NoPadding. When debugging I saw that it used the internal JDK provider, that seem to have a bad implementation for the decryption. When switching to BouncyCastle the speed is much faster and linear. On my development PC a 200mb file took 23s and 1gb file to just below 2 minutes. I need to do some more thorough testing, but hopefully I can make a new release on Monday. Without the switch a 20mb file to 23s.

[OysteinLq]

Wow, that's great news! Well done!

[FrodeBjerkholt]

Fixed in the 4.1.7 release