[
https://issues.apache.org/jira/browse/GEODE-8920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293214#comment-17293214
]
ASF GitHub Bot commented on GEODE-8920:
---------------------------------------
kamilla1201 opened a new pull request #6071:
URL: https://github.com/apache/geode/pull/6071
… (#6041)
(cherry picked from commit fc2fc9f890c5673bd6d0954048efb525b0098126)
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in
the commit message?
- [ ] Has your PR been rebased against the latest commit within the target
branch (typically `develop`)?
- [ ] Is your initial contribution a single, squashed commit?
- [ ] Does `gradlew build` run cleanly?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
### Note:
Please ensure that once the PR is submitted, check Concourse for build
issues and
submit an update to your PR as soon as possible. If you need help, please
send an
email to d...@geode.apache.org.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Modify debug logging to make it easier to trace a message
> ---------------------------------------------------------
>
> Key: GEODE-8920
> URL: https://issues.apache.org/jira/browse/GEODE-8920
> Project: Geode
> Issue Type: Improvement
> Components: membership
> Reporter: Bruce J Schuchardt
> Assignee: Kamilla Aslami
> Priority: Major
> Labels: blocks-1.14.0, pull-request-available
> Fix For: 1.15.0
>
>
> Debug logging in DirectChannel lets us know the IDs of receivers of a message
> and the toString of the message but it's very difficult to figure out what
> thread on the receiving end is supposed to process that message.
> Here's an example of what we currently have:
> [debug 2021/02/01 16:15:17.492 PST persistgemfire8_host1_8586
> <vm_9_thr_25_persist8_host1_8586> tid=0x4f0] Sending
> (DLockRequestProcessor.DLockResponseMessage responding GRANT;
> serviceName=__PDX(version 4); objectName=PDX_LOCK; responseCode=0;
> keyIfFailed=null; leaseExpireTime=9223372036854775807; processorId=509;
> lockId=509) to 1 peers
> ([rs-GEM-3166-PL1535a2i32xlarge-hydra-client-36(persistgemfire9_host1_8517:8517)<ec><v51>:41005])
> via tcp/ip
> This does not tell you anything about the receiver except its ID. On the
> receiving side the thread that, in this run, would handle that message is
> this:
> persistgemfire9_host1_8517 <P2P message reader for
> rs-GEM-3166-PL1535a2i32xlarge-hydra-client-36(persistgemfire8_host1_8586:8586)<ec><v51>:41006
> unshared ordered *uid=1036* dom #1 local port=47207 remote port=42068>
> tid=0x51
> I've highlighted the *uid* here because that is the _uniqueId_ of the sending
> Connection. If you looked through the logs or stack traces of the receiver
> and knew the uniqueId of the sending Connection you could easily locate the
> thread that should receive this DLockResponseMessage. Currently this is much
> harder than it needs to be because the DirectChannel _Sending_ log message
> doesn't include the _uniqueId_ of the Connections it is using to send the
> message.
> Let's change that log message to include the _uniqueId_ of each outgoing
> Connection. Maybe something like this:
> Sending (message.toString()) to 1 peers (peer ID)*, uid=1036* via tcp/ip
> and on the receiving side we could be clearer about what the *uid* in the
> thread's name means:
> persistgemfire9_host1_8517 <P2P message reader for
> rs-GEM-3166-PL1535a2i32xlarge-hydra-client-36(persistgemfire8_host1_8586:8586)<ec><v51>:41006
> unshared ordered *sender uid=1036* dom #1 local port=47207 remote
> port=42068> tid=0x51
> or something like that.
> Now we can look at the _Sending_ message and know that the receiving thread
> will have _uid=1036_ in its name. Knowing this it ought to be possible to
> write a program/script to trace a message and its consequences from one node
> to another.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
