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?
Related
getting error:
2020-01-20 21:15:29,599 WARN [io.net.cha.DefaultChannelPipeline] (vert.x-eventloop-thread-0) An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception.: io.netty.handler.codec.http.websocketx.CorruptedWebSocketFrameException: Max frame length of 65536 has been exceeded.
at io.netty.handler.codec.http.websocketx.WebSocket08FrameDecoder.protocolViolation(WebSocket08FrameDecoder.java:426)
at io.netty.handler.codec.http.websocketx.WebSocket08FrameDecoder.decode(WebSocket08FrameDecoder.java:286)
Very hard to tell "what" is implementing the websocket server and how to modify the configuration.
Vert.x core has a HttpServerOptions with maxWebsocketFrameSize that "might" be the correct thing to increase, or even the maxWebsocketMessageSize that when increased, might increase the frameSize?
Cannot find any way to clear up this exception when client sends a big message to the server over the websocket channel. (it is text message)
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.
Even with debug enabled for RemoteConfig, I still managed to get the following:
Error fetching remote config values Optional(Error Domain=com.google.remoteconfig.ErrorDomain Code=8002 "(null)"
UserInfo={error_throttled_end_time_seconds=1483110267.054194})
Here is my debug code:
let debug = FIRRemoteConfigSettings(developerModeEnabled: true)
FIRRemoteConfig.remoteConfig().configSettings = debug!
Shouldn't the above prevent throttling?
How long will the throttle error remain in effect?
I've experienced the same error due to throttling. I was calling FIRRemoteConfig.remoteConfig().fetchWithExpirationDuration with an expiry that was less than 60 seconds.
To immediately get around this issue during testing, use an alternative device. The throttling occurs against a particular device. e.g. move from your simulator to a device.
The intention is not to have a single client flooding the server with fetch requests every second. Make sensible use of the caching it offers out of the box and fetch only when necessary.
When you receive this error, plug the value of error_throttled_end_time_seconds into an epoch converter (like this one at https://www.epochconverter.com) and it will tell you the time when throttling ends. I've tested this myself, and the throttling remains in effect for 1 hour from the first moment you are throttled. So either wait an hour or try some of the other recommendations given here.
UPDATE: Also, if you continue making config requests and receive the throttle error, the expire timeout does not increase (i.e. "you are not further penalized").
The quick and easy hack to get your app running is to delete the application and reinstall it. Firebase identifies your device as new device on reinstalling.
Hope it helps and save your time.
I am using flex remoting to php, and it works very well, except I occasionally get these 'Invalid URL' fault messages.
In the message below, notice it is using an ip address. SO, no dns lookup issue.
There are usually minimum 10, up to 50 users logged in to this application at one time and there are only a few faults (not at the same time), so I dont think it was a server or larger network issue.
This particular message is to the PollService, so that tells me this user has already communicated with the server a number of times. For example, to log in and to load across other data. The polling is an every 10 seconds flex timer that calls the remote service.
SO, I am trying to figure out if this is an error on the server side, returning something flex did not like, or if it is in fact some lower level network/communications issue, OR possibly something else like an internal flex glitch? Then I would like to figure out how to appropriately handle this fault - maybe re-transmit after a delay?
PollService Send failed Client.Error.MessageSend Channel.Connect.Failed error Invalid URL url:
'http://172.16.10.26:80/amf/indexPoll.php' [ChannelFaultEvent faultCode="Channel.Connect.Failed"
faultString="error" faultDetail="Invalid URL url: 'http://172.16.10.26:80/amf/indexPoll.php'" channelId=null
type="channelFault" bubbles=false cancelable=false eventPhase=2]
Thanks!
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?