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

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-4228 Preferred master node for HASingleton

by bstansberry＠jboss.com

OK, that's fine. Re: testing, can you do a couple things: 1) Move the preferred master tests into a separate method from the simple ones. Just to make it easier to understand from looking at hudson what's being tested is if a test fails. 2) Make sure there's a test of preferred master where the specified master doesn't exist. Probably you should configure the ordinal to -1 or something so it picks the second node. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4128205#4128205 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4128205

18 years, 1 month

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-4228 Preferred master node for HASingleton

by galder.zamarreno＠jboss.com

I've got JBAS-5161 ready to be committed. There's a small change though that I wanted to pass through the forum before committing it: Instead of parsing host:port manually by searching for colon and then calling substring, I thought it'll be easier and less cumbersome to parse it via an URI. To do this, I create a new URI from "cluster://" + preferredMaster, i.e. /** | * Create a URI instance from the given preferred master. | * | * @param str contains the String format of the preferred master. | * @return an instance of URI, or null if the str cannot be parsed. | */ | protected URI createUri(String str) | { | try | { | return new URI("cluster://" + preferredMaster); | } | catch (URISyntaxException use) | { | log.debug("Cannot extract URI from " + preferredMaster, use); | } | | return null; | } and then call getHost() and getPort() on the URI instance to get the host/ip and port values. Even though a new URI is inmutable, I haven't cached it cos preferred master can be changed at runtime. URI is just an identifier in comparison to URL, so I don't expect creation of URI instances to be costly. To make sure I didn't introduce any bugs with this, I've also created PreferredMasterElectionPolicyUnitTestCase that contains several standalone tests that probe different inputs for preferred master. Brian, I'll send you a patch before committing in case you wanna have a look to it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4128202#4128202 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4128202

18 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: Major GPD Changes for Extenders

by pbolle

Hi Koen, Thank you for your answer. I tried to build GPD via eclipse but have the following problems. First a addend the missing plugin dependency org.eclipse.jface.text and add the jar dom4j.jar to classpath. The then 6 new errors occur in JpdlContentProvider: - The method addEdges(Node, Element) in the type JpdlContentProvider is not applicable for the arguments (Node, Transition[], Element) - The method addNodes(NodeContainer, Element) in the type JpdlContentProvider is not applicable for the arguments (NodeContainer, NodeElement[], Element) - The type JpdlContentProvider must implement the inherited abstract method AbstractContentProvider.addEdges(Node, Element) - The type JpdlContentProvider must implement the inherited abstract method AbstractContentProvider.addNodes(NodeContainer, Element) - The type JpdlContentProvider must implement the inherited abstract method AbstractContentProvider.getEdgeSemanticElement(Node, Element, int) - The type JpdlContentProvider must implement the inherited abstract method AbstractContentProvider.getNodeSemanticElement(NodeContainer, Element, int) For me it looks like if there are some commits are missing to get all work. Regards Philipp View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4128187#4128187 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4128187

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Another startup time regression

by bstansberry＠jboss.com

OK, that's what I wanted to check. There's 3 actual JChannel starts, where they need to pause 2 secs each to wait for answers t o their discovery packets. The rest of the channel starts (should be 7 total) are sharing those underlying JChannel's, so they should start quickly. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4128140#4128140 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4128140

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Another startup time regression

by scott.stark＠jboss.org

Default. All takes much longer with 4-5 jgroups channels starting up: | 18:21:37,773 INFO [ServerImpl] JBoss (Microcontainer) [5.0.0.CR1 (build: SVNTag=JBoss_5_0_0_CR1 date=200802090612)] Started in 44s:280ms | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4128135#4128135 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4128135

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Another startup time regression

by bstansberry＠jboss.com

Are you testing 'all' or 'default'? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4128126#4128126 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4128126

18 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: [Productivity] Level 2 - Development

by alessio.soldano＠jboss.com

http://jbws.dyndns.org/mediawiki/index.php?title=Asynchronous_invocations... http://jbws.dyndns.org/mediawiki/index.php?title=Security_and_attachments... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4128118#4128118 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4128118

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Another startup time regression

by scott.stark＠jboss.org

I just updated the aop version to 2.0.0.CR7 and definitely see an improvement: | 12:41:51,320 INFO [ServerImpl] JBoss (Microcontainer) [5.0.0.CR1 (build: SVNTag=JBoss_5_0_0_CR1 date=200802090612)] Started in 24s:810ms | still want it lower, at least under 10 secs on this box. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4128114#4128114 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4128114

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Classloader leak in BasicThreadPool

by bstansberry＠jboss.com

Never mind the bit about start()/stop(). An impl can achieve the same behavior by caching the TCCL in effect when its constructor is invoked. And no lifecycle methods means no reason for the impl to not be in common-core. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4128112#4128112 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4128112

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Classloader leak in BasicThreadPool

by bstansberry＠jboss.com

Discussion of solution to http://jira.jboss.org/jira/browse/JBCOMMON-41[/url] . For background on the problem see [url]http://www.jboss.com/index.html?module=bb&op=viewtopic&t=129122 . I intend to solve this by having the BasicThreadPool set an appropriate TCCL on the pool thread: 1) in the ThreadPoolFactory, just after creating the thread. 2) when a thread is returned from a task, by subclassing ThreadPoolExecutor and overriding afterExecute(). What TCCL gets set will be configurable by an injectable policy: | package org.jboss.util.loading; | | public interface ClassLoaderSource { | | /** | * Returns the classloader provided by this object; may return null. | */ | ClassLoader getClassLoader(); | | } | If no ClassLoaderSource is injected, the TCCL will be set to null. In common-core I'll add a basic SimpleClassLoaderSource which simply returns getClass().getClassLoader(). In the AS, that would return the classloader that loads $JBOSS_HOME/lib. Somewhere else, (AS server module?) I'll add another impl that exposes a start() and stop() method. In start it will cache a weak ref to the current TCCL, and will thereafter return that. This could be injected into the jboss.system:service=ThreadPool pool; it will return the classloader in effect when conf/jboss-service.xml is deployed. That seems like a reasonable default for that service, or at least is likely closest to the "typical" behavior of the current thread pool. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4128107#4128107 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4128107

18 years, 2 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 February 2008