Дубликат, возвращенный Guid.NewGuid ()?

Это ошибка в вашем коде. Если вам удалось создать несколько руководств, это наиболее вероятное объяснение. Подсказка здесь в вашем вопросе: «когда мы запускали тест после незначительных изменений кода симулятора, все сгенерированные им объекты имели одинаковый Guid»

См. Этот статья о том, как создается Guid.

Эта статья пришла из ответа Этот.

Итог, если вы создаете GUID слишком быстро, а часы не сдвинулись вперед, поэтому вы получаете такие же. Однако, когда вы засыпаете, он работает, потому что часы переместились.

Код в Submit и OrderTicket тоже будет полезен ...

Вы повторно используете OrderTicket. Я подозреваю, что либо вы (или само удаленное взаимодействие) выполняете пакетные вызовы - вероятно, в отношении количества соединений / ограничений хоста - и выбираете последнее значение CacheId, когда оно, наконец, отправляет их.

Если вы отлаживаете приложение или Thread.Sleep, вы меняете время, чтобы вызов удаленного взаимодействия завершился до того, как вы назначите новый CacheId.

Вы асинхронизируете удаленный вызов? Я бы подумал, что вызов синхронизации будет заблокирован, но я бы проверил с помощью анализатора пакетов, такого как Wireshark, чтобы быть уверенным. В любом случае, просто переход на создание нового OrderTicket на каждой итерации, вероятно, поможет.

Обновлено: вопрос в нет о том, что NewGuid не работает ... поэтому мой предыдущий ответ был удален.

Тысячи разработчиков используют Guids в .NET. Если бы Guid.NewGuid () вообще имел тенденцию «застревать» на одном значении, проблема возникла бы давно.

Несомненно, виноваты незначительные изменения кода. Тот факт, что Thread.Sleep (который меньше отвлекающий маневр, чем рыба, гниющая на солнце) «решает» вашу проблему, предполагает, что ваши свойства задаются каким-то странным образом, который не может вступить в силу, пока цикл не перестанет блокироваться (либо завершив или с помощью Thread.Sleep). Я даже готов поспорить, что «незначительное изменение» заключалось в сбросе всех свойств из отдельного потока.

Если вы разместили образец кода, это поможет.

Я не знаю подробностей того, как генерируются GUID ... пока. Однако в настоящее время моя орг. разводит GUID со скоростью, которая заставит кроликов посрамить. Так что я могу поручиться за то, что GUID не сломаны .. пока.

• Опубликуйте исходный код, если возможно .. или приложение для воспроизведения клонов. Много раз я обнаружил, что создание этого приложения-клона для воспроизведения проблемы показывает мне проблему.
• Другой подход - закомментировать «эти незначительные изменения». Если это решит проблему, вы можете сделать треугольник, чтобы найти проблемную строку кода. На глаз мелкие изменения жестко ... Я имею в виду реальный Hard.

Сообщите нам, как это происходит ... звучит интересно.

Выполняет ли Submit асинхронный вызов или объект тикета переходит в другой поток на любом этапе.

В примере кода вы повторно используете один и тот же объект. Что делать, если Submit отправляет заявку в фоновом потоке после небольшой задержки (и не принимает копию). Когда вы меняете CacheId, вы фактически обновляете все ожидающие отправки. Это также объясняет, почему Thread.Sleep решает проблему. Попробуй это:

for( int i = 0; i < _numOrders; i++ )
{
    OrderTicket ticket = new OrderTicket(... );
    ticket.CacheId = Guid.NewGuid();
    Submit( ticket );  // note that this simply makes a remoting call
}

Если по какой-то причине это невозможно, попробуйте это и посмотрите, остались ли они такими же:

ticket.CacheId = new Guid("00000000-0000-0000-0000-" + 
     string.Format("{0:000000000000}", i));

Мое чутье подсказывает мне, что что-то в этом роде происходит ...

class OrderTicket 
{
   Guid CacheId {set {_guid = new Guid("00000000-0000-0000-0000-");}
}

Регистрируйте значение CacheId в файле журнала каждый раз, когда он вызывается с трассировкой стека ... Может быть, кто-то еще его устанавливает.