New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use cache in BlockchainController.GetTransactionsAsync
(take 2)
#12275
Use cache in BlockchainController.GetTransactionsAsync
(take 2)
#12275
Conversation
uint256 txId = parsedTxIds[i]; | ||
string cacheKey = GetCacheKeyForTransaction(txId); | ||
|
||
if (Cache.TryGetValue(cacheKey, out TaskCompletionSource<Transaction>? tcs)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it would be better to be more defensive and verify that tcs.Task
is not a failed task which can happen I think.
@@ -140,76 +143,107 @@ private async Task<IEnumerable<string>> GetRawMempoolStringsNoCacheAsync(Cancell | |||
[HttpGet("transaction-hexes")] | |||
[ProducesResponseType(200)] | |||
[ProducesResponseType(400)] | |||
public async Task<IActionResult> GetTransactionsAsync([FromQuery, Required] IEnumerable<string> transactionIds, CancellationToken cancellationToken) | |||
public async Task<IActionResult> GetTransactionsAsync([FromQuery, Required] List<string> transactionIds, CancellationToken cancellationToken) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is safe but maybe not. Not sure. If not, we can create a copy of the input parameter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would revert this.
If you want to change it setup a RegTest and make sure it is working when this happens:
Or was that already done that's why it was resolved?
More or less ready. We should have unit tests. Anyway, this PR waits for concept ACK / NACK. |
@molnard Can you take a decision about this PR or the other alternate and work towards merge please? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm getting 500 Internal Server Error no matter what. I debugged into the backend and the transactions are fetched properly, but there is a problem with serialization.
fail: Microsoft.AspNetCore.Server.Kestrel[13]
Connection id "0HN22KEDCI5QI", Request id "0HN22KEDCI5QI:00000005": An unhandled exception was thrown by the application.
Newtonsoft.Json.JsonSerializationException: Error getting value from 'Date' on 'NBitcoin.LockTime'.
---> System.InvalidOperationException: This is not a time based lock
at lambda_method167(Closure, Object)
at Newtonsoft.Json.Serialization.ExpressionValueProvider.GetValue(Object target)
--- End of inner exception stack trace ---
at Newtonsoft.Json.Serialization.ExpressionValueProvider.GetValue(Object target)
at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.CalculatePropertyValues(JsonWriter writer, Object value, JsonContainerContract contract, JsonProperty member, JsonProperty property, JsonContract& memberContract, Object& memberValue)
at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeObject(JsonWriter writer, Object value, JsonObjectContract contract, JsonProperty member, JsonContainerContract collectionContract, JsonProperty containerProperty)
at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeValue(JsonWriter writer, Object value, JsonContract valueContract, JsonProperty member, JsonContainerContract containerContract, JsonProperty containerProperty)
at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeObject(JsonWriter writer, Object value, JsonObjectContract contract, JsonProperty member, JsonContainerContract collectionContract, JsonProperty containerProperty)
at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeValue(JsonWriter writer, Object value, JsonContract valueContract, JsonProperty member, JsonContainerContract containerContract, JsonProperty containerProperty)
It's fine we will make the decision with @adamPetho when it will be required. |
It is required right now, so it's time to make up our minds. Personally, I don't care which approach gets merged in as long as it's working and does the job. According to Kimi #12263 (review) that PR has major bugs. According to my testing, this PR is almost working, we only need to fix the return type. Whichever PR we decide on, it will be a great help on my current task. Just please choose and push one of these forward. |
Co-authored-by: adamPetho <45069029+adamPetho@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cACK
Please prepare the method like this for adamp. We will merge this PR first.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you make this happen? A running version that is tested and not PoC?
b128a68
to
6263538
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tACK, Code LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, couple of small things to consider but in general OK.
} | ||
catch | ||
{ | ||
return BadRequest("Invalid transaction Ids."); | ||
} | ||
|
||
Transaction[] txs = await FetchTransactionsAsync(parsedTxIds, cancellationToken).ConfigureAwait(false); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was that intentional to go with the Internal Server Error in case of exception instead of BadRequest(ex.Message);
like it was before? If so what is the benefit and how will the client react to that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reverted back in 70a9b75
@@ -32,6 +36,7 @@ public class BlockchainController : ControllerBase | |||
{ | |||
public static readonly TimeSpan FilterTimeout = TimeSpan.FromMinutes(20); | |||
private static readonly MemoryCacheEntryOptions CacheEntryOptions = new() { AbsoluteExpirationRelativeToNow = TimeSpan.FromSeconds(60) }; | |||
private static MemoryCacheEntryOptions TransactionCacheOptions { get; } = new MemoryCacheEntryOptions { AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(1) }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How long should we store the tx in the cache? Can it change meanwhile?
- Transactions are not changing. Mempool information is stored on another level but the tx will remain the same. So we could store the tx indefinitely - nothing gets outdated.
- On the other hand, we need to preserve the memory, so the must be a timeout when after we release the memory.
- Let's do a practical approach, the client uses this request the most while transition are in the mempool mostly when it appeared in the mempool with the sync requests. The request interval is 30 seconds. However the new functionality will add one more use case with the unconfirmed tx chain that is requesting may transactions from time to time.
Are there any risks if we increase this to like to 20 minutes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed to 20 minutes.
@@ -140,76 +143,107 @@ private async Task<IEnumerable<string>> GetRawMempoolStringsNoCacheAsync(Cancell | |||
[HttpGet("transaction-hexes")] | |||
[ProducesResponseType(200)] | |||
[ProducesResponseType(400)] | |||
public async Task<IActionResult> GetTransactionsAsync([FromQuery, Required] IEnumerable<string> transactionIds, CancellationToken cancellationToken) | |||
public async Task<IActionResult> GetTransactionsAsync([FromQuery, Required] List<string> transactionIds, CancellationToken cancellationToken) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would revert this.
If you want to change it setup a RegTest and make sure it is working when this happens:
Or was that already done that's why it was resolved?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
AbsoluteExpirationRelativeToNow
I am not sure about. WDY guys think about such a long caching?
Storing a transaction in memory for some time is cheaper than repeatedly getting it via RPC. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is hard for me to review this PR but LGTM, I've seen no issues in it.
/// </summary> | ||
/// <returns><c>true</c> if the key was added to the cache, <c>false</c> otherwise.</returns> | ||
/// <remarks>Caller is responsible to ALWAYS set a result to <paramref name="responseTcs"/> even if an exception is thrown.</remarks> | ||
public bool TryAddKey<TRequest, TResponse>(TRequest cacheKey, MemoryCacheEntryOptions options, out TaskCompletionSource<TResponse> responseTcs) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a good function, it might be useful elsewhere
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, though one must be extra cautious when using it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I know how one can make it safer but it would be more lines of code, so ... :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well the original PR created by me was not touching IdempotenceRequestCache at all. But that was down-voted so this is the solution you guys wanted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not aware of any downvoting per se (only major bugs in your PR that were not addressed).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't make sense to address any bugs if the concept is not ACKed by the godfather of IdempotencyRequestCache
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You guys went with the alternative solution which is perfectly fine for me. Now that we are at the end of this, are you saying that adding TryAddKey
is not safe? I hope this is not the case...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not safe in the sense that if one forgets to assign the result, then bad things will happen. This is not an issue if one has good tests.
Personally, I would like more to return from TryAddKey
a disposable that would make sure that either a result is assigned or an exception is assigned and if not, it would throw an exception so it would be very much visible that something unexpected has happened. Anyway, even without this it should work well but one must be careful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK - feel free to merge @kiminuo if it is ready.
/// </summary> | ||
/// <returns><c>true</c> if the key was added to the cache, <c>false</c> otherwise.</returns> | ||
/// <remarks>Caller is responsible to ALWAYS set a result to <paramref name="responseTcs"/> even if an exception is thrown.</remarks> | ||
public bool TryAddKey<TRequest, TResponse>(TRequest cacheKey, MemoryCacheEntryOptions options, out TaskCompletionSource<TResponse> responseTcs) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well the original PR created by me was not touching IdempotenceRequestCache at all. But that was down-voted so this is the solution you guys wanted.
CF issues are not related to this PR - but discovered by CF now. Don't need to fix them here. |
I cannot: |
Oh Got it, because of CF... Can I merge then? |
I think so.
Yes. |
Alternative to #12263