Bot releases are hidden (Show)
Published by johnsimons about 10 years ago
As part of this release we had 1 issue closed.
When a user is using the Scheduler API and creates to schedule tasks, one that runs every 5secs and another one that runs every 1min.
Every so often the 5sec schedule task stops from reoccurring.
Here are the logs
And here is one of the timeouts stored in Raven:
{
"Destination": {
"Queue": "Flyt.TiosCtcAgent",
"Machine": "GMBSANNTID"
},
"SagaId": "00000000-0000-0000-0000-000000000000",
"State": "PD94bWwgdmVyc2lvbj0iMS4wIiA/Pg0KPE1lc3NhZ2VzIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIHhtbG5zOnhzZD0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiIHhtbG5zPSJodHRwOi8vdGVtcHVyaS5uZXQvTlNlcnZpY2VCdXMuU2NoZWR1bGluZy5NZXNzYWdlcyI+CjxTY2hlZHVsZWRUYXNrPgo8VGFza0lkPmU2YjZlN2NmLTlmYjMtNDhiZS1iZGUwLTc0NmJhZmE3MmRlNzwvVGFza0lkPgo8TmFtZT5Cb290c3RyYXA8L05hbWU+CjxFdmVyeT5QVDVTPC9FdmVyeT4KPC9TY2hlZHVsZWRUYXNrPgo8L01lc3NhZ2VzPg0K",
"Time": "2014-05-21T08:18:00.2114720Z",
"CorrelationId": "2f849e22-d760-4ce6-846b-a33200a9b784\\0",
"OwningTimeoutManager": "Flyt.TiosCtcAgent",
"Headers": {
"NServiceBus.MessageId": "2f849e22-d760-4ce6-846b-a33200a9b784",
"NServiceBus.CorrelationId": "2f849e22-d760-4ce6-846b-a33200a9b784",
"NServiceBus.OriginatingEndpoint": "Flyt.TiosCtcAgent",
"$.diagnostics.originating.hostid": "522caf7d3f53a790fdcc328b6cb0d627",
"NServiceBus.MessageIntent": "Send",
"NServiceBus.Version": "4.4.2",
"NServiceBus.TimeSent": "2014-05-21 08:17:55:211472 Z",
"NServiceBus.OriginatingMachine": "GMBSANNTID",
"NServiceBus.ContentType": "text/xml",
"NServiceBus.EnclosedMessageTypes": "NServiceBus.Scheduling.Messages.ScheduledTask, NServiceBus.Core, Version=4.4.0.0, Culture=neutral, PublicKeyToken=9fc386479f8a226c",
"CorrId": "2f849e22-d760-4ce6-846b-a33200a9b784\\0",
"WinIdName": "GMBDOMENE1\\sanntidintegrasjon",
"NServiceBus.RelatedTo": "5da0ead5-1701-4e2e-9b43-a33200a9b16e",
"NServiceBus.ConversationId": "a00caaba-1eab-48a7-854f-a33100a5c243",
"NServiceBus.IsDeferredMessage": "True",
"NServiceBus.Temporary.DelayDeliveryWith": "00:00:05",
"NServiceBus.Timeout.Expire": "2014-05-21 08:18:00:211472 Z",
"NServiceBus.Timeout.RouteExpiredTimeoutTo": "Flyt.TiosCtcAgent@GMBSANNTID",
"NServiceBus.Timeout.ReplyToAddress": "Flyt.TiosCtcAgent@GMBSANNTID"
}
}
The only explanation I have is if the index is stale, we could end-up skipping over timeouts.
See full issue
You can download this release from nuget
Published by johnsimons about 10 years ago
As part of this release we had 1 issue closed.
When a user is using the Scheduler API and creates to schedule tasks, one that runs every 5secs and another one that runs every 1min.
Every so often the 5sec schedule task stops from reoccurring.
Here are the logs
And here is one of the timeouts stored in Raven:
{
"Destination": {
"Queue": "Flyt.TiosCtcAgent",
"Machine": "GMBSANNTID"
},
"SagaId": "00000000-0000-0000-0000-000000000000",
"State": "PD94bWwgdmVyc2lvbj0iMS4wIiA/Pg0KPE1lc3NhZ2VzIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIHhtbG5zOnhzZD0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiIHhtbG5zPSJodHRwOi8vdGVtcHVyaS5uZXQvTlNlcnZpY2VCdXMuU2NoZWR1bGluZy5NZXNzYWdlcyI+CjxTY2hlZHVsZWRUYXNrPgo8VGFza0lkPmU2YjZlN2NmLTlmYjMtNDhiZS1iZGUwLTc0NmJhZmE3MmRlNzwvVGFza0lkPgo8TmFtZT5Cb290c3RyYXA8L05hbWU+CjxFdmVyeT5QVDVTPC9FdmVyeT4KPC9TY2hlZHVsZWRUYXNrPgo8L01lc3NhZ2VzPg0K",
"Time": "2014-05-21T08:18:00.2114720Z",
"CorrelationId": "2f849e22-d760-4ce6-846b-a33200a9b784\\0",
"OwningTimeoutManager": "Flyt.TiosCtcAgent",
"Headers": {
"NServiceBus.MessageId": "2f849e22-d760-4ce6-846b-a33200a9b784",
"NServiceBus.CorrelationId": "2f849e22-d760-4ce6-846b-a33200a9b784",
"NServiceBus.OriginatingEndpoint": "Flyt.TiosCtcAgent",
"$.diagnostics.originating.hostid": "522caf7d3f53a790fdcc328b6cb0d627",
"NServiceBus.MessageIntent": "Send",
"NServiceBus.Version": "4.4.2",
"NServiceBus.TimeSent": "2014-05-21 08:17:55:211472 Z",
"NServiceBus.OriginatingMachine": "GMBSANNTID",
"NServiceBus.ContentType": "text/xml",
"NServiceBus.EnclosedMessageTypes": "NServiceBus.Scheduling.Messages.ScheduledTask, NServiceBus.Core, Version=4.4.0.0, Culture=neutral, PublicKeyToken=9fc386479f8a226c",
"CorrId": "2f849e22-d760-4ce6-846b-a33200a9b784\\0",
"WinIdName": "GMBDOMENE1\\sanntidintegrasjon",
"NServiceBus.RelatedTo": "5da0ead5-1701-4e2e-9b43-a33200a9b16e",
"NServiceBus.ConversationId": "a00caaba-1eab-48a7-854f-a33100a5c243",
"NServiceBus.IsDeferredMessage": "True",
"NServiceBus.Temporary.DelayDeliveryWith": "00:00:05",
"NServiceBus.Timeout.Expire": "2014-05-21 08:18:00:211472 Z",
"NServiceBus.Timeout.RouteExpiredTimeoutTo": "Flyt.TiosCtcAgent@GMBSANNTID",
"NServiceBus.Timeout.ReplyToAddress": "Flyt.TiosCtcAgent@GMBSANNTID"
}
}
The only explanation I have is if the index is stale, we could end-up skipping over timeouts.
See full issue
You can download this release from nuget
Published by johnsimons about 10 years ago
As part of this release we had 1 issue closed.
When a user is using the Scheduler API and creates to schedule tasks, one that runs every 5secs and another one that runs every 1min.
Every so often the 5sec schedule task stops from reoccurring.
Here are the logs
And here is one of the timeouts stored in Raven:
{
"Destination": {
"Queue": "Flyt.TiosCtcAgent",
"Machine": "GMBSANNTID"
},
"SagaId": "00000000-0000-0000-0000-000000000000",
"State": "PD94bWwgdmVyc2lvbj0iMS4wIiA/Pg0KPE1lc3NhZ2VzIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIHhtbG5zOnhzZD0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiIHhtbG5zPSJodHRwOi8vdGVtcHVyaS5uZXQvTlNlcnZpY2VCdXMuU2NoZWR1bGluZy5NZXNzYWdlcyI+CjxTY2hlZHVsZWRUYXNrPgo8VGFza0lkPmU2YjZlN2NmLTlmYjMtNDhiZS1iZGUwLTc0NmJhZmE3MmRlNzwvVGFza0lkPgo8TmFtZT5Cb290c3RyYXA8L05hbWU+CjxFdmVyeT5QVDVTPC9FdmVyeT4KPC9TY2hlZHVsZWRUYXNrPgo8L01lc3NhZ2VzPg0K",
"Time": "2014-05-21T08:18:00.2114720Z",
"CorrelationId": "2f849e22-d760-4ce6-846b-a33200a9b784\\0",
"OwningTimeoutManager": "Flyt.TiosCtcAgent",
"Headers": {
"NServiceBus.MessageId": "2f849e22-d760-4ce6-846b-a33200a9b784",
"NServiceBus.CorrelationId": "2f849e22-d760-4ce6-846b-a33200a9b784",
"NServiceBus.OriginatingEndpoint": "Flyt.TiosCtcAgent",
"$.diagnostics.originating.hostid": "522caf7d3f53a790fdcc328b6cb0d627",
"NServiceBus.MessageIntent": "Send",
"NServiceBus.Version": "4.4.2",
"NServiceBus.TimeSent": "2014-05-21 08:17:55:211472 Z",
"NServiceBus.OriginatingMachine": "GMBSANNTID",
"NServiceBus.ContentType": "text/xml",
"NServiceBus.EnclosedMessageTypes": "NServiceBus.Scheduling.Messages.ScheduledTask, NServiceBus.Core, Version=4.4.0.0, Culture=neutral, PublicKeyToken=9fc386479f8a226c",
"CorrId": "2f849e22-d760-4ce6-846b-a33200a9b784\\0",
"WinIdName": "GMBDOMENE1\\sanntidintegrasjon",
"NServiceBus.RelatedTo": "5da0ead5-1701-4e2e-9b43-a33200a9b16e",
"NServiceBus.ConversationId": "a00caaba-1eab-48a7-854f-a33100a5c243",
"NServiceBus.IsDeferredMessage": "True",
"NServiceBus.Temporary.DelayDeliveryWith": "00:00:05",
"NServiceBus.Timeout.Expire": "2014-05-21 08:18:00:211472 Z",
"NServiceBus.Timeout.RouteExpiredTimeoutTo": "Flyt.TiosCtcAgent@GMBSANNTID",
"NServiceBus.Timeout.ReplyToAddress": "Flyt.TiosCtcAgent@GMBSANNTID"
}
}
The only explanation I have is if the index is stale, we could end-up skipping over timeouts.
See full issue
You can download this release from nuget
Published by johnsimons about 10 years ago
As part of this release we had 1 issue closed.
When a user is using the Scheduler API and creates to schedule tasks, one that runs every 5secs and another one that runs every 1min.
Every so often the 5sec schedule task stops from reoccurring.
Here are the logs
And here is one of the timeouts stored in Raven:
{
"Destination": {
"Queue": "Flyt.TiosCtcAgent",
"Machine": "GMBSANNTID"
},
"SagaId": "00000000-0000-0000-0000-000000000000",
"State": "PD94bWwgdmVyc2lvbj0iMS4wIiA/Pg0KPE1lc3NhZ2VzIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIHhtbG5zOnhzZD0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiIHhtbG5zPSJodHRwOi8vdGVtcHVyaS5uZXQvTlNlcnZpY2VCdXMuU2NoZWR1bGluZy5NZXNzYWdlcyI+CjxTY2hlZHVsZWRUYXNrPgo8VGFza0lkPmU2YjZlN2NmLTlmYjMtNDhiZS1iZGUwLTc0NmJhZmE3MmRlNzwvVGFza0lkPgo8TmFtZT5Cb290c3RyYXA8L05hbWU+CjxFdmVyeT5QVDVTPC9FdmVyeT4KPC9TY2hlZHVsZWRUYXNrPgo8L01lc3NhZ2VzPg0K",
"Time": "2014-05-21T08:18:00.2114720Z",
"CorrelationId": "2f849e22-d760-4ce6-846b-a33200a9b784\\0",
"OwningTimeoutManager": "Flyt.TiosCtcAgent",
"Headers": {
"NServiceBus.MessageId": "2f849e22-d760-4ce6-846b-a33200a9b784",
"NServiceBus.CorrelationId": "2f849e22-d760-4ce6-846b-a33200a9b784",
"NServiceBus.OriginatingEndpoint": "Flyt.TiosCtcAgent",
"$.diagnostics.originating.hostid": "522caf7d3f53a790fdcc328b6cb0d627",
"NServiceBus.MessageIntent": "Send",
"NServiceBus.Version": "4.4.2",
"NServiceBus.TimeSent": "2014-05-21 08:17:55:211472 Z",
"NServiceBus.OriginatingMachine": "GMBSANNTID",
"NServiceBus.ContentType": "text/xml",
"NServiceBus.EnclosedMessageTypes": "NServiceBus.Scheduling.Messages.ScheduledTask, NServiceBus.Core, Version=4.4.0.0, Culture=neutral, PublicKeyToken=9fc386479f8a226c",
"CorrId": "2f849e22-d760-4ce6-846b-a33200a9b784\\0",
"WinIdName": "GMBDOMENE1\\sanntidintegrasjon",
"NServiceBus.RelatedTo": "5da0ead5-1701-4e2e-9b43-a33200a9b16e",
"NServiceBus.ConversationId": "a00caaba-1eab-48a7-854f-a33100a5c243",
"NServiceBus.IsDeferredMessage": "True",
"NServiceBus.Temporary.DelayDeliveryWith": "00:00:05",
"NServiceBus.Timeout.Expire": "2014-05-21 08:18:00:211472 Z",
"NServiceBus.Timeout.RouteExpiredTimeoutTo": "Flyt.TiosCtcAgent@GMBSANNTID",
"NServiceBus.Timeout.ReplyToAddress": "Flyt.TiosCtcAgent@GMBSANNTID"
}
}
The only explanation I have is if the index is stale, we could end-up skipping over timeouts.
See full issue
You can download this release from nuget
Published by johnsimons about 10 years ago
As part of this release we had 1 issue closed.
When a user is using the Scheduler API and creates to schedule tasks, one that runs every 5secs and another one that runs every 1min.
Every so often the 5sec schedule task stops from reoccurring.
Here are the logs
And here is one of the timeouts stored in Raven:
{
"Destination": {
"Queue": "Flyt.TiosCtcAgent",
"Machine": "GMBSANNTID"
},
"SagaId": "00000000-0000-0000-0000-000000000000",
"State": "PD94bWwgdmVyc2lvbj0iMS4wIiA/Pg0KPE1lc3NhZ2VzIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIHhtbG5zOnhzZD0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiIHhtbG5zPSJodHRwOi8vdGVtcHVyaS5uZXQvTlNlcnZpY2VCdXMuU2NoZWR1bGluZy5NZXNzYWdlcyI+CjxTY2hlZHVsZWRUYXNrPgo8VGFza0lkPmU2YjZlN2NmLTlmYjMtNDhiZS1iZGUwLTc0NmJhZmE3MmRlNzwvVGFza0lkPgo8TmFtZT5Cb290c3RyYXA8L05hbWU+CjxFdmVyeT5QVDVTPC9FdmVyeT4KPC9TY2hlZHVsZWRUYXNrPgo8L01lc3NhZ2VzPg0K",
"Time": "2014-05-21T08:18:00.2114720Z",
"CorrelationId": "2f849e22-d760-4ce6-846b-a33200a9b784\\0",
"OwningTimeoutManager": "Flyt.TiosCtcAgent",
"Headers": {
"NServiceBus.MessageId": "2f849e22-d760-4ce6-846b-a33200a9b784",
"NServiceBus.CorrelationId": "2f849e22-d760-4ce6-846b-a33200a9b784",
"NServiceBus.OriginatingEndpoint": "Flyt.TiosCtcAgent",
"$.diagnostics.originating.hostid": "522caf7d3f53a790fdcc328b6cb0d627",
"NServiceBus.MessageIntent": "Send",
"NServiceBus.Version": "4.4.2",
"NServiceBus.TimeSent": "2014-05-21 08:17:55:211472 Z",
"NServiceBus.OriginatingMachine": "GMBSANNTID",
"NServiceBus.ContentType": "text/xml",
"NServiceBus.EnclosedMessageTypes": "NServiceBus.Scheduling.Messages.ScheduledTask, NServiceBus.Core, Version=4.4.0.0, Culture=neutral, PublicKeyToken=9fc386479f8a226c",
"CorrId": "2f849e22-d760-4ce6-846b-a33200a9b784\\0",
"WinIdName": "GMBDOMENE1\\sanntidintegrasjon",
"NServiceBus.RelatedTo": "5da0ead5-1701-4e2e-9b43-a33200a9b16e",
"NServiceBus.ConversationId": "a00caaba-1eab-48a7-854f-a33100a5c243",
"NServiceBus.IsDeferredMessage": "True",
"NServiceBus.Temporary.DelayDeliveryWith": "00:00:05",
"NServiceBus.Timeout.Expire": "2014-05-21 08:18:00:211472 Z",
"NServiceBus.Timeout.RouteExpiredTimeoutTo": "Flyt.TiosCtcAgent@GMBSANNTID",
"NServiceBus.Timeout.ReplyToAddress": "Flyt.TiosCtcAgent@GMBSANNTID"
}
}
The only explanation I have is if the index is stale, we could end-up skipping over timeouts.
See full issue
You can download this release from nuget
Published by johnsimons over 10 years ago
As part of this release we had 2 issue closed.
In version 3.3.8 and JSON we have hard coded the assumption that messages will be wrapped in an array
public object[] Deserialize(Stream stream)
{
JsonSerializer jsonSerializer = JsonSerializer.Create(JsonSerializerSettings);
jsonSerializer.ContractResolver = new MessageContractResolver(_messageMapper);
JsonReader reader = CreateJsonReader(stream);
return jsonSerializer.Deserialize<object[]>(reader);
}
Content trimmed. See full issue
When a user is using the Scheduler API and creates to schedule tasks, one that runs every 5secs and another one that runs every 1min.
Every so often the 5sec schedule task stops from reoccurring.
Here are the logs
And here is one of the timeouts stored in Raven:
{
"Destination": {
"Queue": "Flyt.TiosCtcAgent",
"Machine": "GMBSANNTID"
},
"SagaId": "00000000-0000-0000-0000-000000000000",
"State": "PD94bWwgdmVyc2lvbj0iMS4wIiA/Pg0KPE1lc3NhZ2VzIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIHhtbG5zOnhzZD0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiIHhtbG5zPSJodHRwOi8vdGVtcHVyaS5uZXQvTlNlcnZpY2VCdXMuU2NoZWR1bGluZy5NZXNzYWdlcyI+CjxTY2hlZHVsZWRUYXNrPgo8VGFza0lkPmU2YjZlN2NmLTlmYjMtNDhiZS1iZGUwLTc0NmJhZmE3MmRlNzwvVGFza0lkPgo8TmFtZT5Cb290c3RyYXA8L05hbWU+CjxFdmVyeT5QVDVTPC9FdmVyeT4KPC9TY2hlZHVsZWRUYXNrPgo8L01lc3NhZ2VzPg0K",
"Time": "2014-05-21T08:18:00.2114720Z",
"CorrelationId": "2f849e22-d760-4ce6-846b-a33200a9b784\\0",
"OwningTimeoutManager": "Flyt.TiosCtcAgent",
"Headers": {
"NServiceBus.MessageId": "2f849e22-d760-4ce6-846b-a33200a9b784",
"NServiceBus.CorrelationId": "2f849e22-d760-4ce6-846b-a33200a9b784",
"NServiceBus.OriginatingEndpoint": "Flyt.TiosCtcAgent",
"$.diagnostics.originating.hostid": "522caf7d3f53a790fdcc328b6cb0d627",
"NServiceBus.MessageIntent": "Send",
"NServiceBus.Version": "4.4.2",
"NServiceBus.TimeSent": "2014-05-21 08:17:55:211472 Z",
"NServiceBus.OriginatingMachine": "GMBSANNTID",
"NServiceBus.ContentType": "text/xml",
"NServiceBus.EnclosedMessageTypes": "NServiceBus.Scheduling.Messages.ScheduledTask, NServiceBus.Core, Version=4.4.0.0, Culture=neutral, PublicKeyToken=9fc386479f8a226c",
"CorrId": "2f849e22-d760-4ce6-846b-a33200a9b784\\0",
"WinIdName": "GMBDOMENE1\\sanntidintegrasjon",
"NServiceBus.RelatedTo": "5da0ead5-1701-4e2e-9b43-a33200a9b16e",
"NServiceBus.ConversationId": "a00caaba-1eab-48a7-854f-a33100a5c243",
"NServiceBus.IsDeferredMessage": "True",
"NServiceBus.Temporary.DelayDeliveryWith": "00:00:05",
"NServiceBus.Timeout.Expire": "2014-05-21 08:18:00:211472 Z",
"NServiceBus.Timeout.RouteExpiredTimeoutTo": "Flyt.TiosCtcAgent@GMBSANNTID",
"NServiceBus.Timeout.ReplyToAddress": "Flyt.TiosCtcAgent@GMBSANNTID"
}
}
The only explanation I have is if the index is stale, we could end-up skipping over timeouts.
See full issue
You can download this release from nuget
Published by johnsimons over 10 years ago
As part of this release we had 1 issue closed.
Some timeouts could be delayed firing for a maximum of 2 minutes
You can download this release from nuget
Published by johnsimons over 10 years ago
As part of this release we had 1 issue closed.
When a user is using the Scheduler API and creates to schedule tasks, one that runs every 5secs and another one that runs every 1min.
Every so often the 5sec schedule task stops from reoccurring.
Here are the logs
And here is one of the timeouts stored in Raven:
{
"Destination": {
"Queue": "Flyt.TiosCtcAgent",
"Machine": "GMBSANNTID"
},
"SagaId": "00000000-0000-0000-0000-000000000000",
"State": "PD94bWwgdmVyc2lvbj0iMS4wIiA/Pg0KPE1lc3NhZ2VzIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIHhtbG5zOnhzZD0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiIHhtbG5zPSJodHRwOi8vdGVtcHVyaS5uZXQvTlNlcnZpY2VCdXMuU2NoZWR1bGluZy5NZXNzYWdlcyI+CjxTY2hlZHVsZWRUYXNrPgo8VGFza0lkPmU2YjZlN2NmLTlmYjMtNDhiZS1iZGUwLTc0NmJhZmE3MmRlNzwvVGFza0lkPgo8TmFtZT5Cb290c3RyYXA8L05hbWU+CjxFdmVyeT5QVDVTPC9FdmVyeT4KPC9TY2hlZHVsZWRUYXNrPgo8L01lc3NhZ2VzPg0K",
"Time": "2014-05-21T08:18:00.2114720Z",
"CorrelationId": "2f849e22-d760-4ce6-846b-a33200a9b784\\0",
"OwningTimeoutManager": "Flyt.TiosCtcAgent",
"Headers": {
"NServiceBus.MessageId": "2f849e22-d760-4ce6-846b-a33200a9b784",
"NServiceBus.CorrelationId": "2f849e22-d760-4ce6-846b-a33200a9b784",
"NServiceBus.OriginatingEndpoint": "Flyt.TiosCtcAgent",
"$.diagnostics.originating.hostid": "522caf7d3f53a790fdcc328b6cb0d627",
"NServiceBus.MessageIntent": "Send",
"NServiceBus.Version": "4.4.2",
"NServiceBus.TimeSent": "2014-05-21 08:17:55:211472 Z",
"NServiceBus.OriginatingMachine": "GMBSANNTID",
"NServiceBus.ContentType": "text/xml",
"NServiceBus.EnclosedMessageTypes": "NServiceBus.Scheduling.Messages.ScheduledTask, NServiceBus.Core, Version=4.4.0.0, Culture=neutral, PublicKeyToken=9fc386479f8a226c",
"CorrId": "2f849e22-d760-4ce6-846b-a33200a9b784\\0",
"WinIdName": "GMBDOMENE1\\sanntidintegrasjon",
"NServiceBus.RelatedTo": "5da0ead5-1701-4e2e-9b43-a33200a9b16e",
"NServiceBus.ConversationId": "a00caaba-1eab-48a7-854f-a33100a5c243",
"NServiceBus.IsDeferredMessage": "True",
"NServiceBus.Temporary.DelayDeliveryWith": "00:00:05",
"NServiceBus.Timeout.Expire": "2014-05-21 08:18:00:211472 Z",
"NServiceBus.Timeout.RouteExpiredTimeoutTo": "Flyt.TiosCtcAgent@GMBSANNTID",
"NServiceBus.Timeout.ReplyToAddress": "Flyt.TiosCtcAgent@GMBSANNTID"
}
}
The only explanation I have is if the index is stale, we could end-up skipping over timeouts.
See full issue
You can download this release from nuget
Published by indualagarsamy over 10 years ago
As part of this release we had 5 commits which resulted in 1 issue being closed.
When child containers is used. Fix is to upgrade Autofac to 3.0.1
Rollback of Issue 397 (Nested lifetime scopes aren't disposed when the parent is disposed) due to memory leak.
ported from https://github.com/Particular/NServiceBus/issues/1708
You can download this release from:
In Package Manager Console, type:
update-package NServiceBus -version 4.1.2 <ProjectName>
Published by andreasohlund over 10 years ago
As part of this release we had 5 commits which resulted in 1 issue being closed.
When a 3.X endpoint does a Bus.Return
that targets a 4.2.0 endpoint the v4 endpoint can't process the message. This makes it wire incompatible.
repro https://github.com/Particular/BugsRepro/tree/master/1943MissingCompletionMessage
So in a 4.2 endpoint
Bus.Send("Returner", new Message())
.Register<int>(i => Debug.WriteLine(i));
Content trimmed. See full issue
You can download this release from:
Published by SimonCropp over 10 years ago
As part of this release we had 2 commits which resulted in 1 issue being closed.
Turns out some of our consumers actually need this
Partially reverts https://github.com/Particular/NServiceBus/issues/1313
The difference is non CLS Compliant members will be marked as such. So assemblies will be "CLS Compliant with exceptions"
You can download this release from:
Published by johnsimons over 10 years ago
As part of this release we had 53 commits which resulted in 14 issues being closed.
IEndpointConfig
, we should skip scanning if (arguments.ScannedAssemblies.Count > 0 -- && no errors)
{
serviceCommandLine.AddRange(arguments.ScannedAssemblies.Select(assembly => String.Format(@"/scannedAssemblies:""{0}""", assembly)));
}
AppDomain
so that any binding redirects kick inSo there are several confusion of this API
When a message is forwarded to the error queue, the stack trace that is stored in the header information for the message in the error queue is currently too long. We should include the inner exception that caused the problem instead of the entire stack trace which includes the entire pipeline steps.
So in all our assembly attributes we say we are CLS compliant. However we are not. See warnings below
We need to do some significant breaking changes to achieve this.
Warning 58 Type of 'EasyNetQ.ConnectionFactoryInfo.ConnectionFactory' is not CLS-compliant C:\Code\NServiceBus\src\RabbitMQ\NServiceBus.RabbitMQ\EasyNetQ\ConnectionFactoryInfo.cs 13 34 NServiceBus.Transports.RabbitMQ
Warning 52 Type of 'EasyNetQ.HostConfiguration.Port' is not CLS-compliant C:\Code\NServiceBus\src\RabbitMQ\NServiceBus.RabbitMQ\EasyNetQ\HostConfiguration.cs 6 23 NServiceBus.Transports.RabbitMQ
Warning 51 Type of 'EasyNetQ.IHostConfiguration.Port' is not CLS-compliant C:\Code\NServiceBus\src\RabbitMQ\NServiceBus.RabbitMQ\EasyNetQ\IHostConfiguration.cs 6 16 NServiceBus.Transports.RabbitMQ
Warning 41 Type of 'NServiceBus.SagaPersisters.Azure.DictionaryTableEntity.this[string]' is not CLS-compliant C:\Code\NServiceBus\src\azure\NServiceBus.Azure\SagaPersisters\Azure\DictionaryTableEntity.cs 154 31 NServiceBus.Azure
Warning 123 Type of 'NServiceBus.Serializers.XML.Test.MessageWithLists.SBytes' is not CLS-compliant C:\Code\NServiceBus\src\NServiceBus.Core.Tests\Serializers\XML\ListTests.cs 76 28 NServiceBus.Core.Tests
Content trimmed. See full issue
After upgrading to 4.5, I've started to get an exception with the NServiceBus Host:
Unhandled Exception: System.Exception: Could not enumerate all types for 'C:\Ser
vices\Server\FluentNHibernate.dll'.
at NServiceBus.Hosting.Helpers.AssemblyScanner.ScanAssembly(String assemblyPa
th, AssemblyScannerResults results) in c:\BuildAgent\work\31f8c64a6e8a2d7c\src\N
ServiceBus.Core\Hosting\Helpers\AssemblyScanner.cs:line 149
at NServiceBus.Hosting.Helpers.AssemblyScanner.GetScannableAssemblies() in c:
\BuildAgent\work\31f8c64a6e8a2d7c\src\NServiceBus.Core\Hosting\Helpers\AssemblyS
Content trimmed. See full issue
The trial license won't work if NServiceBus is running as LocalSystem
Here is the error:
2014-04-17 14:29:21,257 [4] FATAL NServiceBus.Licensing.LicenseManager [(null)] <(null)> - Could not access registry for the current user sid. Please ensure that the license has been properly installed.
And this is on purpose because LocalSystem does not have a HKCU, see https://github.com/Particular/NServiceBus/blob/develop/src/NServiceBus.Core/Licensing/LicenseManager.cs#L53
When IConfigureThisEndpoint
implementation is in a different project EndpointConfig.cs
content gets replaced with the default empty template.
To replicate this create a VS solution with 2 2 projects and in proj1 add:
public abstract class BaseClass : IConfigureThisEndpoint, IWantCustomInitialization
{
public void Init()
{
}
}
Content trimmed. See full issue
You can download this release from nuget
Published by johnsimons over 10 years ago
As part of this release we had 2 commits which resulted in 1 issue being closed.
Steps to repro
2014-04-16 12:09:29,107 [5] INFO NServiceBus.Configure [(null)] <(null)> - Invocation of NServiceBus.IWantToRunBeforeConfiguration completed in 0.08 s
2014-04-16 12:09:29,270 [5] INFO NServiceBus.Configure [(null)] <(null)> - Invocation of NServiceBus.Config.INeedInitialization completed in 0.00 s
2014-04-16 12:09:29,278 [5] FATAL NServiceBus.Hosting.GenericHost [(null)] <(null)> - Exception when starting endpoint.
System.Exception: Failed to access 'HKEY_LOCAL_MACHINE : SOFTWARE\ParticularSoftware : License'. Do you have permission to write to this key? ---> System.UnauthorizedAccessException: Access to the registry key 'HKEY_LOCAL_MACHINE\SOFTWARE\ParticularSoftware' is denied.
at Microsoft.Win32.RegistryKey.Win32Error(Int32 errorCode, String str)
Content trimmed. See full issue
You can download this release from:
Published by andreasohlund over 10 years ago
This release consist of these issues that were achieved through these commits.
This only applies to new users. If we detect that NServiceBus/the platform is already installed on their machine we do nothing. Existing installs can be detected in 2 ways:
init.ps1 will detect this and pop this page in the vs browser:
http://particular.net/download-the-particular-service-platform?version={nservicebus version}
Content trimmed. See full issue
This depends on the license pull
https://github.com/Particular/NServiceBus/pull/2022
Relates to #1993
It would be nice if you setup application icon in nservicebus.host.exe. This icon could simplify recognizing if this app on my task bar is nservicebus.host.exe
or maybe ConsoleApplication11.exe
. The same when I'm looking for nservicebus.host.exe
in windows explorer.
The reply to address of the workers are wrongly rewritten the distributors control address instead of the main address
This was broken in 4.4.2 by this change:
https://github.com/Particular/NServiceBus/commit/54a1da36b96500ac9807ed85828a5698bb607519
Unhandled Exception: System.ArgumentOutOfRangeException: The added or subtracted value results in an un-representable Da
teTime.
Parameter name: value
at System.DateTime.AddTicks(Int64 value)
at Particular.Licensing.LicenseExpirationChecker.HasLicenseDateExpired(DateTime licenseDate) in c:\Projects\NServiceB
us\src\NServiceBus.Core\App_Packages\Particular.Licensing\LicenseExpirationChecker.cs:line 28
at Particular.Licensing.LicenseExpirationChecker.HasLicenseExpired(License license) in c:\Projects\NServiceBus\src\NS
erviceBus.Core\App_Packages\Particular.Licensing\LicenseExpirationChecker.cs:line 9
at NServiceBus.Licensing.LicenseManager.InitializeLicense() in c:\Projects\NServiceBus\src\NServiceBus.Core\Licensing
\LicenseManager.cs:line 99
Content trimmed. See full issue
So when we show a windows form dialog it will set (or overwrite) the SynchronizationContext.Current
. This will result in callbacks being executed on SynchronizationContext
of the dialog and not the SynchronizationContext
of the executing process..
So the proposal for fixing this is to
SynchronizationContext.Current
SynchronizationContext
back to SynchronizationContext.SetSynchronizationContext
Thoughts?
If you configure your endpoint to use log4net like this:
XmlConfigurator.Configure();
Configure.With()
.Log4Net()
.AutofacBuilder(container)
.FileShareDataBus(BasePath)
.RavenSubscriptionStorage()
.UseRavenTimeoutPersister()
.UnicastBus();
Content trimmed. See full issue
If you use the regular host and an exception is thrown in either IWantCustomInitialization or INeedInitialization (and probably others), no error is logged. Instead, the service just dies with no indication of what the error was. This makes it quite difficult to troubleshoot errors when the host runs as a service.
This used to be logged as a fatal error in NSB 3.3.
SingleCallChannelReceiver
doesn't work with UnityBuilder
.
Logs with UnityBuilder
:
2013-12-02 10:04:43.9703 DEBUG NServiceBus.Gateway.Receiving.IdempotentChannelReceiver Received message of type SingleCallSubmit for client id: 4e5cde3c-b09e-4943-8379-b5a5f88d589e
2013-12-02 10:04:43.9863 DEBUG NServiceBus.Gateway.Channels.Http.HttpChannelReceiver Sending HTTP 200 response.
2013-12-02 10:04:44.0143 DEBUG NServiceBus.Gateway.Channels.Http.HttpChannelReceiver Http request processing complete.
When I change builder from UnityBuilder
to DefaultBuilder
log looks like this:
2013-12-02 10:18:44.5661 DEBUG NServiceBus.Gateway Received message of type SingleCallSubmit for client id: 9a85fc19-dd91-411d-9f82-2f7c793236ed
Content trimmed. See full issue
You can download this release from:
Published by yvesgoeleven over 10 years ago
This release consist of these issues that were achieved through these commits.
They point to the endpointname instead of the override. It was caused by logic related to the distributor that always changed the replyto header of subscription messages to the endpoint name.
It was discovered by investigating a windows azure related issue: https://github.com/Particular/NServiceBus.Azure/issues/122
You can download this release from:
This release consist of these issues that were achieved through these commits.
I have a simple console application that configures a bus (MSMQ) and sends a single message. Between version 4.3.4 and 4.4.0 the application has stopped working with the exception in the stack trace below.
Note that this only happens when running from a command window. It does not happen when running from visual studio (using host process or not). In both cases I am running in a non-elevated context.
In case it is down to user error, here is the guts of the bus configuration code that is failing:
Configure.Serialization.Xml();
bus = Configure.With()
.Log4Net()
.DefaultBuilder()
Content trimmed. See full issue
You can download this release from:
Published by SimonCropp over 10 years ago
This release consist of these issues that were achieved through these commits.
Before applying this release it is recommended that your read the release notes for 4.3.4 to check if the issue #1925 applies to you. #1925 When using NServiceBus version 4.3.x and an event is sent through a Distributor it is incorrectly received by multiple workers instead of just one.
OriginatingHostId
and ProcessingHostId
headers that represent the current "host"
We currently have the ProcessingMachine
and OriginatingMachine
headers. These do not accurately reflect all concepts of a "Host". For example when hosting in Azure.
So the headers OriginatingHostId
, HostId
and HostDisplayName
have been added to be environment agnostic where "machine" does not make sense.
The headers ProcessingMachine
and OriginatingMachine
have been marked as obsolete and will be removed in 5.0.
IWantToRunWhenBusStartsAndStops
Start
or Stop
throws an exception
Currently if the IWantToRunWhenBusStartsAndStops
methods Start
or Stop
throw an exception the endpoint still starts.
This can hides critical issues from the user.
We now raise a critical exception that will shutdown the bus.
So a ContainsKey
+ Item lookup takes approx twice as long as a TryGetValue
While this is a micro-optimization the correct approach, that uses TryGetValue
, is actually just as readable.
Stop
and Start
of the Bus causes a NullReferenceException
inside event subscriptions
When the bus is restarted using Bus.Start()
, Bus.Shutdown()
then Bus.Start()
timeout messages can throw an exception and end up in the error queue.
If a saga message handler requests any timeouts, the message being handled is rolled back and always ends up in error queue.
false
will result in a true
Ack
If a false
is passed in the Ack header AutoAck
will still be set to true
IStartableBus.Shutdown()
followed with IStartableBus.Start()
When self hosting, all messages are lost after restarting the bus (ie calling Shutdown
followed by Start
on IStartableBus
.
Messages are removed from the queue but no handlers are called.
Due to the pipeline not wrapping InMemory.Raise
in a child container an exception can be thrown
InvalidOperationException: Scope was not available. Did you forget to call container.BeginScope()?
IWantToRunWhenBusStartsAndStops.Stop
In v4 IWantToRunWhenBusStartsAndStops.Stop
is only allowed to run for a maximum of 20 seconds.
This limitation may not allow tasks to be completed successfully before shutting down the Windows service.
As such this timeout has been removed.
You can download this release from:
Published by indualagarsamy over 10 years ago
This release consist of these issues that were achieved through these commits.
When using the distributor in version 4.3.x
, and the workers are subscribing to an event, having the message mapping for the event in the app.config of the worker causes each worker to handle the event, instead of just one worker.
If you are affected by this bug:
Browse to your RavenDB url. if RavenDB is installed using the default ports the url is either http://servername:8080 or http://servername:8081, otherwise use the appropriate port number.
Identify the database of the publisher endpoint (the database name matches the endpoint name) and double click to open the database.
You will see the subscriptions list. If there are multiple subscription documents, Identify the subscription document based on the event type. For example, Example.Messages.Events.MyEvent
as specified in the MessageType
column.
Double click on the document to open the subscription list. Select the worker nodes that have been erroneously subscribed to the event and press delete.
Once the entries are removed, click on Save to save the document.
Using Microsoft SQL Management Studio, connect to the appropriate persistence database specified in the NServiceBus/Persistence
connection string in the app.config of the endpoint
<connectionStrings>
<add name="NServiceBus/Persistence" connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=NSERVICEBUS;Integrated Security=True" />
</connectionStrings>
Find out the erroneous subscribers by running
select *
FROM [NServiceBus].[dbo].[Subscription]
where TypeName='Example.Messages.Events.MyEvent'
To clear out the subscriptions for the event Example.Messages.Events.MyEvent
, delete the subscription entries for the workers. For example:
delete
FROM [NServiceBus].[dbo].[Subscription]
where TypeName='Example.Messages.Events.MyEvent'
and SubscriberEndpoint in ('Example.NServiceBus.Worker@machine1', 'Example.NServiceBus.Worker@machine2')
You can download this release from:
Published by andreasohlund over 10 years ago
This release consist of these issues that were achieved through these commits.
Version 4.3.0 introduced a bug where the NServiceBus.Version header didn't get populated for the control messages containing the subscribe/unsubscribe requests. This meant that our mutators didn't mutate them correctly causing the requests to be misinterpreted.
Affected transports: Msmq, SqlServer
Repro
Content trimmed. See full issue
You can download this release from:
Published by indualagarsamy almost 11 years ago
This release consist of these issues that were achieved through these commits.
When we fixed issue #1837 in version 4.3.1
, a check was added to ignore the address count and call the SubscriptionManager.Subscribe
passing in null as the endpoint address for brokered transports with centralized pub sub support. While it works for ActiveMQ and RabbitMQ, the azure transport expects an address. Passing in null causes a NRE.
Our current way of handling licenses in the registry is wrong since it looks for a subkey containing the {major}.{minor}. This means that users that have installed a 4.2/4.3 license will have to reinstall it again for 4.4 even though the license it self is valid for 4.4
When publishing using interface-defined events and when the messageConstructor not defined, an exception is thrown and the event is not published.
Get-NServiceBusVersion commandlet reported the version of NServiceBus.Powershell.dll
and not the version of the NSB within the solution. NServiceBus.Powershell dll has been separated from the core in order that it could be released independantly of the core if need be. This commandlet does not make sense, as we can have multiple endpoints referencing different versions of NServiceBus on the same machine.
You can download this release from: