> So, we need to inform the client that the
> error was caused by EntryProcessor. First option to do this: introduce
> new error code, second option: use dedicated "success" flag.
Thanks for the explanation. I lean towards a new error code for this.
On Wed, May 8, 2024 at 9:05 AM Alex Plehanov
Sameiksha, send email to dev-unsubscr...@ignite.apache.org if you are
no longer interested in Ignite dev list messages.
ср, 8 мая 2024 г. в 08:06, sameiksha kiran k :
>
> Can u please remove from this mail chain , this is so much unwanted mails
> in my inbox from ignite Apache mails
>
> On Tue,
Pavel, it's not about the stack trace, it's about the right exception
to be thrown to the user. JCache specifies that if any exception is
thrown by the EntryProcessor, this exception should be wrapped into
EntryProcessorException. So, we need to inform the client that the
error was caused by
Can u please remove from this mail chain , this is so much unwanted mails
in my inbox from ignite Apache mails
On Tue, May 7, 2024 at 10:35 PM Pavel Tupitsyn wrote:
> > In case of such response we need some new
> > error code to distinguish entry processor exceptions and general
> client/server
> In case of such response we need some new
> error code to distinguish entry processor exceptions and general
client/server exceptions.
I don't think we do this anywhere else (e.g. Compute).
Full stack trace should be present in the server logs, or sent back to the
client when
Hi Igniters!
I've prepared a proposal about implementation of invoke/invokeAll
cache operations for thin clients. All proposed changes to the
protocol and client API (currently for java thin client only) are
described in IEP-122 [1]
Please have a look and share your thoughts.
[1]
