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

[Design of EJB 3.0] - Re: EJBTHREE-615 still present in Embedded-ALPHA9

by jazir1979

Hi folks, I just posted about this to the user forum as well, but that was before I noticed this thread. EJBTHREE-615 is causing problems for me too. I'd be willing to debug into it further but had similar problems to Bill when trying to find the correct source. I couldn't even find the correct starting point for the embedded stuff... Any pointers, or ideas when this Jira issue would be assigned to a developer? cheers, Daniel. "hennejg" wrote : Bill, | | thanks. I tried 2006-9-14 (the timestamp of the release on sf and inside the archive) but the line numbers for jbosssx (the starting point for me) just don't match with the ones from the code's debug information. | In fact, I'm even confused about which repository is the correct one. The version I mentioned above is from CVS. SVN also has a JBossAuthorizationManager in /repos/jbossas/projects/security et al. However, those versions lack the updateCache method. | | Thanks! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002535#4002535 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002535

19 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: SerializableDeploymentRepository notions

by bill.burke＠jboss.com

So, you're going to have a generic service check every timestamp of, of every file in the deployment context? Still think it would be much simpler if the deployers control this as they know exactly what files to look for and what timestamps of what files to store in the attachment serialization. They would even be able to control whether or not serialization is allowed for that type of deployment. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002533#4002533 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002533

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec

by clebert.suconic＠jboss.com

Also.. that's why I called this a race condition. Case the failure is captured after the ConnectionFactory is updated for some reason... you would have a NullPointerException. This is not a problem on the hopping... it's a matter of not finding anything on failoverMap what would cause a NPE. That's why I introduced the guessing routine and I will trust on the Hopping case the guess didn't find the right server. (unlikely to happen.. the guessRoutine seemed to be pretty good to me) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002531#4002531 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002531

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec

by clebert.suconic＠jboss.com

Well.. I could replicate this in a testcase.. so it is a problem. You have Server1, Server2, and Server3 Then you have a map: 1->2 2->3 3->1 Now you kill server1: Map now is: 2->3 3>2 You don't have 1 on the MAP. When a connection on server1 fails.. it won't find an ID on failoverMAP. I could replicate this on a testcase. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002529#4002529 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002529

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec

by timfox

Also remember that the failover map on the client is never guaranteed to exactly mirror the server side map. This is why we built in "server hopping", where if the client got the wrong server it wouuld just redirect to the correct server. In the most degenerate case, even if you choos a random server it would still redirect to the corrects server, so even if slightly inefficient would end up on the correct failover server eventually. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002528#4002528 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002528

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec

by timfox

"clebert.suconic(a)jboss.com" wrote : I'm thinking about how to fix this race condition: | | | I - ClientClusteredConnectionFactoryDelegate has this following failoverMap: | | Server 1->Server2->Server3->Server 1 | | II - Server1 is killed | | III - Now the CF::failoverMap is updated to: | Server2->Server3->Server2 | | I can't see how this would happen. When a server dies, the new failover map is created on the server according to the algorithm. The algorithm would never create such a mapping. So this is a non problem AFAICT. Am I missing something? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002526#4002526 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002526

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec

by clebert.suconic＠jboss.com

The way I found to skip the race condition was to guess the failoverId based on the order on the failoverMap. So, in case we can't find the nodeID on failoverMap (meaning the CF was already updated) I will use a method that I'm calling guessFailoverId: | | class ClusteringAspect... | | | public static Integer guessFailoverID(Map failoverMap, Integer nodeID) | { | Integer failoverNodeID = null; | Integer[] nodes = (Integer[])failoverMap.keySet().toArray(new Integer[failoverMap.size()]); | // We need to sort the array first | Arrays.sort(nodes); | for (int i = 0; i < nodes.length; i++) | { | if (nodeID.intValue() < nodes.intValue()) | { | failoverNodeID = nodes; | break; | } | } | // if still null use the first node... | if (failoverNodeID==null) | { | failoverNodeID = nodes[0]; | } | return failoverNodeID; | } | | I want to keep this method as public static just because on the process of writing it I wrote a testcase for it... I haven't committed it yet: org.jboss.test.messaging.jms.clustering.ClusteringAspectInternalTest Any objections on a test for internal methods (not part of the API)? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002524#4002524 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002524

19 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Bean definition as value add problem (JBMICROCONT-28)

by alesj

This is done half way. No cloning at the moment. But you can define inner beans, with a full bean name. And they can be referenced from other beans. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002517#4002517 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002517

19 years, 2 months

1
0
0 / 0

[Design of JBoss Labs] - Navigation in Labs 2.0

by adamw

Hello, as I'm starting to change the project pages behavior, I guess it's good time to decide how navigation will look like :) As I suppose everybody already knows that each project will have the ability to compose its page out of a set of available portlets (via a GUI that Rysiek&Pawe? are writing). They will also be able to add additional pages with other portlets. So I think a first navigational portlet will be "Project Pages" which will simply list the pages defined for a project and enable to switch between them (of course, a project would have to add this portlet to their pages; it would be only usable when a project is selected). Also, projects much be chosen somehow. So on the main page we would have a "Project List" portlet (or "Software Map" portlet)? That would be a second navigational portlet. How this portlet would be accessed? As I have seen on the mockups, there is no "navigation" on the left side. A third navigational portlet would be needed for navigating between "global" Labs pages, like architects library/ wiki/ contributors/ jmm/ etc. But I think that we can do this by re-using the first one, that is, having a special "default" project, which would be hold the global content. Waiting for your opinions :) -- Adam View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002513#4002513 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002513

19 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: shutdown vs. undeploy with serialized attachments

by scott.stark＠jboss.org

Its not a kernel notion. Its a combined usage of the MainDeployer and ProfileService. shutdown is MainDeployer.removeDeploymentContext(DeploymentContext). Undeployming is Profile.removeDeployment(). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002480#4002480 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002480

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