While creating Data service, I see 'Enable Batch Request', 'Enable Box Carring' options while developing SQL.
It is clear that these are used for processing batch records.
Could you please let me know how many records(100, 200 or what is the default setting) are handled by these two options at once when invoked.
If I want to change the default settings, how it can be done.
Regards,
Abhishek
There is no default setting, you pass one record it works , you pass 100 records it works, it all depends upon your request and you cannot change anything in it , if you want to limit the number of records then you can do that using wso2 esb, so wso2 esb you frame a request with limited records and then pass to DSS the advantage is that you can control the request in ESB as per your requirement.
Related
I have .Net core App deployed on azure and enabled application insights.
Sometimes Azure application insights End-to-end transaction details do not display all telemetry.
Here it only logs the error and not request or maybe request logged but both do not display together over here(difficult to find out due to many people use it)
Should be like:
Sometimes request log but with no error log.
What could be the reason for happening this? do I need to look into application insights specific set-up/feature?
Edit:
As suggested by people here, try to disable the Sampling feature but still not works, Here is open question as well.
This usually happens due to sampling. By default, adaptive sampling is enabled in the ApplicationInsights.config which basically means that only a certain percentage of each telemetry item type (Event, Request, Dependency, Exception, etc.) is sent to Application insights. In your example probably one part of the end to end transaction got sent to the server, another part got sampled out. If you want, you can turn off sampling for specific types, or completely remove the
AdaptiveSamplingTelemetryProcessor
from the config which completely disables sampling. Bear in mind that this leads to higher ingestion traffic and higher costs.
You can also configure sampling in the code itself, if you prefer.
Please find here a good overview of how sampling works and can be configured.
This may be related to :
When using SDK 2.x, you have to track all events and send the telemetries to Application insights
When using auto-instrumentation with 3.x agent, in this case the agent collect automatically the traffic, logs ... and you have to pay attention to the sampling file applicationinsights.json where you can filter the events.
If you are using java, below the accepted Logging libraries :
-java.util.logging
-Log4j, which includes MDC properties
-SLF4J/Logback, which includes MDC properties
I'm using Node.js and ws for my WebSocket servers and want to know the best practice methods of tracking connections and incoming and outgoing messages with Azure Azure Application Insights.
It appears as though this service is really only designed for HTTP requests and responses so would I be fine if I tracked everything as an event? I'm currently passing the JSON.parse'd connection message values.
What to do here really depends on the semantics of your websocket operations. You will have to track these manually since the Application Insights SDK can't infer the semantics to map to Request/Dependency/Event/Trace the same way it can for HTTP. The method names in the API do indeed make this unclear for non-HTTP, but it becomes clearer if you map the methods to the telemetry schema generated and what those item types actually represent.
If you would consider a receiving a socket message to be semantically beginning an "operation" that would trigger dependencies in your code, you should use trackRequest to record this information. This will populate the information in the most useful way for you to take advantage of the UI in the Azure Portal (eg. response time analysis in the Performance blade or failure rate analysis in the Failures blade). Because this request isn't HTTP, you'll have to mend your data to fit the schema a bit. An example:
client.trackRequest({name:"WS Event (low cardinality name)", url:"WS Event (high cardinality name)", duration:309, resultCode:200, success:true});
In this example, use the name field to describe that items that share this name are related and should be grouped in the UI. Use the url field as information that more completely describes the operation (like GET parameters would in HTTP). For example, name might be "SendInstantMessage" and url might be "SendInstantMessage/user:Bob".
In the same way, if you consider sending a socket message to be request for information from your app, and has meaningful impact how your "operation" acts, you should use trackDependency to record this information. Much like above, doing this will populate the data in most useful way to take advantage of the Portal UI (Application Map in this case would then be able to show you % of failed Websocket calls)
If you find you're using websockets in a way that doesn't really fit into these, tracking as an event as you are now would be the correct use of the API.
By reading the Handing off work section in wiki, it seems that you can do one way publishing in rebus with one way mode. But I thought one way mode only allows bus.send?
If in a scenario, where I have two applications both can publish SomethingHappened message, but only one of the application should handle the reply from ProcessManager, e.g. DoSomethingElse, how should I configure rebus for both applications?
Regards
Yin
But I thought one way mode only allows bus.send?
Nothing will prevent you from doing a bus.Publish from a one-way client as long as it has a properly set up subscription storage. And if something else populates that subscription storage with some subscriptions (e.g. you, by inserting them manually in the db, or by having another publisher handle subscribe/unsubscribe) then something might actually happen when you publish ;)
how should I configure rebus for both applications?
Without having a totally clear image of your scenario, I'm thinking that
one publisher, A, has an input queue: publisherA
the other publisher, B, has no input queue (i.e. it's a one-way client)
the two publishers share their subscription storage (e.g. a table in SQL Server)
the two publishers publish messages from assembly StuffToPublish
other endpoints have an endpoint mapping that maps StuffToPublish to publisherA - therefore, a bus.Subscribe with an event type from StuffToPublish will make publisher A establish the subscription
published messages from A and B will go to the same subscribers because they share their subscription storage
If you want publisher A to handle replies even though the event was published by publisher B, you can make B supply the rebus-return-address header (which would otherwise automatically be set, had B had an input queue) like so:
bus.AttacheHeader(someEvent, Headers.ReturnAddress, "publisherA");
This way, replies will be sent to the publisherA input queue.
Is there a way (without actually keeping a state in a external application and scanning the configuration database) to detect a configuration change in BizTalk Server?
I know there are timestamps for changes for the different artifact in the configuration database but are there any sort of general flag that indicate a change?
I'd like to for example kick of a process as a change occurs and for example log current configuration - without adding triggers or similar things.
No, there is no 'change notification' built into the product nor is there an 'official' way to track or identify changes.
Of course, there are various techniques you can use to identify changes such as monitoring timestamps, examine the SQL Logs, etc, but that would be a custom implementation.
BizTalk 360 has a robust auditing feature that might cover what you're really asking for.
From experiance, this question of 'tracking changes' is driven by governance scenarios where controls and access are more open then they should be. That's a management problem.
I am using JBoss JMX Console to monitor my Web Application.
How can i find what http requests are being processed at any point in time?
For eg: I see 25 busy theads - i want to know what http requests are these threads processing.
I am not really sure if there is an ability to map a specific request to a thread but you can certainly see what HTTP requests are made to Tomcat using AccessLogValve. You can probably use the timestamps to map those requests if need be.
Jasper;
The arduous way to do this is to examine every instance of the MBeans that have this pattern:
jboss.web:name=HttpRequest1,type=RequestProcessor,worker=http-0.0.0.0-18080
They are MBeans that represent the web request serving threads and they have an attribute called currentQueryString which is the query string of the request currently being processed. There are also attributes for currentUri and method. You could script the collection of this data as well.
An easier way, which is enabled in JBoss servers by default, is to use the available at:
http://localhost:8080/web-console/status
It handily aggregates those same MBean's and reports them in one page.
There is also options for a fuller report
http://localhost:8080/web-console/status?full=true
and an XML formatted output
http://localhost:8080/web-console/status?XML=true