JBoss ESB pipeline interceptor triggers multiple times - jboss

I am working on a project that "sniffs" (intercepts) all messages that are being send through ESB.
I use JBoss AS 6 with ESB 4.11. I am sending both esb-aware and JMS messages and everything works, but it seems that my interceptor intercepts every message mulptiple times.
At the moment, the Interceptor class just prints the concent + some other stuff to console. When I send a message, it displays the sent message multiple times (3 times to be more specific).
So my question is: Why?. Is this normal behavior? I have no clue where the mistake could be. I think that is could be one of these two options:
1) I have some error in my sending class, but I dont think thats the issue, since I use simply one serviceInvoker and my code is very similar to sample quickstarts. Standard output from gateway listeners also indicate that message is sent only ones...
2) Pipeline Interceptor intercepts the message multiple times, every time at a different stage of the pipeline. But how to test if this is the issue?
My properties file section for interceptors looks like this:
<properties name="interceptors">
<property name="org.jboss.soa.esb.pipeline.failure.interceptors" value="interceptor.Interceptor"/>
<property name="org.jboss.soa.esb.pipeline.instantiate.interceptors" value="interceptor.Interceptor"/>
<property name="org.jboss.soa.esb.pipeline.start.interceptors" value="interceptor.Interceptor"/>
<property name="org.jboss.soa.esb.pipeline.end.interceptors" value="interceptor.Interceptor"/>
</properties>
I tried to delete some of the properties but then it either doesnt intercept anything at all or it triggers multiple times!
Thanks for any tips!

JBossESB is not a very popular topic here :D
Eventually, I figured it out (I got helped on Jboss community forum). The problem is apparently a bug which is fixed in the next version of ESB. I hope this answer helps someone eventually...
Here is the link to the bug:
https://issues.jboss.org/browse/JBESB-3876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Related

Not able to receive message as a batch from the channel subscribed using aiosfstream, Python library for salesforce

I am trying to subscribe to a salesforce channel, I was able to get the messages from the channel.
But the issue is I am getting the messages one after another, the expected way of receiving is when bulk messages are published to the channel. Need to get the messages as a whole in the subscriber.
Let's say if I publish 500 messages, I need to get whole 500 messages here on the subscriber. But I am getting one message after another.
I am using the following code
async with client:
for topic in get_topics(system='salesforce'):
await client.subscribe(topic)
async for message in client:
messages = message
The above code is called inside async function
I am not sure this a bug from library or the method I follow is wrong
please let me know what is the issue.
I was able to figure out this Issue,
It is not related to library, it is super awesome. I was able to get the message real time.
The issue was with the architecture I have currently, which is causing the delay.
Thank you all for the help.
I see like it is not so good to answer this way, but answering it so that it might give someone heads up. While looking for such errors.
They can easily start debug the architecture instead of the library.

Coffescripts not receiving data from broadcasted message relay job

Here's the code:
How to ensure the javascripts/channels/chatrooms.coffee is loading and receive: (data) works? Console.log data is not loading
I posted the problem the other day. It comes from a tutorial, but somewhere after continuing work on my project, I'm not sure where the bug came up,
But the message relay job posts on the server, and my config.yml has redis with redis up and running.
There have been similar bugs, but I've worked through those solutions and it's not enough. The received: (data) console log doesn't arrive in the js console of the browser.
The App subscriptions seem to all be in order according to the tutorial, I bet it's a really simple fix.
My messaging system still works, so it's not crucial to the project, but it's a difference of having the chat system work in realtime versus with a 4 second page-refresh delay.
The last problem I had was not including jquery for my other coffeescripts, so I'm guessing the channels coffeescripts is probably a one line fix.

Threading profile for one endpoint in Mule results in endless hanging when used for two endpoints

I added a program to a Mule project in order to avoid duplication of code. They are both REST, access the same webservice and return json. The first service's threading profile looked like this:
<configuration doc:name="Configuration">
<default-receiver-threading-profile maxThreadsActive="10" poolExhaustedAction="WAIT" threadWaitTimeout="10000" maxBufferSize="100" maxThreadsIdle="2" >
</configuration>
When I added my second service, the same threading profile caused the program to hang endlessly. No log entries, no nothing. Raising max active threads to 1000, or even deleting the WAIT option doesn't do anything. It's only when I change "maxThreadsIdle" to 3 or higher, or delete maxBufferSize or delete the entire thing that both can work in the same project. One other thing...when I edit the mule flow and save, the program automatically launches again. Oddly enough, the results end up appearing in any browser I left hanging from trying to submit.
What I want to know is why the min threads needs to be set to 3 or higher...I mean what the heck is actually going on here? Ideally, I would like to keep the threading configuration set to what I have here.

Part of DROOLS ruleflow not working randomly

We have a main ruleflow which calls 8 more rule flows (Rule1.rf to Rule8.rf) through an AND splitter. One of the rule flows - say Rules4.rf - is fired sometimes and not fired sometimes.
This is for an online application and we use jBoss. When the server is started, everything works fine. After many hours, for some requests, Rules4.rf is not fired at all and for others, its fired properly.
We even posted the same request again and again and the issue happens some times only. There is no difference in the logs between the success & failure requests, except for the logs from the Rules4.rf which missing in failued requests.
We are using drools 5.1 and java 6.
Please help me. This is creating a very big issue.
It is very difficult to figure out what might be going on without being able to look at the actual code and log. Could you by any chance create a JIRA and attach the process and if possible (a part of) an audit log that shows the issue?
Kris

Silly WebSphere MQ questions

I have two very basic questions on WebSphere MQ - given that I had been kind of administrating it for past few months I tend to think that these are silly questions
Is there a way to "deactivate" a
queue ? (for example through a
runmqsc command or through the
explorer interface) - I think not. I
think what I can do is just delete
it.
What will happen if I create a
remote queue definition if the real
remote queue is not in place? Will
it cause any issues on the queue
manager? - I think not. I think all
I will have are error messages in
the logs.
Please let me know your thoughts.
Thanks!
1 Is there a way to "deactivate" a
queue?
Yes. You can change the queue attributes like so:
ALTER Q(QUEUE_NAME) PUT(DISABLED) GET(DISABLED)
Any connected applications will receive a return code on the next API call telling them that the queue is no longer available for PUT/GET. If these are well-behaved programs they will then report the error and either end or go into a retry loop.
2 What will happen if I create a
remote queue definition if the real
remote queue is not in place?
The QRemote definition will resolve to a transmit queue. If the message can successfully be placed there your application will receive a return code of zero. (Any unsuccessful PUT will be due to hitting MAXDEPTH or other local problem not connected to the fact that the remote definition does not exist.)
The problem will be visible when the channel tries to deliver the message. If the remote QMgr has a Dead Letter Queue, the message will go there. If not, it will be backed out onto the local XMitQ and the channel will stop.