This repository has been archived by the owner on Mar 16, 2022. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Wip upgrade to 2.6.x √ #293
Wip upgrade to 2.6.x √ #293
Changes from 2 commits
4fae978
0467e03
4e98b33
c5fa618
2fddf75
fb6e8f3
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Large diffs are not rendered by default.
This file was deleted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be modified. With the old version of protobuf that Akka used, the
equals
,hashCode
andtoString
implementations used reflection, which is why every method needed a reflection configuration. But the new protobuf version they're on, when configured to be optimized for speed (rather than bytecode size), generatesequals
,hashCode
andtoString
methods that don't use reflection. Furthermore, all of theakka.protobufv3.internal.*
subtypes, Akka never loads them or interacts with them using reflection, rather, Akka has hand coded serializers that convert the Akka types to these types statically, and uses short manifest names, rather than classnames, with static mappings of these names to the protobuf types, when deserializisng. So, we should be able to just removeakka.protobufv3.*
from here, no reflection configuration should be needed for it.We still do need some config for the Cloudstate messages that we expect to be serialized by the Akka protobuf serializer, but I think there might be some problems with the code below, the Akka protobuf serializer uses
parseFrom
andtoByteArray
reflectively, but I don't see those being registered. Also, not sure how much of an overhead this is going to be to have configuration for classes that don't need it, we have a lot of protobuf classes that don't get loaded reflectively, only those sent over Akka remoting as top level messages need reflection configuration, which is only a handful of messages.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jroper I'll try removing protobufv3 and report back
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jroper You were right! Removing the protobufv3 worked. I'll see if I can remove the need for the methods again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jroper It would be interesting to simplyfy this AutomaticFeature—but the challenge is the ridiculously long turnaround time to try even the smallest changes. Feel free (encouraged!) to find optimizations here! 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jroper @pvlugter We need to decide on what to choose for our usage—I have no idea and the documentation on the matter was not very helpful either. Right now it loads the NoopHostnameVerifier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Depends on what it's being used for.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@patriknw Do you have any suggestion what what hostname verifier we should be using?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is sslconfig. That isn't used for Akka remoting. It was deprecated in Akka 2.6. I would be surprised if it's used by Akka gRPC. @raboof do you know? Or is it still used in Akka HTTP?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
default in Akka 2.6, so not strictly needed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pvlugter @patriknw Probably best solved by a decision—given that we control all that runs in this, I thouht it important to keep number of threads down. If you both agree with this setting, then I can remove the comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's a valid choice for Cloudstate
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @patriknw!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
both these are default in Akka 2.6, so not strictly needed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pvlugter @patriknw Should we set these two new settings, and to what?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
default connection-timeout is 5s, so unless you think that is wrong you should start with defaults
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if you don't set hostname it will be
InetAddress.getLocalHost.getHostAddress
, maybe good to have that as an optional environment variable here?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pvlugter @patriknw These are here since they are a part of the migration docs, and I didn't want them to be forgotten, but I also don't know what to set them to. Advise?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove, and use defaults until you see a problem.
Only mentioned in migration guide because the defaults were changed (to better defaults).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And remove the built-in passivation using receive timeout. Looks like
cloudstate.proxy.passivation-timeout
is currently 30s. Could substitute that setting here.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pvlugter I suspect that we need to remove the receive timeout thing at the same time to not have competing timers?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, remove the receive timeout at the same time. Although, I can imagine that passivation timeouts is something that will want to be defined per entity type on the user side? Maybe this needs its own issue to be enhanced.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pvlugter Makes sense to make the change separately from this PR. (Hence the FIXME)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure. Would be good to capture in an issue then, rather than just a FIXME.