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

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Changes on the JBM stack on JBoss5

by bstansberry＠jboss.com

The differences in the control channel config: UDP.singleton_name. In the AS this instance of the UDP transport protocol is shared across numerous channels. Giving the transport a name is what allows this to work. UDP.mcast_addr and mcast_port. These are just the values for the shared transport rather than the old JBM-specific ones. Don't see what difference this would make. UDP.loopback=true. We were seeing inscrutable startup failures for the AS when this was false on machines that had improperly configured multicast. With true you get startup failures (nodes can't cluster because multicast doesn't work) but they aren't inscrutable. I'd consider changing this back if we could somehow establish it's a cause of whatever your problem is. UDP.enable_bundling=false is just putting in the config file the default you had before. No change. UDP.ip_ttl=2. Longstanding AS default value to limit multicast propagation. In most testsuites, multicast doesn't even need to propagate off the test machine, so I doubt this is your problem. UDP.timer.num_threads=12. Your unspecified value defaults to 4. This is because the transport is meant to be shared between different services in the AS, so the number of threads available to run timer tasks is increased. UDP.thread_pool.min_threads="20". Old value = 1. With thread_pool.queue_enabled="true" and thread_pool.queue_max_size="1000", once that 1 min_thread was carrying a message up the stack or handling it at the application level, you would have to receive 1000 more messages and fill the queue before a 2nd thread would be created in the pool to handle to take a message off the queue. With a shared transport, it's possible those messages are for completely unrelated services and while the 1 thread is busy say in the session replication cache, 1000 JBM messages pile up in the queue. You need a larger # of min threads to ensure threads are available to read the queue. Testing with just one showed very poor performance in multi-node clusters. I can't see why having more threads available in a pool would cause a problem. UDP.thread_pool.rejection_policy="discard". Was "run". You can hang the entire cluster with "run", since it allows the single thread that reads messages off the wire to end up going into code that blocks in NAKACK or UNICAST or even into arbitrary application code. With multi-node clusters in tests under load, we found it was quite easy to hang the cluster with "run". UDP.oob_thread_pool.max_threads="20". See UDP.thread_pool.min_threads="20" above. UDP.oob_thread_pool.rejection_policy="run" Was "Run". This is just consistency in capitalization. FD.timeout and maxTries. With old values, would take 50 secs to detect a hung node. That's a long time. That was reasonable in AS 4, where the single-threaded channel and no OOB thread pool made it quite possible for FD heartbeats to go unacknowledged for a long time while the single thread was busy doing something else. With the thread pool and OOB messages, there's no reason FD heartbeats should go unacknowledged for so long, so we reduced the timeout period to 30 secs. GMS.shun="true". Previous value of false makes no logical sense in conjunction with FD.shun="true". This was discussed on a JBM forum thread a while back. TBH, I don't see why any of these would cause the error you reported, but until I see more details I don't really know what the error was. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187165#4187165 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187165

17 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Changes on the JBM stack on JBoss5

by clebert.suconic＠jboss.com

I'm using 2.6.5.GA, as I thought that was the version available at JBoss5. It is hard to replicate this error. I have to run the whole testsuite (about 2-3 hours) and it will happen eventually. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187155#4187155 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187155

17 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Changes on the JBM stack on JBoss5

by bstansberry＠jboss.com

Please send me the logs showing the full startup that results in the error. What JGroups version are you testing against? AS is using 2.6.6.CR1 (2.6.6.GA will be released tomorrow); 2.6.5.GA is fine too. I don't know of any reason why an fairly recent earlier version would give you trouble though. I'll post separately about the differences between your r4985 and r5284. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187153#4187153 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187153

17 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Changes on the JBM stack on JBoss5

by clebert.suconic＠jboss.com

Brian, I have just taken the configuration you changed on JBoss5 in our clustered-testsuite from here: http://anonsvn.jboss.org/repos/jbossas/trunk/cluster/src/resources/jgroup... into here: http://viewvc.jboss.org/cgi-bin/viewvc.cgi/messaging/branches/Branch_1_4/... and I started seeing these errors on our testsuite: | SomeException: | ... | Caused by: java.lang.IllegalStateException: Could not flush the cluster and proceed with state retrieaval | at org.jgroups.JChannel.getState(JChannel.java:1041) | at org.jgroups.JChannel.getState(JChannel.java:973) | at org.jgroups.JChannel.getState(JChannel.java:927) | at org.jboss.messaging.core.impl.postoffice.GroupMember.start(GroupMember.java:152) | ... | | Any idea why this would happen? Also, any particular reason why you needed to change the config on the jboss5 tree? If you did, maybe you could help us with a better config as this one is clearly not working. At this point I would like to release with the config we have tested so far. Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187146#4187146 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187146

