March 2009 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Remoting, Unified Invokers] - Re: Server side thread leak?

by bstansberry＠jboss.com

="galder.zamarreno(a)jboss.com" wrote : In the case of clustered invokers, I think disconnecting the current client before creating/connecting a new one would make sense as otherwise you're leaking clients (this probably needs a jira, FAO Brian thoughts?) There are really 2 cases here: a) switching to a new Client due to failover. In that case the InvokerLocator is removed from the set of targets and disconnecting seems like an obvious right thing to do. b) switching to a new Client due to normal load balancing (e.g. RoundRobin) with an expectation that we may end up creating another Client later for the same InvokerLocator. That, if I understand the code correctly, will end up using the already-existing ClientInvoker The b) case is more tricky. If in the non-clustered case we end up deciding to call disconnect after every invocation, then the clustered case should as well. If non-clustered doesn't disconnect on every invocation, we can revisit. Sounds like disconnecting is necessary though, with the "invokerDestructionDelay" as the workaround to cut down on the waste associated with that. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222123#4222123 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222123

15 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Deprecated JbpmContext.getCurrentJbpmContext

by bradsdavis

I noticed that JbpmContext.getCurrentJbpmContext is deprecated. However, it is used throughout the jBPM codebase. Does this need to be cleaned up? There is more functionality around the JbpmContext.getCurrentJbpmContext than within the JbpmConfiguration.getCurrentJbpmContext. Because of this, it is not equivalent to use one versus the other. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222121#4222121 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222121

15 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Commented out JMS tests

by timfox

I was doing a bit of spring cleaning in the old JMS tests, and I discovered quite a few commented out tests, in: MessageConsumerTest MessageProducerTest TopicTest PersistenceTest I de-commented them, and most seem to work ok, with one exception in MessageConsumerTest. Naughty developers please note, don't comment out tests unless you want to be severely disciplined ;) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222119#4222119 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222119

15 years, 9 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Server side thread leak?

by rachmato＠redhat.com

Notwithstanding Galder's comments, it seems as though the bulk of what is being seen may be a non-problem and just a matter of having large pool sizes for threads with thread reaping turned off or with long delay. I'll try a run using smaller pool sizes and keep alive times for both JCA and Remoting and see what happens. Thanks for your help... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222090#4222090 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222090

15 years, 9 months

1
0
0 / 0

[Design of Management Features on JBoss] - Re: JBAS-6689 add support for activation policy metadata on

by charles.crouch＠jboss.com

"emuckenhuber" wrote : So when you restart AS the application will have the changed JNDIName and clustered config. Well this maybe technically true, but for all practical purposes when you restart the AS you will just have a non-functional destination whose configuration has been updated. When the AS starts I would expect you to see something like the following... java.lang.IllegalArgumentException: Queue quickstart_helloworld_Request_esb is already deployed as clustered = true so cannot redeploy as clustered=false . You must delete the destination first before redeploying as described in https://jira.jboss.org/jira/browse/JBMESSAGING-1368 So given there is no way, without resorting to executing SQL, to actually update this 'clustered' property in a way that is going to leave a functional destination I think it should be readonly from a management perspective. Or we should work with the messaging team to provide a management interface which supports updates. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222083#4222083 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222083

15 years, 9 months

1
0
0 / 0

[Design of Management Features on JBoss] - Re: JBAS-6672, null values and defaults

by charles.crouch＠jboss.com

"emuckenhuber" wrote : Although i still think doing managedProperty.setValue(null); should not replace it with a default value. | Ok, so what should we use? In use case 1) we need to specify "I want to use the default" and in use case 3) we need to specify "I want to use null/nothing/blank". So maybe for use case 1) we have managedProperty.setDefaultValue() and for 3) we have managedProperty.setValue(null) or alternatively (but this seems even more of a hack) 1) managedProperty.setValue(null); 3) managedProperty.setValue(""); Because the template will specify an actual value for the default, e.g. 20, its of no use to us when the user wants to persist the "default value" since the "default value" may change over time. This is exactly analogous to the case of defining the resources configuration via xml. If you had a template with every xml element specified in there and persisted that, it would be a different value than if you just included the xml elements you wanted to specify, letting the server set the other ones as it saw fit. Cheers View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222081#4222081 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222081

15 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2.0 examples

by timfox

The examples list needs to be updated since we decided we're going to pretty much concentrate on the JMS examples for now. (I.e. demonstrate functionality by sending/consuming of JMS messages), since that's what most people will use. Then we'll have a parallel hierarchy for core tests. So the distinction core/jms examples is not that relevant. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222073#4222073 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222073

15 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2.0 examples

by clebert.suconic＠jboss.com

Jeff added a wiki with the list: http://www.jboss.org/community/docs/DOC-13460 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222069#4222069 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222069

15 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2.0 examples

by ataylor

You'll need to run ant jar before running the examples. It some point i'll add some checks to make sure the jars are available View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222059#4222059 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222059

15 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Debug Logging

by bradsdavis

David, I am not trying to argue about it. I think this is a genuine place we could improve efficiency. anonymous wrote : | Not Apache clogging, JBoss common logging. http://anonsvn.jboss.org/repos/common/common-logging-spi/trunk/src/main/j... | Correct me if I am wrong, but I think that most of the logging performed in jBPM is with Common's logging. Also, we want this to be portable to all containers, which means we should be programming for commons logging, and should also use the suggestions of Apache for how to use their logger. I am sure there should be plenty of places where trace should be used rather than debug. However, I am trying to contribute something that is an easy and a proper fix for the issue at hand. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222058#4222058 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222058

15 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums March 2009