May 2008 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Mixing Blocking and OneWay calls is very slow...

by jmesnil

"jmesnil" wrote : "timfox" wrote : One thing I noticed is that if I change it so TCPNoDelay is picked up from the messaging config (currently it's hardcoded on the connector), and tried to run perfSender and perfListener with non persistent messages, not transacted, then the listener seems to not receive any messages. | | I think the issue is related to session suspend/resume in MinaHandler. | | We can suspendRead the session when we receive a message. | The resumeRead can occur when we sent a message. | | But we have cases where the server receives a lot of one-way messages (potentially suspending the session) and do not send a message (thus never resuming the session). | E.g. the client acknowledge a lot of messages and close the session. | At one point, when receiving an ack, the server's MINA Handler will suspendRead the session. Since the server does not send any messages, the session will not be resumeRead and the CLOSE message will not be handled. | | We can't assume that we have as much messages received as message sent (and vice versa). It seems we need to rethink our algorithm to take into account these cases. | | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152019#4152019 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152019

18 years

1
0
0 / 0

[Design of JBoss ESB] - Re: JCRMessageStoreImpl store only message body?

by mark.little＠jboss.com

We should definitely be storing the entire message. I'd suggest adding some option (maybe on the message) that indicates the duration for which it can be stored and, when it gets deleted by the store, we should have a "grave stone" (marker) for it so that we don't break referential integrity. If you delve back far enough in the design forums you'll find some of the original design ideas behind the message store, not all of which made it into the implementation. One of them was to store the entire message and have a generic search method that allowed you to send arbitrary rules in to the "engine" and get back a stream of results, c.f. dynamic SQL procedures. That way the store API isn't tied to a static and limited set of search criteria. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152008#4152008 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152008

18 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Mixing Blocking and OneWay calls is very slow...

by jmesnil

"timfox" wrote : One thing I noticed is that if I change it so TCPNoDelay is picked up from the messaging config (currently it's hardcoded on the connector), and tried to run perfSender and perfListener with non persistent messages, not transacted, then the listener seems to not receive any messages. I've observed the same problem on failing tests in our test suite. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151998#4151998 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151998

18 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Mixing Blocking and OneWay calls is very slow...

by timfox

One thing I noticed is that if I change it so TCPNoDelay is picked up from the messaging config (currently it's hardcoded on the connector), and tried to run perfSender and perfListener with non persistent messages, not transacted, then the listener seems to not receive any messages. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151988#4151988 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151988

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Composite Map key and weak reference

by alesj

How to solve this issue: I have a Class ref and array of Annotation refs, which together compose my Map key. Since I have no callback hooks for removing this key I need something similar as what WeakHashMap would do if my key was only that Class ref - removing the whole entry when Class ref is GCed. Is there an easier way than rewriting the whole WeakHM (or some similar construct)? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151986#4151986 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151986

18 years

1
0
0 / 0

[Design of JBoss ESB] - Re: JCRMessageStoreImpl store only message body?

by maeste

"Kevin.Conner(a)jboss.com" wrote : Yes, storing the complete message makes sense. | | Burr is correct, this code was contributed by an external contributor and would have been done to fit their requirements. We should revisit this code. Ok, I can create an issue on Jira and take it, if you agree. My opinion is the best solution would be to store in ESB action whole message, without any manipulation (no extraction of properties, header and so on) and leave to DNA sequencer this kind of job. This approach would permit us to apply different sequencer to ESB message repository to extract metadata at different levels, depending on actually needing. Am I wrong? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151985#4151985 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151985

18 years

1
0
0 / 0

[Design of JBoss ESB] - Re: JCRMessageStoreImpl store only message body?

by maeste

"burrsutter" wrote : Are you looking to place all "in-flight" messages of the ESB into the DNA repo? | Good question...we are discussing about. It would be a lot of data. Isn't it? And what would make sense to you? I'm thinking to store it for a limited period of time, configurable of course. Well, this and other question (like which kind of metadata we should sequence) would be discussed in a dedicated 3ad on DNA or overlord forums. Or would you think is it fine here? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151983#4151983 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151983

18 years

1
0
0 / 0

[Design of POJO Server] - Re: JBMICROCONT-288 - Invalid feature request and invalid pr

by wolfc

The use case is using a MC bean from a registry which is by nature not MC aware. For example JNDI and Remoting (ServerInvocationHandler). Other use cases are passivation of objects which might contain references to MC beans. For example I might have a reference to a MC bean in a web session. (I think this translates to being able to have a serialized reference to a MC bean itself. But to facilitate that the MC bean would need a serialized reference to the Kernel.) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151975#4151975 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151975

18 years

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Optimizing Pointcut Matching

by kabir.khan＠jboss.com

If you have time, then I think this will be a good thing to have. http://jira.jboss.com/jira/browse/JBAOP-579 I have expanded the PointcutStats class, which already did some classification, to classify things more finely. I added the methodExecution/Call and construtorExecution/Call fields. You can see this used in PointcutTestCase.testPointcutClassification(). It should now be a matter of plugging it into the advisors so we only match what we need to match. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151972#4151972 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151972

18 years

1
0
0 / 0

[Design of JBoss ESB] - Re: Newbie problem

by Kevin.Conner＠jboss.com

You appear to have mixed a jBPM action class with an ESB action class. Look at the bpm_orchestration quickstarts for an example of how to do this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151964#4151964 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151964

18 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums May 2008