September 2007 - jboss-dev-forums

[Design of JBoss Portal] - Re: Maven Migration Status

by bdaw

Does it mean we'll be able to run portal build and testsuite from IDE? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4084600#4084600 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4084600

18 years, 6 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-4719 (JBCLUSTER-186) Invoker implementations need e

by ScottMarlowNovell

Cool, then I don't need to worry about the other Invokers! Thanks for the feedback! Scott View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4084590#4084590 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4084590

18 years, 6 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-4719 (JBCLUSTER-186) Invoker implementations need e

by bstansberry＠jboss.com

OK, I see the problem. I didn't think you'd be totally off-base in a bug report; so I was scratching my head a bit. :) Looks like this is limited to the PooledInvoker then; for the other InvokerHA impls, getStub() returns the types as I described. The value returned from that method is what populates the target list. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4084587#4084587 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4084587

18 years, 6 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-4719 (JBCLUSTER-186) Invoker implementations need e

by ScottMarlowNovell

I am seeing the issue with 4.0.4, but not for the reason that you mentioned. ServerAddress in 4.0.4 has an equals method but its not called by the PooledInvokerProxy. The PooledInvokerProxy is actually stored in the targets list (this is true for load balancing. This would be true for anyone that switches from using RMI to org.jboss.invocation.pooled.server.PooledInvokerHA. PooledInvokerProxy contains a ServerAddress, which should be used for the equality check. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4084582#4084582 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4084582

18 years, 6 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Handling cluster state when network partitions occur

by bela＠jboss.com

"manik.surtani(a)jboss.com" wrote : I inherently don't like using a static cluster size configuration. With larger clusters, nodes joining and leaving the cluster should be seen as "normal" and it should be able to scale up or down without reconfiguration. | This is not a static configuration, e.g. {A,B,C,D,E}. The only thing that's static is the primary partition size. anonymous wrote : | Correct me if I am wrong, but if you have {A, B, C} on switch S1 and {D, E} on switch S2, and if S2 fails, does JGroups deliver 2 view changes to {A, B, C} (one without D and one without both D and E) or just a single view change, without D and E? Assuming FD_SOCK is used for immediate switch failure detection? | Depends. usually you get 2 view changes, sometimes 1. Remember that if a switch goes down, the TCP connection in FD_SOCK will *not* be closed, so we'd have to rely on FD here. anonymous wrote : | If this is the case, can't a split brain threshold be used? I.e., if a view change is received in which more than N% of members are removed, assume a split brain as opposed to normal drop-offs? No, because you can't rely on JGroups excluding all 'dead' members in *1* view. This depends on the failure detection and group membership protocol impl, and they might all be different. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4084571#4084571 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4084571

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Unifying metadata

by scott.stark＠jboss.org

The first step I want to do to get a unified metadata view is to simply pull all of the metadata classes into /projects/metadata/trunk/src/main/java/org/jboss/metadata. I want to pull out any jbossxb/xml parser factories into a metadata-parser project as well so there is a clean separation of metadata, metadata parsing and metadata consumers. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4084570#4084570 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4084570

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Handling component references

by scott.stark＠jboss.org

The first issue for a component registry is how to build the keys that describe a component. The most obvious starting point is that you have a structured name and indices based on the different types of references. For ejb-link style references, you have a name based on the deployment structure and ejb-name. For @EJB with a class, you have a name based on the deployment structure and business interface class. A source based on an ejb-name: {vfs-url-base}/{root-deployment-name}/{ejb-deployment-name}/ejb-name - points to the component metadata for the ejb-name component. A source based on a business interface: {vfs-url-base}/{root-deployment-name}/{ejb-deployment-name}/business-interface-class - points to the component metadata for the component providing the business-interface-class implementation. Resolution of a reference then consists of trying various structured keys based on the referencing component structure and type of reference. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4084568#4084568 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4084568

18 years, 6 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Handling cluster state when network partitions occur

by manik.surtani＠jboss.com

Basically pretty much the same as a static configuration except that the cluster size used is the last known number of members. Better still, how about maintain an average number of members over time and use this as a cluster size? Unlikely that a cluster would grow by _doubling_ the number of servers or anything like that ... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4084563#4084563 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4084563

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: ManagedOperation aspects for the ProfileService.Manageme

by scott.stark＠jboss.org

The org.jboss.test.profileservice.test.ProfileServiceUnitTestCase.testDefaultDSOps unit test exercises the ManagedOperation calls for a DataSource component. This is wired up to the point of the invocation showing up in the org.jboss.profileservice.management.ManagementViewImpl.invoke(Invocation inv)method, where the server side ManagedOperation instance is located. What is missing is how to take that ManagedOperation invocation and turn it into an invocation on the runtime component that source the operation, and return the result. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4084560#4084560 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4084560

18 years, 6 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Handling cluster state when network partitions occur

by manik.surtani＠jboss.com

I inherently don't like using a static cluster size configuration. With larger clusters, nodes joining and leaving the cluster should be seen as "normal" and it should be able to scale up or down without reconfiguration. Correct me if I am wrong, but if you have {A, B, C} on switch S1 and {D, E} on switch S2, and if S2 fails, does JGroups deliver 2 view changes to {A, B, C} (one without D and one without both D and E) or just a single view change, without D and E? Assuming FD_SOCK is used for immediate switch failure detection? If this is the case, can't a split brain threshold be used? I.e., if a view change is received in which more than N% of members are removed, assume a split brain as opposed to normal drop-offs? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4084557#4084557 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4084557

18 years, 6 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 September 2007