January 2007 - jboss-dev-forums - Jboss List Archives

[Design of JBossCache] - Re: PojoCache uses a special node factory

by ben.wang＠jboss.com

This is interesting proposal, Brian. :-) But I am still pondering will it really help. I have been grapling with this problem for a while now since I encountered this in the "stress" test env. Basically, in release 2.0, since we move to the flat-space approach as all the real POJO attachment happens at "__JBossInternal__" node. E.g., we will store the real POJO under, say, "__JBossInterna__/e4xx99ssjswi" node. This imposes the fqn "__JBossInternal__" as the bottleneck as whenever I need to map another POJO, I will need to obtain a WL on "__JBossInternal__" first. And note that WL is needed for both attach and detach (a la, remove) as well. So question is what options that we have to improve the concurrency while maintaining the correctness? I am finding not a lot, other than using the Region concept to improve it somewhat. Can a specialized Node for "__JBossInternal__" help? During the creation and removal of child node, actually I can forgo the interceptor chain and just rely on the Node ConcurrentHashMap to provide synchonization. But I will run into problem when I need to rollback either attach or detach operations (unless I still go thru the interceptor stack). Any thought? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999350#3999350 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999350

19 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Failover analysis

by ovidiu.feodorov＠jboss.com

What's the use case for an re-entrant lock? If the valve is distributed among delegates, you probably don't need that, hence reduced complexity ... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999284#3999284 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999284

19 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Failover analysis

by ovidiu.feodorov＠jboss.com

Even if we keep a single valve instance per connection, I see no reason to involve remotingConnection at such low level, as you do in | JMSRemotingConnection remotingConnection = null; | | try | { | valve.enter(); | | // it's important to only retrieve the remotingConnection while inside the Valve, as we | // guarantee that no failover has happened yet | remotingConnection = connectionState.getRemotingConnection(); | return invocation.invokeNext(); | } | catch (CannotConnectException e) | { | log.warn("We got a CannotConnectionException and we are trying a failover", e); | ((ConnectionDelegate)connectionState.getDelegate()).performFailover(remotingConnection); | return invocation.invokeNext(); | | } | catch (IOException e) | { | log.warn("We got an IOException and we are trying a failover", e); | ((ConnectionDelegate)connectionState.getDelegate()).performFailover(remotingConnection); | return invocation.invokeNext(); | } Why don't we just message the connection: "there's failure, deal with it!". The connection has access to the proper remoting connection instance, why does it need to receive as an argument of the call? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999282#3999282 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999282

19 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Failover analysis

by ovidiu.feodorov＠jboss.com

Keeping a single centralized valve per connection gives a single point of bottleneck. All threads invoking into any delegate will have to acquire/release the synchronization element of that valve. This will lead to a lot of contention. Distributing the load across different valve instances will relieve some of this pressure, with no apparent drawback. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999281#3999281 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999281

19 years, 3 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Servlet transport is completely broken.

by Cyberax

Servlet transport (in Remoting 2.0) is broken in sooooo many ways.... 1) There can't be two servlet invokers (it's necessary, for example, if you want to use them for JBoss Messagning and for EJBs - they require separate connectors) because ObjectName is hard-coded in ServletServerInvoker.java 2) Null returns from invokers are sent to client as empty 204 responses and custom marshallers have no change to process return value. This breaks JBoss Messaging which expects that EVERY message contains at least two bytes (version tag and format tag). 3) No support for PINGS. 4) etc. I've fixed all of them :) Now I can use JBoss Messaging using servlet connector. Should I send patch version? BTW, probably some of these bugs are present in other invokers (HTTP invoker, in particular). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999277#3999277 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999277

19 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Failover analysis

by ovidiu.feodorov＠jboss.com

Clebert wrote : | Ovidiu on Wiki Page wrote : If there are active threads traversing the valve at the moment when "close" command arrives, those threads must be interrupted and put to wait until the valve opens again | | | There is no way to interrupt those threads, but on the event of a failure, all of the inflight invocations are going to fail at the same time, and all of them will capture the failure trying to close the valve at the same time. | Not in a portable way, I agree. But then I said that a possibility would be to close the valve regardless of any active thread, since the active threads will have no choice but fail anyway shortly. For that, we need to make sure that: 1. We can close a valve with active threads traversing it 2. Once a valve is closed, it still handles correctly a downstream failure. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999276#3999276 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999276

19 years, 3 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Leasing is br0ken in servlet transport.

by Cyberax

Servlet transport doesn't process lease request messages, so it doesn't work. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999274#3999274 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999274

19 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-674 - Propagation of server List to client

by clebert.suconic＠jboss.com

Instead of updating failoverMap on every communication we will be doing activelly when server's view (failoverMap and connectionDelegate) has changed. We will have a static list somewhere on the client, and update that list when new nodes are joining the cluster. I will have to think of something, as right now I don't have many details about how this will be implemented. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999268#3999268 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999268

19 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Tests for JBoss MQ message counter functionality

by genman

There aren't any tests I know of. The counter functionality is really bad (the JMX methods return HTML blocks which would have to be parsed) and Adrian continues to threaten to remove it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999267#3999267 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999267

19 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Expiring/DLQ same message from multiple subscriptions

by genman

"timfox" wrote : If I send a message to a topic, and it ends up being delivered to n subscriptions on that topic, then the message expires, should the message be added to the expiry queue n times, one for each subscription, or only once? | JBossMQ creates an expired message for every subscription. anonymous wrote : | A more complex but related situation is for messages that have exceeded max delivery attempts. | | If a message is sent to a topic with n subscriptions. Then depending on how many times the client calls recover() or rollback() for one or more of the subscriptions, then the message could have exceeded max delivery attempts for some of the subscriptions but not with others. | | So the message needs to be added to the DLQ for some of the subscriptions, but not for others - how does this effect the subscriptions who have not exceeded max delivery attempts? | | Can we end up with a situation where the same message (same message id) is in the queue (dlq or expiry queue) multiple times? Would we get primary key violations in the database? | How I did it was to basically create a new message, which is mostly a copy of the original message, with additional headers indicating the original message ID, queue or topic name, and time of expiry. Then, JBossMQ would remove the old message and store the new message as a single DB operation. You don't really need to worry about ID conflicts therefore. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999266#3999266 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999266

19 years, 3 months

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 January 2007