We have an NServiceBus 6 environment with a number of services that send files between each other using DataBusProperty over a custom SqlDataBus : IDataBus.
This works fine on NSB6 using the built in JSON serializer, but is now broken after we moved to NSB7 and the NewtonsoftSerializer.
Removing DataBusProperty from our classes and just using byte[] works fine. We also tried changing the DataBus to FileShareDataBus but got the same exception:
NServiceBus.MessageDeserializationException: An error occurred while attempting to extract logical messages from incoming physical message c7b5cd47-c1b7-4610-9f6c-aa7800cc9b64 --->
Newtonsoft.Json.JsonReaderException: Error reading bytes. Unexpected token: StartObject. Path 'Data.Key', line 1, position 68.
This fails even if a service is sending messages to itself. Also we can see the files written to the file store, whether on Sql or File Share, so they're serializing fine.
An example payload from the error queue is
{"ExecutionId":"1db85105-a71c-4b29-87da-9b7ae6518c1c","Data":{"Key":"2019-06-26_13\\6a2b63c7-12b0-46dd-8b92-f1fc743d27c1","HasValue":true}}
How can we get this to deserialize in NSB7+NewtonsoftSerializer when it works fine in NSB6+JsonSerializer?
Thanks
I just spent about 8 hours trying to figure out what was going on, and realized, that for whatever reason, NSB7 wants a paramaterless constructor and settable properties. I am going back to Particular to see if this change is expected, but I expect we will have to adjust all of our message classes to fit that paradigm.
Although data bus properties should work there is also an alternative to data bus properties which is using stream attachments via send options:
https://docs.particular.net/nservicebus/messaging/attachments-sql
Depending on the use case using Streams might be a more efficient approach.
Related
I am using firebase v4 to push notifications to android devices. When the Send method of the instance of messaging.Client fails, I only get a string error value and I wonder if this error string is localized. If not, I could compare it against e.g. "Requested entity was not found." to detect devices that have uninstalled my app. Is this string always plain english or does this depend on the locale the app is running under? Or does this error string come from the server, so I can never be sure if it stays the same?
What other options do I have to properly detect such an error, even if my golang binary runs on computer systems with any locale or language? I am running my golang binary on windows.
Any help or insights appreciated,
--
Stefan
In general, all error messages from Firebase SDKs are in English only. They are generally not suitable for display or comparison in an app. You should instead use the provided error codes (which will not vary) in the error or exception object to determine what exactly went wrong.
I'll try provide as much information as possible:
No error message.
The instance stays in the "ready service instances".
The receive location has the same parameters (except URI, the three polling queries, user account/pw and receive pipeline) as another receive location that points to another database/table which works.
The pipeline is waiting for the correct schema.
The port surface and receive location are both waiting for the correct schema.
In my test example, there are only 10 lines being returned.
The message, which contains those 10 lines, validates against the schema.
I tried to let the instance alone to no avail - 30+ minutes - and no change in its condition.
I had also tried suspending and then resuming it which then places the instance in the "dehydrated orchestrations" list. Again, with no error message.
I'm able to get the message by looking at the body of the message that's in the "ready to run" service. (This is the message that validates versus the schema I use in Visual Studio.)
How might something like this arise?
Stupid question, but I have to ask... Is the corresponding host instance running?
I am trying to Enqueue a message onto an Oracle Queue from a .NET client. If the message exceeds a certain size, the following error occurs:
ORA-01013: user requested cancel of current operation
This happens with both XMLTYPE and raw as the queue table's message type.
It seems that the size of the message is to blame but cannot tell for sure be cause of the limited Oracle error message.
Is there a limit on the size, can I increase the size or is there another way to overcome this issue?
Update:
I am able to send the message directly with dbms_aq.enqueue(...)
Setting the timeout from the .NET client does not have any effect. (It times out immediately regardless of the timeout value)
This sounds like a connection timeout from the .net client. Try increasing the timeout. If that doesn't work, check if the issue is with the message payload by inserting the message directly through dbms_aq.enqueue(...). If you are able insert, then the message itself is fine.
There are a couple of size-related issues being fixed for 11.2.0.3. See this non-authoritative list here:
http://www.eygle.com/Notes/11.2.0.3.html
Some examples:
9878459 Specific length object binds over 4k may be bound as NULL
10389881 Raw buffered message payload > 8k corrupted when dequeued
from a buffered queue
Maybe, your issue is in this list?
I'm relatively new to Biztalk and I'm having a bit of hassle with this:
I have built a simple orchestration, hooked it up correctly to a receive port, I'm using the correct schema and map and the orchestration seems to be subscribing ok.
However, when the file I want to process gets picked up at the port I'm getting the 'could not be routed because no subscribers were found' error.
I ran a HAT query and can see the orch has an active subsription to the correct thing, is there anything else I can check on this?
Is your port hooked directly to the orchestration or is the orchestration picking the message up from the message box? Has the orchestration receive been set to Activate?
What does your subscription filter look like for the orchestration?
As a futher test:
a) create a sendport (FILE)
b) add a filter to it; BTS.ReceivePortName =
c) grab the resulting file - it should be the XML thats produced by your Custom PL
d) Use this file with a receive location using an XML Receive PL and see how your orchestration reacts to
This will at least rule out a Pipeline issue...
HTH
Check your pipeline is XMLReceive. This will promote the MessageType property and hopefully your orchestration will subscribe successfully.
Find the failed message in HAT and look at the body of the message. Copy it out and then run validate it against the schema of the message you are expecting. If it doesn't validate then you have set your flat file disassembler up incorrectly.
For a user application (not a driver) using WinUSB, I use WinUsb_ControlTransfer in combination with overlapped I/O to asynchronously send a control message. Is it possible to cancel the asynchronous operation? WinUsb_AbortPipe works for all other endpoints but gives an 'invalid parameter' error when the control endpoint is passed (0x00 or 0x80 as the pipe address). I also tried CancelIo and CancelIoEx but both give an 'invalid handle' error on the WinUSB handle. The only related information I could find is on http://www.winvistatips.com/winusb-bugchecks-t335323.html, but offers no solution. Is this just impossible?
Probably not useful to the original asker any more, but in case anyone else comes across this: you can use CancelIo() or CancelIoEx() with the file handle that you originally passed in to WinUsb_Initialize().
This is similar to how the documentation of WinUsb_GetOverlappedResult says:
This function is like the Win32 API routine, GetOverlappedResult, with one difference—instead of passing a file handle that is returned from CreateFile, the caller passes an interface handle that is returned from WinUsb_Initialize. The caller can use either API routine, if the appropriate handle is passed. The WinUsb_GetOverlappedResult function extracts the file handle from the interface handle and then calls GetOverlappedResult.