Call remote tasks of service workspace #75
No reviewers
Labels
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: kscience/dataforge-core#75
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "winter-yuki/distributed"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Remote tasks can be called now
Remove debug print
Use
ConnectionPool
Some comments, not a final review (had not time to read the second part.
Coroutines are alredy in dataforge-context
Should not be in basic workspace module. Should be a separate module.
Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
There is already WorkspacePlugin that does similar thing.
Is it possible to avoid the cast? For example specialize output for this workspace?
Better to pass Adress from outside instead of constructor initialization.
Why?
There is existing one
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:
WorkspacePlugin
is also aTaskContainer
, which I did not want to.ClientPlugin
is just a port to existing remote plugin and has no tasks locally.I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole
Yes, but it is private for some reason
All contributions should target
dev
, so please resolve conflicts.Major cleanup is required.
You can switch to 0.6 branch. It fixes problems with needless suspend factory functions and introduces context receivers.
I still do not understand why do we need wrappers for plaguns. Plagins are only a way to load tasks into workspace. Ther should be a wrapper for a task, not a plugin.
DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
Need to think about better naming
Why not suspended?
Is it possible to replace manual 'Coder's with KSerializer or IOFormat? Or make converters?
There is existing class for that
@ -0,0 +13,4 @@
* [Data] representation that is trivially serializable.
*/
@Serializable
internal data class DataPrototype(
This is unusable. I believe that it should be something like this:
Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
switch to runTest
I thought about
WorkspaceNode
orWorkerWorkspace
. There is alsoDistributedWorkspace
but it is not truly distributed itself.Also
ServiceWorkpace
is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
Yes, it already exist, I just forgot about it.
This function is not available in dataforge, shall I add some dependency to the project?
When
ServiceWorkspace.execute
returns result to the client, it do not know yet about serializer for theT
. ThenRemoteTask
uses serializer to deserialize DataSet from prototype.But where should endpoints for the tasks be provided? Seems that task declaration is not good enough place. Should I use Meta for this?
@winter-yuki is it ready for review?
No, I need a bit of time. Maybe tomorrow will be ready, I'll rerequest review
Maybe I should also do:
square wire
to remove lambdarpc dependency. But I failed to add it's plugin to the project, gradlle cannot find it and seems that it does not know any plugins repo at all. Meybe it is mpp plugin issue.@ -0,0 +27,4 @@
private val dataSerializer: KSerializer<Any>? = null,
data: DataSet<*> = DataTree<Any>(),
targets: Map<String, Meta> = mapOf(),
) : Workspace by RemoteTaskWorkspace(context, data, targets), ServiceWorkspace {
Why do we need such complex construct. Isn't it possible to add a simple wrapper by adding a connection and serializator resolver. Something like this for server:.
And for client:
We can add a
close
method to a generic Workspace to handle the lifecycle.@ -0,0 +12,4 @@
/**
* [Workspace] that can expose its tasks to other workspaces as a service.
*/
public interface ServiceWorkspace : Workspace, Closeable {
I do not see, why we need it in the API on the server side the connection should be closeable, not the workspace. Maybe you should rename it to connection and remove inheritance from a workspace?
@ -0,0 +13,4 @@
* [Data] representation that is trivially serializable.
*/
@Serializable
internal data class DataPrototype(
Is it used somewhere?
@ -0,0 +19,4 @@
* [DataSet] representation that is trivially serializable.
*/
@Serializable
internal data class DataSetPrototype(val meta: Meta, val data: Map<String, DataPrototype>) {
Do we need that?
@ -0,0 +26,4 @@
@BeforeAll
fun before() = runBlocking {
worker1 = NodeWorkspace(
context = Global.buildContext("worker1".asName()) {
This is outdated, use
Context()
factory function instead.Pull request closed