ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Goncharuk <alexey.goncha...@gmail.com>
Subject Re: Monitoring of active transactions
Date Thu, 05 Oct 2017 10:24:07 GMT
Guys,

I think we should not limit this functionality to http-rest only. We should
add this information to one of the MBeans as the primary information
source. Then this should be added as a client command both to http-rest and
binary-rest endpoints, so the information is available through different
tools.

Thoughts?

2017-09-28 13:35 GMT+03:00 Sasha Belyak <rtsforex@gmail.com>:

> It's very useful, but I often we need to get list of hang transaction when
> exchange stopped by some reason and in this case utility, based on client
> node won't help. I rewrite it as ComputeTask with default constructor, add
> jar into ignite libs, activate http rest api and now it can be used from
> console and no need to update cluster topology:
>
> curl '
> http://127.0.0.1:8080/ignite?cmd=exe&name=org.apache.ignite.txviewer.
> RestCollectTxInfoTask&p1=false&p2=100
> '
>
> {"successStatus":0,"sessionToken":null,"error":null,"response":{"id":"~
> 98391a83-3d76-4e5e-b0c3-185cf2bd4acd","finished":true,
> "error":null,"result":[{"nearXidVersion":"GridCacheVersion
> [topVer=118063514, order=1506583525449,
> nodeOrder=2]","nodeId":"baa0237e-707c-4b69-abb6-
> 555a2fc17762","nodeString":"TcpDiscoveryNode
> [id=baa0237e-707c-4b69-abb6-555a2fc17762, addrs=[0:0:0:0:0:0:0:1%1,
> 10.0.3.1, 10.38.176.253, 10.42.1.107, 127.0.0.1, 172.17.0.1], sockAddrs=[/
> 127.0.0.1:0, /10.42.1.107:0, /0:0:0:0:0:0:0:1%1:0, /172.17.0.1:0, /
> 10.38.176.253:0, /10.0.3.1:0], discPort=0, order=2, intOrder=0,
> lastExchangeTime=1506583525683, loc=true, ver=2.1.5#20170922-sha1:
> 6452201d,
> isClient=true]","threadId":1,"startTime":"Thu Sep 28 14:25:27 NOVT
> 2017","entries":[{"cache":"txCache","key":"1","value":"1"
> ,"operation":"CREATE"}]}]}}
>
> Even better if this tool can use binary rest too. I mean that we should be
> able to run this collecting task from:
> 1) http rest api by curl/wget (but must deploy class somehow before, by
> peerClassLoad with Continues mode or by adding it to application classpash)
> Good for admin's console scripting.
> 2) binary rest api by some java tool (with instant peerClassLoading). Good
> for investigation on any grid configuration.
> 3) maybe, by client node as it implemented now (can't see any adwantages)
>
>
> 2017-09-16 5:35 GMT+07:00 Dmitry Pavlov <dpavlov.spb@gmail.com>:
>
> > Hi Ilya,
> >
> > I can help with including this utility into build/release, I've recenty
> > finished same steps for PDS WAL analysing tool for converting records to
> > human readable format.
> > Please feel free to contact me.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > пт, 15 сент. 2017 г. в 6:37, Dmitriy Setrakyan <dsetrakyan@apache.org>:
> >
> > > It seems that the community (including me) really would like to see
> this
> > > feature in Ignite.
> > >
> > > Ilya, can you create a ticket and submit it for review?
> > >
> > > D.
> > >
> > > On Fri, Sep 8, 2017 at 7:15 AM, Anton Vinogradov <av@apache.org>
> wrote:
> > >
> > > > Ilya,
> > > >
> > > > We extremely need this!
> > > >
> > > > Txs and Locks info should be collected on each cluster hang.
> > > > We already have an issue related to this problem -
> > > > https://issues.apache.org/jira/browse/IGNITE-4937
> > > >
> > > > Nikolay,
> > > >
> > > > Good point,
> > > > but, seems you should start separate thread to discuss this.
> > > >
> > > > On Fri, Sep 8, 2017 at 4:28 PM, Dmitry Pavlov <dpavlov.spb@gmail.com
> >
> > > > wrote:
> > > >
> > > > > Hi Ilya,
> > > > >
> > > > > I'm definitely +1 for including the utility in the product. Perfect
> > > > > contribution.
> > > > >
> > > > > Sincerely,
> > > > > Dmitriy Pavlov
> > > > >
> > > > > пт, 8 сент. 2017 г. в 14:28, Ilya Lantukh <ilantukh@gridgain.com>:
> > > > >
> > > > > > Igniters,
> > > > > >
> > > > > > According to our current design and implementation, unclosed
> > > > transaction
> > > > > or
> > > > > > unreleased lock can hang ignite cluster forever. This is logical,
> > and
> > > > > with
> > > > > > correct usage of those mechanics such issue should never happen,
> in
> > > > real
> > > > > > world developers can make mistakes and leave transaction open.
We
> > > have
> > > > a
> > > > > > feature "transaction timeout", but turns out it doesn't work
in
> all
> > > > cases
> > > > > > (see https://issues.apache.org/jira/browse/IGNITE-6181). Even
if
> > all
> > > > > known
> > > > > > issues are fixed, there is still a lot of room for mistake and
> > > > incorrect
> > > > > > usage.
> > > > > >
> > > > > > To make it possible for Ignite users to discover such problem
and
> > > trace
> > > > > it
> > > > > > to a particular part of code, I've created a very simple utility
> > that
> > > > > > collects and prints information about long running transactions
> for
> > > the
> > > > > > whole cluster. It is available here:
> > > > > > https://github.com/ilantukh/IgniteTxViewer.
> > > > > >
> > > > > > One might expect such monitoring utilities to be included in
> Ignite
> > > > > > codebase. Personally, I think that such information should be
> > > available
> > > > > > from public API, without using of additional applications or
> diving
> > > > into
> > > > > > Ignite internals.
> > > > > >
> > > > > > What do you think?
> > > > > >
> > > > > > --
> > > > > > Best regards,
> > > > > > Ilya
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message