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

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Fail-over design questions

by timfox

If you want to do this, just shutdown the server. The client connections will then break, and they'll failover to another node, no extra code is necessary. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003772#4003772 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003772

19 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - added profiles to the build

by tom.baeyens＠jboss.com

in order to add profiles capabilities to the build, i have added <property file="${jbpm.root}/build/profiles/${profile}.profile.properties" /> to all the build files that import the base.project.build.xml that way, you can specify profile=jboss5 in your ${user.home}/jbpm/build.properties and then these profile properties will get loaded before the build/build.properties that way you can create profiles with different sets of libraries to test with. i don't have any specific profiles defined yet. there is just an example that contains the same library versions as the main properties file. note that i also have removed the <property file="build.properties" /> since it was not used View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003770#4003770 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003770

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Fail-over design questions

by hendra_netm

"timfox" wrote : When you failover, non persistent messages would be lost. Therefore we can't just fail over to redistribute load, since people would get upset if suddenly their non persistent messages disappeared. Sorry, I still don't get your answer. The intention of failover over shutdown is not to redistristibute load. It is done to keep the service available. So users still can send messages without knowing that there is a maintenance take place. Shut down is done by administrators/operators. They know what will happen to non persistent messages when they shut down the server. I think it is unlikely that they will be surprised on their own action. Anyway, with or without failover, shut down a server will make non persistent messages dissapeared. Why is this failover going to make them upset? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003768#4003768 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003768

19 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: new simplified menu structure

by tom.baeyens＠jboss.com

"falazar" wrote : anonymous wrote : | | The "End Task" is not terminology that is defined by the web console. The caption of each of the transition buttons is determined by the name of the corresponding transition. In this case, the "websale" example process happens to have transitions named "End Task". | | The "End" "Cancel" and "Save" are rather confusing, we changed those to be specfic action names so users would know what they were doing, like "Submit Request" and such. | +1. So we should give some thought on how the user can specify button names and link them to transition names. By default, the transition names are chosen, but the user should be able to override these. If no transition name is specified and no button name is given, we can't do anything else except come up with a silly generic name. "falazar" wrote : And the "Cancel" does not actually cancel the task or the process, so it is very ambigously named, we changed it to "Go back to inbox" and added a Cancel Request transition button. good point. that button got me fooled too. since there is a task.cancel method, i thougt it was cancelling the task. "Back to Inbox" is indeed better View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003766#4003766 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003766

19 years, 2 months

1
0
0 / 0

[Design of JBossCache] - Re: Last minute 2.0 API suggestions

by manik.surtani＠jboss.com

"manik.surtani(a)jboss.com" wrote : "genman" wrote : | | 1. Have Node.removeChild() return true if the node was removed | | | | Need to think about how big an impact this will have on the interceptor chain since this calls remove(Fqn). | This is actually not a good idea - the whole concept of Nodes are Nodes that are attached to a tree. If a node has been removed, a reference to it will not be of much use at all. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003746#4003746 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003746

19 years, 2 months

1
0
0 / 0

[Design of JBossCache] - Re: Last minute 2.0 API suggestions

by manik.surtani＠jboss.com

"genman" wrote : | 1. Have Node.removeChild() return true if the node was removed | Need to think about how big an impact this will have on the interceptor chain since this calls remove(Fqn). "genman" wrote : | 2. Add a Node.size() or Node.dataSize() to count basically getData().size(). The problem (in terms of efficiency) is that getData() makes a copy. | 3. Node.putIfAbsent() should be consistent with ConcurrentMap, and return Object. Consider adding other methods of ConcurrentMap. | 4. Change Node.put to Node.putAll to be consistent with Map.putAll(). | Makes sense. I've added the APIs and basic impl's, which we can revise/refactor over time. "genman" wrote : | I'm working on a Node -> Map adaptor, sort of a poor man's PojoCache, and find these basic methods missing. An interesting idea; I'd like to see a separate thread on this though so we can discuss View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003733#4003733 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003733

