Identifying grid transactions

[Alexey Inozemtsev]

Igniters,
A team I'm working with uses Apache Ignite massively.
There are many application modules using the cluster.
We've faced a problem on how to identify the external app
modules which keep transactions open in the grid.
Right now we have to restart client nodes to get reed of them.

Is there a parameter on Ignite transaction to (ala MODULE in Oracle) which
can be set on a client side?
Are there other ways to manage such a situation?

Have a nice day,
Alexey

[Alexei Scherbakov]

Alexey,

Simplest way: wrap IgniteTransactions instance returned by
ignite.transactions() with delegate using advanced logging capabilities for
tx* methods, like current thread and stack trace.

There is no notion of transaction parameters.

2017-10-04 12:40 GMT+03:00 Alexey Inozemtsev <[hidden email]>:

> Igniters,
> A team I'm working with uses Apache Ignite massively.
> There are many application modules using the cluster.
> We've faced a problem on how to identify the external app
> modules which keep transactions open in the grid.
> Right now we have to restart client nodes to get reed of them.
>
> Is there a parameter on Ignite transaction to (ala MODULE in Oracle) which
> can be set on a client side?
> Are there other ways to manage such a situation?
>
> Have a nice day,
> Alexey
>

--

Best regards,
Alexei Scherbakov

[Alexey Inozemtsev]

Alexey, thanks a lot!
This requires a change in application code.
Is there a way to do it without that?

Alexey

2017-10-04 13:22 GMT+03:00 Alexei Scherbakov <[hidden email]>:

> Alexey,
>
> Simplest way: wrap IgniteTransactions instance returned by
> ignite.transactions() with delegate using advanced logging capabilities for
> tx* methods, like current thread and stack trace.
>
> There is no notion of transaction parameters.
>
> 2017-10-04 12:40 GMT+03:00 Alexey Inozemtsev <[hidden email]
> >:
>
> > Igniters,
> > A team I'm working with uses Apache Ignite massively.
> > There are many application modules using the cluster.
> > We've faced a problem on how to identify the external app
> > modules which keep transactions open in the grid.
> > Right now we have to restart client nodes to get reed of them.
> >
> > Is there a parameter on Ignite transaction to (ala MODULE in Oracle)
> which
> > can be set on a client side?
> > Are there other ways to manage such a situation?
> >
> > Have a nice day,
> > Alexey
> >
>
>
>
> --
>
> Best regards,
> Alexei Scherbakov
>

[Vladimir Ozerov]

Alex,

I do not think we have such feature in the product at the moment. But this
could be very valuable addition. For example, we have somewhat similar task
for JDBC - to track applications that use the driver [1]. We can think of
adding a single optional string to transaction protocol, so that we can
track application/module on any node. E.g.:

