We required to consume messages from VM in a flow. Currently it is throwing an error when VM is empty as below:
Message : Tried to consume messages from VM queue 'FQ' but it was empty after timeout of 5 SECONDS Payload Type : org.mule.runtime.core.internal.streaming.bytes.ManagedCursorStreamProvider
For now we wrapped it in try catch block and handling this error(still it is printing the error stack trace, we want to avoid it)
I want to check is there a way or piece of code that can be used for checking the number of messages available in VM before consuming it.
You can use the logException attribute on the error handler so the exception is not printed in the log.
Example:
<try doc:name="Try">
<vm:consume doc:name="Consume" config-ref="VM_Config" queueName="q1" />
<error-handler >
<on-error-continue enableNotifications="true" logException="false" doc:name="On Error Continue" type="VM:EMPTY_QUEUE">
<logger level="INFO" doc:name="Logger" message="consume timeout"/>
</on-error-continue>
</error-handler>
</try>
Related
I am new to Mule and i am working on a company project. I have many inbound-endpoints defined in XML in a single flow. I am trying to get the processor "scbProcessor" that processes the response to work asynchronously in the inbound-endpoint.
I tried to just wrap the processor in <async></async> but it gives the error: "Invalid content was found starting with element 'async'". Then I tried to make it sub-flow then reference to flow, which gave the same error.
Code:
<flow name="scb-services">
<composite-source doc:name="Composite Source inbounds">
<https:inbound-endpoint exchange-pattern="request-response" host="${httpInbound.secure.host}"
port="${httpInbound.secure.port}" doc:name="HTTPS QWE Service (Deprecated)"
path="${httpInbound.qwe.contextRoot}/${auto.external.serviceName}"
responseTimeout="${service.qwe.auto.timeout}" connector-ref="httpsConnector">
<mule-ss:http-security-filter realm="mule-realm"/>
<mule-ss:authorization-filter requiredAuthorities="PUBLIC"/>
<response>
<set-variable variableName="outgoingFromESBToClientDate"
value="#[new org.mule.el.datetime.DateTime()]"
doc:name="Register Outgoing date from ESB to Client"/>
<processor ref="scbProcessor" doc:name="SCB Logging Processor"/>
</response>
</https:inbound-endpoint>
.
.
</composite-source>
</flow>
.
.
You can change exchange-pattern="request-response" to exchange-pattern="one-way"to send the messages asynchronously. You can see it in the official documentation: https://docs.mulesoft.com/mule-runtime/3.6/http-transport-reference
Alternatively, you can use a queue in between. Send the message to queue as soon as it is received and then process it after reading it from the queue.
When our service fails to deliver an email, the rejection notification returned to the sender contains the stack trace of the code that failed. Is there a way to send the delivery notification, without the attached errors?
We have a postfix server that handles incoming emails in a catchall python script. That script uploads the email to one of our services and throws an exception in case it failed.
This is the template we are using
failure_template = <<EOF
Charset: us-ascii
From: MAILER-DAEMON (Mail Delivery System)
Subject: Undelivered Mail Returned to Sender
Postmaster-Subject: Postmaster Copy: Undelivered Mail
This is the mail system at host $myhostname.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to <postmaster>
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
EOF
Expected result would be just the template notification, without the strack trace of the catch-all script.
The mail server simply includes in the bounce whatever your Python program displays on its standard error. Maybe call the script via a wrapper which saves the standard error to a sane place (or even discards it, if you are sure it never contains anything useful).
#!/bin/sh
python3 /path/to/deliver.py 2>>/var/log/deliver.log
Your mail server obviously needs to have write access to the log, and you'll probably want to set up periodic log rotation for the file.
Probably a better overall approach is for the Python program to not crash.
I have created a small BizTalk application which has a single dynamic send port with the Delivery Notification == transmitted.
The send port is configured to a folder path and when the folder is not exist it suspends the orchestration. When I try to resume the orchestration after creating the folder. I'm getting two instances in the BizTalk query expression. the instance err messages are
Status : Suspend(Not resumable)
Error code : 0xC0C01B4e (Routing Failure Report)
Routing Failure Report for "Routing Failure Report for """
Status : Suspend(resumable)
Error code : 0xc0c01b02
Error Description: The published message could not be routed because no subscribers were found.
NOTE:
I'm getting this error message only when I set the Delivery notification == transmitted
This works fine in some environment.
it might be because the pipeline define in the receive location was not set to be an XML pipeline. Change the pipeline and it should work.
There will always be 2 failure instances in case of routing failure:
First is a non resumable, information only "Routing failure report".
Second is the actual message which was not routed because no subscriber found. Hence "the published message could not be routed because no subscribers were found." This is similar to "Exception occurred when persisting state to the database." error message we see in case of Orchestration routing failures.
Now whats is the difference:
The Suspend(resumable)instance will have the message body present, and you will be able see the contents(body) of the message. However the context properties of that message won't help you finding the reason of routing failure.
However the Suspended(Not resumable) message will have the required "Context properties" which will help you determine the reason of routing failure. That's why we see following
"This service instance exists to help debug routing failures for instance "{your message instance id}". The context of the message associated with this instance contains all the promoted properties at the time of the routing failure."
Can someone help me with this problem that occurs whenever you run a TRIGGER, but works in a normal PROCEDURE?
TRIGGER:
create or replace
procedure testeHTTP(search varchar2)
IS
Declare
req sys.utl_http.req;<BR>
resp sys.utl_http.resp;<BR>
url varchar2(500);
Begin
url := 'http://www.google.com.br';
dbms_output.put_line('abrindo');
-- Abrindo a conexão e iniciando uma requisição
req := sys.utl_http.begin_request(search);
dbms_output.put_line('preparando');
-- Preparandose para obter as respostas
resp := sys.utl_http.get_response(req);
dbms_output.put_line('finalizando response');
-- Encerrando a comunicação request/response
sys.utl_http.end_response(resp);
Exception
When Others Then
dbms_output.put_line('excecao');
dbms_output.put_line(sys.utl_http.GET_DETAILED_SQLERRM());
End;
close your user session and then the problem is fixed.
Internal there is a limit from 5 http requests.
Might a problem is the missing: utl_http.end_response
or an exception in the app and not a close from the resp object.
modify the code like that:
EXCEPTION
WHEN UTL_HTTP.TOO_MANY_REQUESTS THEN
UTL_HTTP.END_RESPONSE(resp);
you need to close your requests once you are done with them, it does not happen automatically (unless you disconnect form the db entirely)
It used to be utl_http.end_response, but I am not sure if it is the same api any more.
Usually we need UTL_HTTP.END_RESPONSE(resp); to avoid of ORA-29270: too many open HTTP requests, but I think I reproduced the problem of #Clóvis Santos in Oracle 19c.
If web-service always returns status 200 (success) then too many open HTTP requests never happens. But if persistent connections are enabled and web-service returns status 404, behavior becomes different.
Let`s call something that always return 404.
First call of utl_http.begin_request returns normally and opens new persistent connection. We can check it with select utl_http.get_persistent_conn_count() from dual;. Second call causes an exception inside utl_http.begin_request and persistent connection becomes closed. (Exception is correctly handled with end_response/end_request).
If I continue then each odd execution returns 404 normally and each even execution gives an exception (handled correctly of course).
After some iterations I get ORA-29270: too many open HTTP requests. If web-service returns status 200 everything goes normally.
I guess, it happens because of the specific web-service. Probable it drops persistent connection after 404 and doesn't after 200. Second call tries to reuse request on persistent connection but it doesn't exist and causes request leak.
If I use utl_http.set_persistent_conn_support (false, 0); once in my session the problem disappears. I can call web-service as many times as I need.
Resolution:
Try to switch off persistent connection support. Probable, on the http-server persistent connections work differently for different requests. Looks like a bug.
I have published the BlazorApp1 app created by the VS2019 Blazor template to a production server. Since it is a sub-site, I made 3 changes:
in _Host.cshtml replaced the base tag with <base href="/BlazorApp1/" >
in Startup.cs added app.UsePathBase("/BlazorApp1")
in web.config, changed the hostingModel to outofprocess and stdoutLogEnabled to true
When navigating to the site I almost always get the following error:
Unhandled Exception Page must be reloaded
This is displayed in the browser console: (replaced my site with contoso)
[2020-06-02T18:39:49.445Z] Information: Normalizing '_blazor' to 'http://www.contoso.com/BlazorApp1/_blazor'. blazor.server.js:1:5212
[2020-06-02T18:39:49.936Z] Information: WebSocket connected to ws://www.contoso.com/BlazorApp1/_blazor?id=5yq6pI_jo1ByPZtskEjjmw. blazor.server.js:1:5212
[2020-06-02T18:39:50.132Z] Error: The circuit failed to initialize. blazor.server.js:15:27309
log http://www.contoso.com/BlazorApp1/_framework/blazor.server.js:15
C http://www.contoso.com/BlazorApp1/_framework/blazor.server.js:8
S http://www.contoso.com/BlazorApp1/_framework/blazor.server.js:8
invokeClientMethod http://www.contoso.com/BlazorApp1/_framework/blazor.server.js:1
invokeClientMethod .../BlazorApp1/_framework/blazor.server.js:1
processIncomingData .../BlazorApp1/_framework/blazor.server.js:1
onreceive .../BlazorApp1/_framework/blazor.server.js:1
onmessage .../BlazorApp1/_framework/blazor.server.js:1
[2020-06-02T18:39:50.141Z] Information: Connection disconnected. blazor.server.js:1:5212
Error: Invocation canceled due to the underlying connection being closed. blazor.server.js:1:20001
I can't find any other clues about what's happening. There are no exceptions shown in the log.
The problem was resolved by using only lowercase characters in the <base> tag:
<base href="/blazorapp1/" >
It has just happened to me as well, but I had the base tag specified correctly. This error can also occur in a rare case when you have ambiguous constructors defined for one of your dependency injected services if both match all the parameters (possibly by accident due to inheritance). The verbose log won't point to that issue. Be aware that purposeful creation of multiple constructors for dependency injected services is considered an anti-pattern.
For me it happened because I put an async call inside a constructor of a class in DI, so, yeah, that's a stupid error which can mean anything.