Open LarsHesselberg opened 1 year ago
Are you able to try your proposed fix to see if it stops the issue you are seeing?
I have no possibility to reproduce the problem consistently. It happens randomly. But examination of the code reveals that Close() will throw an exception if MsgType is Uninitialised. In my opinion it must be legal to call Close() at any time and repeatedly without getting an exception.
In fact I think the check should be removed in Close() and moved to the XXXInit() functions so these throws exception if not MsgType is Uninitialised, that would be more logical. But I have no deep knowledge to the code complex to see if that will introduced other dysfunctionality/errors.
I run into the same issue randomly too. Difficult to reproduce but looks like it happens under heavy load.
We are seeing the problem again. I still think it is better to allow Close() handle !Initialized: Proposed change in Msg.cs:
/// <summary>
/// Clear the <see cref="Data"/> and set the MsgType to Invalid.
/// If this is not a shared-data Msg (MsgFlags.Shared is not set), or it is shared but the reference-counter has dropped to zero,
/// then return the data back to the BufferPool.
/// </summary>
/// <exception cref="FaultException">The object is not initialised.</exception>
public void Close()
{
if (IsInitialised)
{
if (MsgType == MsgType.Pool)
{
Assumes.NotNull(m_refCount);
Assumes.NotNull(m_data);
// if not shared or reference counter drop to zero
if (!IsShared || m_refCount.Decrement() == 0)
BufferPool.Return(m_data);
EnsureAtomicCounterNull();
}
}
// Uninitialise the frame
m_data = null;
MsgType = MsgType.Uninitialised;
}
Environment
Expected behaviour
No exception
Actual behaviour
Steps to reproduce the behaviour
Appears randomly - mostly under heavy load.
Examining the NetMQ code it looks like the issue occurs in EncoderBase.cs Encode function here:
I point at this place because following the call-tree it is the only place I can find where Msg could be Uninitialised.