I have an error queue in ActiveMQ, which is populated by Apache Camel's onException error handler. There could be thousands of messages in this queue.
Instead of using the ActiveMQ web console, I am building a custom web admin to integrate several other statistics from other components as well. Thus, I wanted to include the statistics from ActiveMQ as well.
ActiveMQ version: 5.14.3
I have looked at Jolokia JMX API, and its operations. For instance, I have the following payload to the broker's Jolokia API endpoint:
{
"type": "exec",
"mbean": "org.apache.activemq:type=Broker,brokerName=localhost,destinationType=Queue,destinationName=test.errors",
"operation": "browse(java.lang.String)",
"arguments": ["EXCEPTION_TYPE LIKE '%jdbc%'"]
}
The header field EXCEPTION_TYPE is already populated via Apache Camel Route. I have more than 10k messages in this queue at the moment. I made a POST request to my broker API endpoint with the payload as shown above. Although I had more than 10k messages, this request resulted in just 400 messages (due to the max page size limitation, hard coded in the source code). This means that I will not be able to get more than 400 messages at a time via Jolokia. I also tried the browseMessages() method as well. Looks like, it does the same thing, in general.
Is it possible to browse these messages (let's say if they are high in number, may be around 10k+)?
Or, is it possible to paginate them? I could not see a relevant operation method for that.
I tried to see if Hawtio did something special in retrieving all the messages. But, the result is same( with max 400 messages).
ActiveMQ web console does fetch all the messages. This probably could be because it is tightly coupled with the ActiveMQ project.
I am not restricted to just JMX/Jolokia. If these stats can be fetched via some API, its equally fine.
Any inputs would be great !
Related
I have build a simple cloud-SDK based application for adding as a Webhook in Enterprise messaging queue to receive the events as soon as it gets inside the queue.
I have an OPTIONS and POST function. OPTIONS is for the handshake with the queue and it works.
Now, when there is message in the Queue, it hits my application with the POST block but the request body is coming as empty object.
I have tried the same from the postman, i'm able to receive the data in request body. Only from the Enterprise messaging queue, the data is empty.
In contrast, to verify this, I have used a Express based nodejs application, there i'm able to receive the data from the queue.
What am i missing in the Cloud-SDK based code ?
POST block, looks like this
#Post('ems-events')
receiveEmsEvents(#Body() requestBody: string, #Req() req:Request) {
Logger.log("Event Received with Data:");
Logger.log(requestBody);
Logger.log(req.body);
Logger.log("Log over--");
Logger.log(Object.keys(req));
return {};
}
The SAP Cloud SDK for JavaScript does not offer any support for Enterprise Messaging as of today. The code you're writing here is most likely Nest.js code, which is an independent framework.
That being said, Nest.js does run Express.js under the hood by default. So if you've been able to make it work in Express, you should be able to make it work in Nest.
I want to create live notifications for my website.
Reference link: http://sinhamohit.com/writing/spring-boot-reactive-sse
Above link contains example for SSE and Event Source. The stream of objects is created to create Flux stream.
In my case, I want to create server sent events and send them to RabbitMQ server, the rest controller should be able to listen to message queue and receive the message.
Right now I am able to receive the messages, but I am not sure how I can convert them into Flux and send the stream to rest URL.
How should I do it?
Refernces, links and examples will be great.
Refer following link, here activemq is used but you can also use RabbitMQ.
I'm trying to figure out how the service worker works in regards to cache headers in responses. I have implemented a couple of service workers now but have never had to bother worrying about caching headers, how long items should be cached for etc. I'm now implementing it on an enterprise production site, whereby this stuff actually really matters.
Basically when using a service worker, is the http cache completely bypassed?
Do I then need to build a framework to handle resource expiration/invalidation like the http cache used to do for us? Or am I talking rubbish?
Would be super helpful if someone could provide some clarification of this. The way I see it there are 3 potential scenarios:
A). Network request => Service worker fetch => (Browser cache?) <=> Server
B). Network request <=> (Browser cache?) <=> Service worker fetch <=> Server
C). Network request => Service worker fetch <=> Server
I've tested this locally and it seems that C). is the correct implementation, whereby we the developer have sacrificed cache header/duration abstraction for control.
I'm fine with this, just want it clarifying before I run off and build a framework for reading and honouring caching headers in the service worker.
A) is the correct model. If a service worker controls a page, all network requests will trigger the fetch event handler of the service worker prior to consulting the browser cache or the network.
In turn, any time the service worker makes a network request, either explicitly via fetch() or implicitly via cache.add()/cache.addAll(), the browser's "traditional" cache is consulted for a response first. A network request to the server will only be made if there isn't a valid response in the browser cache.
This sometimes works in your favor, and sometimes can expose you to subtle bugs if you don't expect that behavior.
There's a very detailed explanation of this interaction at https://jakearchibald.com/2016/caching-best-practices/, specifically covering things to avoid and ways to take advantage of this behavior.
That depends on how you configure request. With Fetch API you can control how request interacts with browser HTTP Cache.
For example you can set request's cache mode to no-store so it will bypass HTTP Cache. Or you can set request's cache mode to force-cache so browser will return cached response even if it is stale:
fetch("some.json", {cache: "force-cache"})
.then(function(response) { /* consume the response */ });
By default request's cache mode is default. In this case request will act as usual. Obviously that is only if service worker actually performs request instead of returning some hardcoded response.
For more information check Fetch Standard, Request.cache MSN page and Using Service Workers MDN page.
First a little explanation; I have a system, lets call it SystemA that I can configure to send http Posts to a url I specify when something goes wrong, but can't modify the request body directly.
My goal is to get the body of the post request to a storm spout via a redis pubsub queue.
I know I can publish to the redis pubsub channel by doing a POST to webdis like:
url: http://127.0.0.1:7379/
body:/PUBLISH/channelname/someimportantinfo
Since I can't modify the body of the POST from SystemA to prepend the /PUBLISH/channelname I was hoping I could structure the request like:
url: http://127.0.0.1:7379/PUBLISH/channelname
body:someimportantinfo
but that does not work; I don't get an error the event just never flows through the channel.
Any thoughts on how to get around this.
Your problem could be solved by adding a "shim" between SystemA and WebDis interface.
This shim will receive the HTTP post request from SystemA, extract the body and then send the request to Redis in the desired format.
Since you want to feed this data into Storm only when something goes wrong, I don't think this approach is going to be a bottle neck in your system (hopefully, your system isn't generating errors every second!).
Using WSO2 API Manager 1.3.1. Trying to use the API Manager to proxy to a REST service. I have set up the service in API Mgr and can successfully post and get responses, typically json, though some are text.
However, when I try to GET a resource that returns binary content (a zip "file", content-type:application/octet-stream), the API Manager does not seem to respond and I can see an error in the console window (i'm running wso2server.bat in console):
[2013-07-03 11:52:05,048] WARN - SourceHandler Connection time out
while writing the response: 173.21.1.22:1268->173.21.1.22:8280
I have an HTTPModule on my internal service and it seems to be responding with the appropriate content (I can see the GET and response data logged). I can also call to the internal service directly and get a response, so that end of things seems OK. But going through the API Manager seems to fail.
I found information on enabling other content-types:
WSO2 API Manager - Publishing API with non-XML response
http://wso2.com/library/articles/binary-relay-efficient-way-pass-both-xml-non-xml-content-through-apache-synapse
Using that information I tried to enable the application/octet-stream for messageFormatter and messageBuilder using the binary relay and it did not help (or seem to make a difference). I have even disabled all other content-types and use the binary relay for all content-types and it does not help.
Currently, I'm running with just the following in both axis2.xml and axis2_client.xml (in their appropriate sections):
<messageBuilder contentType=".*" class="org.wso2.carbon.relay.BinaryRelayBuilder"/
<messageFormatter contentType=".*" class="org.wso2.carbon.relay.ExpandingMessageFormatter"/>
I still get my json and text responses, but WSO2 times out getting the zip content. I saw the JIRA referenced in axis2.xml about enabling the ".*" relay, but as the other requests seem to work, I'm not sure it's an issue for me. I did try adding
'format="rest"' to the API definition, but it seemed to break all operations even the ones that worked prior so I've pulled it back out.
Any ideas on what is happening or how to dig in and debug this will help. Thanks!
After working with this for much too long, it turns out that my WSO2 configuration was correct, using the Message Relay and BinaryRelayBuilder, etc. While my REST service could reply immediately, I was setting a HTTP header that I assume WSO2 does not like, because when i removed it WSO2 would reply at an expected rate (instantly).
I was setting the header:
Transfer-Encoding: binary
When I removed that header from my service reply, then WSO2 operated as expected. I don't know if that's a "bug" in WSO2 or if I was implementing incorrectly, but I do have what seems like a "workaround" by omitting that header from my service response.