anton-vinogradov commented on code in PR #13454:
URL: https://github.com/apache/ignite/pull/13454#discussion_r3745531948
##########
modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamProcessor.java:
##########
@@ -240,7 +235,10 @@ private void processRequest(final UUID nodeId, final
DataStreamerRequest req) {
StreamReceiver<?, ?> updater;
try {
- updater = U.unmarshal(marsh, req.updaterBytes(),
U.resolveClassLoader(clsLdr, ctx.config()));
+ // Read here, not on the inbound pass: the deployment class
loader is known only at this point.
+ MessageMarshalling.unmarshal(req, ctx, null,
U.resolveClassLoader(clsLdr, ctx.config()));
Review Comment:
The call stays external, but what it does is not the same.
Before, this line picked the marshaller itself — `marsh` was
`ctx.marshaller()` — and deserialized one particular field. That is what makes
a blob a hole for IGNITE-28940: the field decides its own marshaller, whatever
the transport decides. Now the processor only starts the read; which fields are
touched, and with which marshaller, is decided by the generated marshaller that
the message factory holds for this type (`@UseBinaryMarshaller` on
`StreamReceiverMessage` selects the schema-aware one). The processor no longer
knows that the receiver has a serialized form at all, and the entries of the
same request are read by the same pass.
What cannot become automatic here is the moment of the call. The message is
a `DeferredUnmarshalMessage`: its class loader is known only at this point —
the grid loader under forced local deployment, the sender's global deployment
otherwise — and a missing deployment has to travel back to the sender as a
response instead of being thrown on the inbound thread.
`GridEventStorageManager`, `GridJobProcessor`, `GridTaskWorker` and
`GridCacheIoManager` call `MessageMarshalling.unmarshal` explicitly for the
same reason.
##########
modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/StreamReceiverMessage.java:
##########
@@ -0,0 +1,59 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.ignite.internal.processors.datastreamer;
+
+import org.apache.ignite.internal.Marshalled;
+import org.apache.ignite.internal.Order;
+import org.apache.ignite.internal.UseBinaryMarshaller;
+import org.apache.ignite.plugin.extensions.communication.Message;
+import org.apache.ignite.stream.StreamReceiver;
+
+/**
+ * The receiver of a streamer on its way to the nodes that own the data: a
user object here, its serialized form on
+ * the wire. One instance serves every batch of a streamer, so the receiver is
marshalled once and the batches share
+ * the result; a streamer given another receiver builds another instance.
+ */
+@UseBinaryMarshaller
+public class StreamReceiverMessage implements Message {
+ /** */
+ @Marshalled("rcvrBytes")
+ StreamReceiver<?, ?> rcvr;
+
+ /**
+ * Serialized {@link #rcvr}, written by whichever batch is marshalled
first and read by the rest. Those batches
+ * leave on different threads, hence the {@code volatile}: a reader seeing
the reference before the contents would
+ * skip the marshalling and send a half-written array.
+ */
+ @Order(0)
+ volatile byte[] rcvrBytes;
Review Comment:
I don't think so: the marker means the opposite of what this class does.
`MarshallableMessage` declares `marshal(Marshaller)` and `unmarshal(Marshaller,
ClassLoader)` — it says "I carry a hand-written marshalling step, call it", and
the generated marshaller does exactly that, on top of the fields. Implementing
it here would mean writing that step by hand again, which is what this ticket
removes.
`StreamReceiverMessage` has no such step: the `@Marshalled` pair is what
makes the generator produce one. The other `@Marshalled` messages are the same
— `GridEventStorageRequest`, `GridJobExecuteRequest`, `StartRequestData`,
`GenericValueMessage` — none of them implements the interface.
If what you had in mind is the side effects the marker brings — the
marshaller becoming mandatory at registration, and `MessageUnmarshalOnceCheck`
covering the message — those would apply to every `@Marshalled` message
equally, so it reads as a codegen-level decision rather than a property of this
class. Happy to file it separately if you think the check should cover them.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
