[ACCEPTED]-Duplicate returned by Guid.NewGuid()?-guid

Does Submit do an async call, or does the 10 ticket object go into another thread at 9 any stage.

In the code example you are reusing 8 the same object. What if Submit sends the 7 ticket in a background thread after a short 6 delay (and does not take a copy). When you 5 change the CacheId you are actually updating 4 all the pending submits. This also explains 3 why a Thread.Sleep fixes the problem. Try 2 this:

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
}

If for some reason this is not possible, try 1 this and see if they are still the same:

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

Thousands of developers use Guids in .NET. If 15 Guid.NewGuid() had any tendency at all to 14 get "stuck" on one value, the 13 problem would have been encountered long 12 ago.

The minor code changes are the sure 11 culprit here. The fact that Thread.Sleep (which is 10 less a red herring than a fish rotting in 9 the sun) "fixes" your problem 8 suggests that your properties are being 7 set in some weird way that can't take effect 6 until the loop stops blocking (either by 5 ending or by Thread.Sleep). I'd even be 4 willing to bet that the "minor change" was 3 to reset all the properties from a separate 2 thread.

If you posted some sample code, that 1 would help.

It's a bug in your code. If you've managed 5 to generate multiple guid's it is the most 4 likely explanation. The clue is here in 3 your question: "when we ran a test after some minor code changes to the simulator all 2 of the objects generated by it had the same 1 Guid"

See this article about how a Guid is created.

This 6 artcile came from This answer.

Bottom line if 5 you are creating the GUIDs too quickly and 4 the clock hasn't moved forward that is why 3 you are getting some as the same. However 2 when you put a sleep in it works because 1 the clock has moved.

The code in Submit and OrderTicket would 16 be helpful as well...

You're reusing OrderTicket. I'd 15 suspect that either you (or remoting itself) is 14 batching calls out - probably in respect 13 to # of connections/host limits - and picking 12 up the last value of CacheId when it finally 11 sends them along.

If you debug or Thread.Sleep 10 the app, you're changing the timing so that 9 the remoting call finishes before you assign 8 a new CacheId.

Are you asyncing the remoting 7 call? I'd think a sync call would block 6 - but I'd check with a packet sniffer like 5 Wireshark to be sure. Regardless, just changing 4 to creating a new OrderTicket in each iteration 3 would probably do the trick.

Edit: The question 2 is not about NewGuid being broken...so my previous 1 answer has been removed.

I dont know the details of how GUIDs are 5 generated.. yet. However currently my org. is 4 breeding GUIDs at a rate that would put 3 rabbits to shame. So I can vouch for the 2 fact that GUIDs aren't broken.. yet.

• Post the source code if possible.. or a clone repro app. Many times I find the act of creating that clone app to repro the problem shows me the issue.
• The other approach would be to comment out "those minor changes". If that fixes the problem, you can then triangularize to find the offending line of code. Eye-ball the minor changes hard... I mean real Hard.

Do let us know how it goes... this 1 sounds interesting.

My gut is telling me something along these 4 lines is going on...

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

Log the value of CacheId 3 into a log file every time its called with 2 a stack trace ... Maybe someone else is 1 setting it.