17 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Passivating EJB 3 Stateful Session Beans stops the World

by ALRubinger

Hey, Andy. If you're still doing this testing, current trunk of AS has a new version of EJB3 with some Cache fixes in SimpleStatefulCache (ie. non-clustered SFSBs). Would be interested in hearing how this plays out. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187138#4187138 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187138

17 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBTHREE-1396 MockServer must report startup / shutdown

by ALRubinger

Figured you're waiting on pins and needles for my opinion. ;) * Methods like "hasMonitoringSupport" violate OO practices; this is what inheritance is for. You can ensure that a MockServer has this support by removing "addMonitoringSupport(int port)" in favor of another argument to a MonitorableMockServer constructor if indeed being "Monitorable" is a separate add-on capability (which might even come with its own interface). * Constants like SERVER_STARTING should be marked "final"? * MockServerMonitor has hardcoded "localhost" used by the ServerSocket. If we've gotta specify a port, might as well specify a host bind address (to bind to 2 unique hosts using same port for example) * In MockServerMonitor.waitForServerStartup(), there's a "while not started" loop. Let's throw a Thread.sleep(100) or something in there as to relax the CPU a bit * RemoteAccessTestCase now has "mockServerMonitor.waitForServerStartup();", which will block indefinitely - what if server does not start? Recommend making a "private volatile boolean remoteServerStarted" field, spawning off the check to "waitForServerStartup" into a j.u.c.FutureTask, and then call "getResult()" on it with a sensible timeout value. The FutureTask's job would be to set the "remoteServerStarted" to true, and then the RemoteAccessTestCase can poll for that. In the case of a timeout of the FutureTask, throw an exception and fail the test. * I put a static instance of MockServer *in* MockServer? It'd make me smile if you could remove that so we can actually start up more than one MockServer. This shouldn't be a Singleton, and even if it was, that's just bad implementation. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187137#4187137 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187137

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-6104; slow Seam deployments

by scott.stark＠jboss.org

We have to ship with something better than this as the default. Its just a question of what. Ales posted: "alesj" wrote : | This is something we need to discuss, as in which impl to use: | | | (1) Weak ref | | (2) Soft ref | | (3) LRU | | (4) Timed | | | | I would either go with | | - (1) + proper strong ref on this: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=145039 | | We keep the most used one's via strong ref on VFSInitializer, | | but let other temps be GCed asap. | | | | - (4) with limit long enough to do common apps deployment triggered upon this cache | | We make the timed limit long enough that most of apps make advantage of this vfs cache, | | once initialization period is over, flush it all. | | | [/qutoe] | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187131#4187131 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187131

17 years, 5 months

1
0
0 / 0

[Design of JBoss Identity] - Re: SAML Assertions (JBossESB)

by anil.saldhana＠jboss.com

"jkurtz.wa(a)gmail.com" wrote : | I am looking into some open source identity managers and service providers. This is what needs to be built using JBoss Identity (of course in a few days). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187130#4187130 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187130

17 years, 5 months

1
0
0 / 0

[Design of JBoss Identity] - Re: SAML Assertions (JBossESB)

by jkurtz.wa＠gmail.com

Anil The Integration point for a JBoss ESB Service could be an action class or Spring Listener class. This class could be the Policy Enforcement Point (PEP) for either authentication or authorization. The PEP would then call out to some mechanism, pluggable of course, to perform the analysis. >>For authentication the PEP would need the SAML Assertion or some other identity token >>For authorization using XACML the PEP needs the Subject (role), Resource and Action (optional Environment) The SAML Assertion (or other identification token) can be placed in the message header for both the ESB and web Service. Meta-data for authorization could be placed there too. I am looking into some open source identity managers and service providers. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187127#4187127 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187127

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-6104; slow Seam deployments

by stan.silvert＠jboss.com

There's a discussion about it now on the dev list. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187104#4187104 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187104

17 years, 5 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 November 2008