IgniteTransactions transactions = ignite.transactions().withApplication("
*myApp:myModule*");

And then all usages of this facade will propagate application to all nodes.

Thoughts?

[1] https://issues.apache.org/jira/browse/IGNITE-5453

On Wed, Oct 4, 2017 at 1:22 PM, Alexei Scherbakov <
[hidden email]> wrote:

> Alexey,
>
> Simplest way: wrap IgniteTransactions instance returned by
> ignite.transactions() with delegate using advanced logging capabilities for
> tx* methods, like current thread and stack trace.
>
> There is no notion of transaction parameters.
>
> 2017-10-04 12:40 GMT+03:00 Alexey Inozemtsev <[hidden email]
> >:
>
> > Igniters,
> > A team I'm working with uses Apache Ignite massively.
> > There are many application modules using the cluster.
> > We've faced a problem on how to identify the external app
> > modules which keep transactions open in the grid.
> > Right now we have to restart client nodes to get reed of them.
> >
> > Is there a parameter on Ignite transaction to (ala MODULE in Oracle)
> which
> > can be set on a client side?
> > Are there other ways to manage such a situation?
> >
> > Have a nice day,
> > Alexey
> >
>
>
>
> --
>
> Best regards,
> Alexei Scherbakov
>

[dsetrakyan]

I would rename to "withMetadata()".

On Wed, Oct 4, 2017 at 2:31 PM, Vladimir Ozerov <[hidden email]>
wrote:

> Alex,
>
> I do not think we have such feature in the product at the moment. But this
> could be very valuable addition. For example, we have somewhat similar task
> for JDBC - to track applications that use the driver [1]. We can think of
> adding a single optional string to transaction protocol, so that we can
> track application/module on any node. E.g.:
>
> IgniteTransactions transactions = ignite.transactions().withApplication("
> *myApp:myModule*");
>
> And then all usages of this facade will propagate application to all nodes.
>
> Thoughts?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-5453
>
> On Wed, Oct 4, 2017 at 1:22 PM, Alexei Scherbakov <
> [hidden email]> wrote:
>
> > Alexey,
> >
> > Simplest way: wrap IgniteTransactions instance returned by
> > ignite.transactions() with delegate using advanced logging capabilities
> for
> > tx* methods, like current thread and stack trace.
> >
> > There is no notion of transaction parameters.
> >
> > 2017-10-04 12:40 GMT+03:00 Alexey Inozemtsev <
> [hidden email]
> > >:
> >
> > > Igniters,
> > > A team I'm working with uses Apache Ignite massively.
> > > There are many application modules using the cluster.
> > > We've faced a problem on how to identify the external app
> > > modules which keep transactions open in the grid.
> > > Right now we have to restart client nodes to get reed of them.
> > >
> > > Is there a parameter on Ignite transaction to (ala MODULE in Oracle)
> > which
> > > can be set on a client side?
> > > Are there other ways to manage such a situation?
> > >
> > > Have a nice day,
> > > Alexey
> > >
> >
> >
> >
> > --
> >
> > Best regards,
> > Alexei Scherbakov
> >
>

[Sergey Kozlov]

Hi

.withApplication and .withMetatData may narrow use case. Looks like .
withDescription can have more sense and allow use write any information
valuable for further debugging.

On Wed, Oct 4, 2017 at 2:47 PM, Dmitriy Setrakyan <[hidden email]>
wrote:

> I would rename to "withMetadata()".
>
> On Wed, Oct 4, 2017 at 2:31 PM, Vladimir Ozerov <[hidden email]>
> wrote:
>
> > Alex,
> >
> > I do not think we have such feature in the product at the moment. But
> this
> > could be very valuable addition. For example, we have somewhat similar
> task
> > for JDBC - to track applications that use the driver [1]. We can think of
> > adding a single optional string to transaction protocol, so that we can
> > track application/module on any node. E.g.:
> >
> > IgniteTransactions transactions = ignite.transactions().
> withApplication("
> > *myApp:myModule*");
> >
> > And then all usages of this facade will propagate application to all
> nodes.
> >
> > Thoughts?
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-5453
> >
> > On Wed, Oct 4, 2017 at 1:22 PM, Alexei Scherbakov <
> > [hidden email]> wrote:
> >
> > > Alexey,
> > >
> > > Simplest way: wrap IgniteTransactions instance returned by
> > > ignite.transactions() with delegate using advanced logging capabilities
> > for
> > > tx* methods, like current thread and stack trace.
> > >
> > > There is no notion of transaction parameters.
> > >
> > > 2017-10-04 12:40 GMT+03:00 Alexey Inozemtsev <
> > [hidden email]
> > > >:
> > >
> > > > Igniters,
> > > > A team I'm working with uses Apache Ignite massively.
> > > > There are many application modules using the cluster.
> > > > We've faced a problem on how to identify the external app
> > > > modules which keep transactions open in the grid.
> > > > Right now we have to restart client nodes to get reed of them.
> > > >
> > > > Is there a parameter on Ignite transaction to (ala MODULE in Oracle)
> > > which
> > > > can be set on a client side?
> > > > Are there other ways to manage such a situation?
> > > >
> > > > Have a nice day,
> > > > Alexey
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > Best regards,
> > > Alexei Scherbakov
> > >
> >
>

--
Sergey Kozlov
GridGain Systems
www.gridgain.com

[Константин Дудков]

Hi,

.withTag maybe?

04/10/2017 14:52, Sergey Kozlov пишет:

> Hi
>
> .withApplication and .withMetatData may narrow use case. Looks like .
> withDescription can have more sense and allow use write any information
> valuable for further debugging.
>
> On Wed, Oct 4, 2017 at 2:47 PM, Dmitriy Setrakyan <[hidden email]>
> wrote:
>
>> I would rename to "withMetadata()".
>>
>> On Wed, Oct 4, 2017 at 2:31 PM, Vladimir Ozerov <[hidden email]>
>> wrote:
>>
>>> Alex,
>>>
>>> I do not think we have such feature in the product at the moment. But
>> this
>>> could be very valuable addition. For example, we have somewhat similar
>> task
>>> for JDBC - to track applications that use the driver [1]. We can think of
>>> adding a single optional string to transaction protocol, so that we can
>>> track application/module on any node. E.g.:
>>>
>>> IgniteTransactions transactions = ignite.transactions().
>> withApplication("
>>> *myApp:myModule*");
>>>
>>> And then all usages of this facade will propagate application to all
>> nodes.
>>>
>>> Thoughts?
>>>
>>> [1] https://issues.apache.org/jira/browse/IGNITE-5453
>>>
>>> On Wed, Oct 4, 2017 at 1:22 PM, Alexei Scherbakov <
>>> [hidden email]> wrote:
>>>
>>>> Alexey,
>>>>
>>>> Simplest way: wrap IgniteTransactions instance returned by
>>>> ignite.transactions() with delegate using advanced logging capabilities
>>> for
>>>> tx* methods, like current thread and stack trace.
>>>>
>>>> There is no notion of transaction parameters.
>>>>
>>>> 2017-10-04 12:40 GMT+03:00 Alexey Inozemtsev <
>>> [hidden email]
>>>>> :
>>>>
>>>>> Igniters,
>>>>> A team I'm working with uses Apache Ignite massively.
>>>>> There are many application modules using the cluster.
>>>>> We've faced a problem on how to identify the external app
>>>>> modules which keep transactions open in the grid.
>>>>> Right now we have to restart client nodes to get reed of them.
>>>>>
>>>>> Is there a parameter on Ignite transaction to (ala MODULE in Oracle)
>>>> which
>>>>> can be set on a client side?
>>>>> Are there other ways to manage such a situation?
>>>>>
>>>>> Have a nice day,
>>>>> Alexey
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Best regards,
>>>> Alexei Scherbakov
>>>>
>>>
>>
>
>
>

--
Regards, Konstantin.

[Vladimir Ozerov]

Sergey,

Do you mean attaching something more than a single String?

On Wed, Oct 4, 2017 at 3:01 PM, Konstantin Dudkov <[hidden email]> wrote:

> Hi,
>
> .withTag maybe?
>
> 04/10/2017 14:52, Sergey Kozlov пишет:
>
> Hi
>>
>> .withApplication and .withMetatData may narrow use case. Looks like .
>> withDescription can have more sense and allow use write any information
>> valuable for further debugging.
>>
>> On Wed, Oct 4, 2017 at 2:47 PM, Dmitriy Setrakyan <[hidden email]>
>> wrote:
>>
>> I would rename to "withMetadata()".
>>>
>>> On Wed, Oct 4, 2017 at 2:31 PM, Vladimir Ozerov <[hidden email]>
>>> wrote:
>>>
>>> Alex,
>>>>
>>>> I do not think we have such feature in the product at the moment. But
>>>>
>>> this
>>>
>>>> could be very valuable addition. For example, we have somewhat similar
>>>>
>>> task
>>>
>>>> for JDBC - to track applications that use the driver [1]. We can think
>>>> of
>>>> adding a single optional string to transaction protocol, so that we can
>>>> track application/module on any node. E.g.:
>>>>
>>>> IgniteTransactions transactions = ignite.transactions().
>>>>
>>> withApplication("
>>>
>>>> *myApp:myModule*");
>>>>
>>>> And then all usages of this facade will propagate application to all
>>>>
>>> nodes.
>>>
>>>>
>>>> Thoughts?
>>>>
>>>> [1] https://issues.apache.org/jira/browse/IGNITE-5453
>>>>
>>>> On Wed, Oct 4, 2017 at 1:22 PM, Alexei Scherbakov <
>>>> [hidden email]> wrote:
>>>>
>>>> Alexey,
>>>>>
>>>>> Simplest way: wrap IgniteTransactions instance returned by
>>>>> ignite.transactions() with delegate using advanced logging capabilities
>>>>>
>>>> for
>>>>
>>>>> tx* methods, like current thread and stack trace.
>>>>>
>>>>> There is no notion of transaction parameters.
>>>>>
>>>>> 2017-10-04 12:40 GMT+03:00 Alexey Inozemtsev <
>>>>>
>>>> [hidden email]
>>>>
>>>>> :
>>>>>>
>>>>>
>>>>> Igniters,
>>>>>> A team I'm working with uses Apache Ignite massively.
>>>>>> There are many application modules using the cluster.
>>>>>> We've faced a problem on how to identify the external app
>>>>>> modules which keep transactions open in the grid.
>>>>>> Right now we have to restart client nodes to get reed of them.
>>>>>>
>>>>>> Is there a parameter on Ignite transaction to (ala MODULE in Oracle)
>>>>>>
>>>>> which
>>>>>
>>>>>> can be set on a client side?
>>>>>> Are there other ways to manage such a situation?
>>>>>>
>>>>>> Have a nice day,
>>>>>> Alexey
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Best regards,
>>>>> Alexei Scherbakov
>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
> --
> Regards, Konstantin.
>

[Sergey Kozlov]

No I meant just a string

p.s. .withTag looks better

On Wed, Oct 4, 2017 at 3:08 PM, Vladimir Ozerov <[hidden email]>
wrote:

> Sergey,
>
> Do you mean attaching something more than a single String?
>
> On Wed, Oct 4, 2017 at 3:01 PM, Konstantin Dudkov <[hidden email]> wrote:
>
> > Hi,
> >
> > .withTag maybe?
> >
> > 04/10/2017 14:52, Sergey Kozlov пишет:
> >
> > Hi
> >>
> >> .withApplication and .withMetatData may narrow use case. Looks like .
> >> withDescription can have more sense and allow use write any information
> >> valuable for further debugging.
> >>
> >> On Wed, Oct 4, 2017 at 2:47 PM, Dmitriy Setrakyan <
> [hidden email]>
> >> wrote:
> >>
> >> I would rename to "withMetadata()".
> >>>
> >>> On Wed, Oct 4, 2017 at 2:31 PM, Vladimir Ozerov <[hidden email]>
> >>> wrote:
> >>>
> >>> Alex,
> >>>>
> >>>> I do not think we have such feature in the product at the moment. But
> >>>>
> >>> this
> >>>
> >>>> could be very valuable addition. For example, we have somewhat similar
> >>>>
> >>> task
> >>>
> >>>> for JDBC - to track applications that use the driver [1]. We can think
> >>>> of
> >>>> adding a single optional string to transaction protocol, so that we
> can
> >>>> track application/module on any node. E.g.:
> >>>>
> >>>> IgniteTransactions transactions = ignite.transactions().
> >>>>
> >>> withApplication("
> >>>
> >>>> *myApp:myModule*");
> >>>>
> >>>> And then all usages of this facade will propagate application to all
> >>>>
> >>> nodes.
> >>>
> >>>>
> >>>> Thoughts?
> >>>>
> >>>> [1] https://issues.apache.org/jira/browse/IGNITE-5453
> >>>>
> >>>> On Wed, Oct 4, 2017 at 1:22 PM, Alexei Scherbakov <
> >>>> [hidden email]> wrote:
> >>>>
> >>>> Alexey,
> >>>>>
> >>>>> Simplest way: wrap IgniteTransactions instance returned by
> >>>>> ignite.transactions() with delegate using advanced logging
> capabilities
> >>>>>
> >>>> for
> >>>>
> >>>>> tx* methods, like current thread and stack trace.
> >>>>>
> >>>>> There is no notion of transaction parameters.
> >>>>>
> >>>>> 2017-10-04 12:40 GMT+03:00 Alexey Inozemtsev <
> >>>>>
> >>>> [hidden email]
> >>>>
> >>>>> :
> >>>>>>
> >>>>>
> >>>>> Igniters,
> >>>>>> A team I'm working with uses Apache Ignite massively.
> >>>>>> There are many application modules using the cluster.
> >>>>>> We've faced a problem on how to identify the external app
> >>>>>> modules which keep transactions open in the grid.
> >>>>>> Right now we have to restart client nodes to get reed of them.
> >>>>>>
> >>>>>> Is there a parameter on Ignite transaction to (ala MODULE in Oracle)
> >>>>>>
> >>>>> which
> >>>>>
> >>>>>> can be set on a client side?
> >>>>>> Are there other ways to manage such a situation?
> >>>>>>
> >>>>>> Have a nice day,
> >>>>>> Alexey
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> Best regards,
> >>>>> Alexei Scherbakov
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> >>
> >>
> > --
> > Regards, Konstantin.
> >
>

--
Sergey Kozlov
GridGain Systems
www.gridgain.com

[dsetrakyan]

On Wed, Oct 4, 2017 at 3:01 PM, Konstantin Dudkov <[hidden email]> wrote:

> Hi,
>
> .withTag maybe?
>

Agree, withTag() looks much better.

[yzhdanov]

Really like .withTag() suggestion!

--Yakov

[Vladimir Ozerov]

+1 for withTag()

ср, 4 окт. 2017 г. в 17:19, Yakov Zhdanov <[hidden email]>:

> Really like .withTag() suggestion!
>
> --Yakov
>

[Valentin Kulichenko]

That's a very useful suggestion. Can it be supported for other APIs as
well, not only transactions?

-Val

On Wed, Oct 4, 2017 at 12:47 PM, Vladimir Ozerov <[hidden email]>
wrote:

> +1 for withTag()
>
> ср, 4 окт. 2017 г. в 17:19, Yakov Zhdanov <[hidden email]>:
>
> > Really like .withTag() suggestion!
> >
> > --Yakov
> >
>

[Dmitriy Pavlov]

Hi Igniters,

Would it be useful to provide some traceability identifier for messages
participating in the partition map exchange? This can be used to filter all
logs associated with the exchange. Or now there is some possibility?

Sincerely,
Dmitriy Pavlov

чт, 5 окт. 2017 г. в 2:01, Valentin Kulichenko <
[hidden email]>:

> That's a very useful suggestion. Can it be supported for other APIs as
> well, not only transactions?
>
> -Val
>
> On Wed, Oct 4, 2017 at 12:47 PM, Vladimir Ozerov <[hidden email]>
> wrote:
>
> > +1 for withTag()
> >
> > ср, 4 окт. 2017 г. в 17:19, Yakov Zhdanov <[hidden email]>:
> >
> > > Really like .withTag() suggestion!
> > >
> > > --Yakov
> > >
> >
>

[yzhdanov]

>>That's a very useful suggestion. Can it be supported for other APIs as
>> well, not only transactions?

>> -Val

Val, please clarify. What APIs do you mean?

--Yakov

[Valentin Kulichenko]

Yakov,

Ideally - all of them :) Or at least those APIs that execute remote
operations (all cache operations, compute, service proxy invocations, ...).
Having an ability to add custom metadata to this kind of operations can be
very valuable for auditing purposes.

-Val

On Thu, Oct 5, 2017 at 8:38 AM, Yakov Zhdanov <[hidden email]> wrote:

> >>That's a very useful suggestion. Can it be supported for other APIs as
> >> well, not only transactions?
>
> >> -Val
>
> Val, please clarify. What APIs do you mean?
>
> --Yakov
>

[yzhdanov]

Val, I really like your idea to implement common mechanism for all APIs.
Can you please file a ticket?

--Yakov

[Valentin Kulichenko]

Yakov,

Here is the ticket: https://issues.apache.org/jira/browse/IGNITE-6847

Feel free to add if I missed anything.

-Val

On Tue, Oct 10, 2017 at 3:22 AM, Yakov Zhdanov <[hidden email]> wrote:

> Val, I really like your idea to implement common mechanism for all APIs.
> Can you please file a ticket?
>
> --Yakov
>