19 years, 2 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Distributed Lock Mechanism

by bela＠jboss.com

The issue of releasing locks from crashed members has already been solved and is part of the current DLM, I just mentioned it as one of the issues for a potential re-implementation. Yes, leasing of locks could help preventing distributed deadlocks, this could be part of a new implementation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003709#4003709 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003709

19 years, 2 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Distributed Lock Mechanism

by manik.surtani＠jboss.com

Perhaps something similar to the DLM in JGroups could be implemented as a part of a common clustering library, as I think it takes away from JGroups' core focus to have it reside in JGroups. (IMO) Re: the problem of the lock owner crashing, surely JGroups FD can kick in, and when a new view is issued, locks held by missing members can be automatically released? Further, timeouts can be applied to ensure locks cannot be held forever, although this may undermine the purpose of the lock in the first place. Replicated deadlock, anyone? :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003697#4003697 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003697

19 years, 2 months

1
0
0 / 0

[Design of EJB 3.0] - ManyToMany enhancement?

by joe.marques＠jboss.com

Given this object model: | Object_A LinkT Object_B | Aid --- Aid | Bid --- Bid | Stuff | I would like to use the following ManyToMany style on classes A & B: | @Entity | @Table(name = "Object_A") | class A { | @ManyToMany | @JoinTable(name="LinkT", | joinColumns={@JoinColumn(name="Aid")}, | inverseJoinColumns={@JoinColumn(name="BiD")}) | List<B> Bs = new ArrayList<B>(); | } | | @Entity | @Table(name = "Object_B") | class B { | @ManyToMany(mappedBy="Bs") | List<A> As = new ArrayList<A>(); | } | But I also want to be able to access the linking table directly, because it has extra metadata called "stuff" that I insert directly into it with a different Entity mapped directly on top of it: | @Entity | @Table(name = "LinkT") | class Link { | // Aid, Bid, and Stuff | } | Thus, I can do one of two things right now: 1) Use the @ManyToMany annotations to construct the relationships. This allows me to navigate via getAs() and getBs() to the other side of the relationship and back again. However, doing it this way prevents me from inserting the additional "stuff" qualifier, which can only be calculated at insertion-time. 2) I can use a slightly more obtuse procedure to insert data into the linking table via the Link entity. Here, I've ensured that the data in all three tables is correct, and that the relational part is identical to what is persisted in the above scenario. This method affords me the additional opportunity to insert this qualifying "stuff" into the linking table. Unfortunately, when I go to access the relationships - getAs() and getBs() - they always return empty sets. Now, I went into all of this presuming that this was most likely a limitation of the current JBoss ejb3 implementation (inserting data through a direct map on top of the linking table, and selecting from the @ManyToMany context), but it would sure be nice if this was a JBoss extension. After the data is inserted into the linking table with the additional "stuff" attached to it, then you could choose the complexity of your JPQL according to the needs in your calling context: A simple condition: | SELECT someA FROM A someA, IN (someA.Bs) someB | WHERE someB.property=<value> | A complex condition, requiring the use of "stuff": | SELECT someA FROM A someA, LinkT link | WHERE someA.Aid = link.Aid | AND link.stuff=<value> | Thoughts on this? -joseph View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003685#4003685 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003685

19 years, 2 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Distributed Lock Mechanism

by bela＠jboss.com

There is a DLM that's part of JGroups but it is somewhat unsupported (I didn't write it and the guy who did is too busy to support it): http://www.koders.com/java/fidC73888EED1C2ECCDD56AF33274914F9AB36641F7.as... The existing DLM is also a bit costly, as it does a 2-phase lock acquisition phase. Also, IIRC it requires total consensus, not majority-based consensus as you described above. You also have to solve the issue where a member which is currently holding the lock crashes. In this case, you have to release all the locks held by a crashed member. If you submit a concise spec then something like what you described could be implemented in a few days... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003677#4003677 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003677

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