[Design of Messaging on JBoss (Messaging/JBoss)] - split-brain between live and backup node
by jmesnil
this is related to https://jira.jboss.org/jira/browse/JBMESSAGING-1194
Starting with the simplest case, it appears that we can very easily have a split-brain between a live node and its backup node.
1. normal use case
C1 & C2 are connected to live node L1
L1 is replicated on the backup node B1
| C1 - - - B1
| \ |
| \ |
| \ |
| \ |
| L1*
|
| *: live node
|
2. Backup activation is triggered by the 1st client connection to the backup node
Network cable is unplugged from L1
1. C1 will failover to B1
2. B1 will be activated and becomes live
3. L1 is still alive
4. L1 will be informed that the connection to B1 is dead
-> it will stop replicate to B1 but it remains alive
=> 2 live nodes: split-brain!
| C1 - - - B1*
| X X
| X X
| X X
| X X
| L1*
|
3. in case the network connection failure was transient (someone replugs the cable in C1)
1. another client C2 joins and connects to L1 as its live node
2. C1 will continue to use BA as its live node
| C1 - - - B1*
| /
| /
| /
| /
| C2 - - - L1*
|
To sum up, we can reach a split-brain after a transient network failure on the live node.
In the code, I've not seen any heartbeat between the live node and the backup node. L1 will never be informed when it can reach B1 again.
B1 as the original backup never checks connectivity to the original live node L1
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4207359#4207359
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4207359
15 years, 4 months
[Design the new POJO MicroContainer] - Re: Too strict pattern matching in PackageClassFilter
by jaikiran
Posting here in continuation to this thread in the user forum http://www.jboss.com/index.html?module=bb&op=viewtopic&t=149468#4207208. Other than this there are some more users (of JBossAS5.0 GA) who have reported that the package filtering isn't working as expected.
A bit of background:
* The WAR deployer allows (and used to allow in JBossAS4.x) a "filteredPackages".
<property name="filteredPackages">javax.servlet,org.apache.commons.logging</property>
|
This configuration would ensure that if the user had packaged a jar containing any classes belonging to javax.servlet.* package (and child packages), then those classes would be filtered/ignored.
* In 5.0 GA, users have reported that this doesn't work anymore. The forum thread has more details. As explained in that thread, the PackageClassFilter is not filtering child packages. For ex: If the user had filteredPackages = javax.servlet then the PackageClassFilter filters only classes belonging to javax.servlet but not the ones in javax.servlet.http. In my opinion, the PackageClassFilter regex needs to be changed to allow this (there's a patch in the other forum thread). This would allow users to add a filter on the top most package and not worry about any child packages.
* The comments on the original version of that class made me believe that the current behaviour was intended (though i don't know the reason).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4207292#4207292
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4207292
15 years, 4 months
[Design of EJB 3.0] - Design of EJB 3.1 @Asynchronous
by ALRubinger
This is to document an initial proposal for design of the new @Asynchronous handling required of EJB 3.1. Initially I'll describe the flow in prose until I get some good diagrams. :)
I'm sure this will change a bunch as I start to prototype. I'm not a fan of big-design-up-front and tend to work out the kinks while coding.
Overall Goals
* Every component should get an SPI and allow for pluggable/configurable implementations
* Remoting is a functional add-on, not baked into the API. Remoting impls may be swapped.
Components Involved
Async Interceptor - Responsible for short-circuting the client invocation. Examines invocation metadata, determines if it's targeted for async. If so, pushes the invocation to an InvocationQueue and returns a j.u.c.Future implementation to the client.
Async Future - A (possibly) remotable handle for the client to obtain the result, check if completed, request a cancellation, etc.
InvocationQueue - Acts both as a queue of Invocations and a queryable registry. Supports isCancelled(Invocation uid), hasCompleted(Invocation uid), . Must be thread-safe.
Thread Pool - Used by AsyncExecutor. Possibly implemented by MC ThreadPool deployers https://svn.jboss.org/repos/sandbox/david.lloyd/jboss-threads/trunk/
AsyncExecutor - A custom implementation of j.u.c.Executor which uses the configured Thread Pool to run jobs.
InvocationSucker - Begs for a better name. Inspired by JBM "MessageSucker". Runs in a loop, pulls the next Invocation off the queue (if present), and uses the AsyncExecutor (and by extension the configured Thread Pool) to invoke upon the appropriate SessionContainer.
Server's Future Invocation Endpoint - Serves invocations upon the Future object by the client. May query upon the InvocationQueue, as well as register itself for callbacks when state changes in the queue occur.
Control Flow
Client Invocation
* Client invokes upon a business method annotated with @Asynchronous
* Server's AsyncInterceptor determines this is an async invocation. Pushes the invocation upon the InvocationQueue and returns a handle back to the client in form of the AsyncFuture.
* InvocationSucker loops around and finds this new invocation on the queue. Makes a state change on the queue to "processing" and invokes the Invocation upon the Container via the AsyncExecutor.
* AsyncExecutor obtains either return value or Exception, and stores this back into the InvocationQueue under a state of "completed"
Future.get() when result is available
* Client obtains Future result from AsyncInterceptor
* Client invokes Future.get()
* Server's Future Invocation Endpoint queries upon the InvocationQueue if the invocation is done. Since it is, obtains the result and returns to the client.
Future.get() when result is not available
* Client obtains Future result from AsyncInterceptor
* Client invokes Future.get()
* Server's Future Invocation Endpoint queries upon the InvocationQueue if the invocation is done. Since it is not, a callback is registered within the Queue.
* Future Invocation Endpoint blocks (Thread.wait() or NIO blocking)
* When the queue gets a state change on the invocation in question, queue notifies the endpoint with the result
* Endpoint returns to client
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4207242#4207242
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4207242
15 years, 4 months
[Design of POJO Server] - Re: The DeploymentManager and ProfileService
by emuckenhuber
"scott.stark(a)jboss.org" wrote :
| 3. The ProfileServiceBootstrap needs to call the AbstractBootstrapProfileFactory createProfile(Map profiles, List subProfiles, ProfileKey key, List profileMetaData) method as there may be ProfileMetaData coming in from the bootstrap environment.
|
Hmm well the AbstractBootstrapProfileFactory is a rough prototype and it might not be valid.
I think it would be good if it also activates the profiles in more or less the correct order,
so that we can get rid of the implicit dependencies i was mentioning before.
"scott.stark(a)jboss.org" wrote :
| 4. We need the ability to have multiple ProfileFactorys that are either associated with a ProfileMetaData or tolerant of ProfileMetaData they don't understand so that a mixture of profile implementations can be built up.
|
Yes there should be more ProfileFactories, at the moment it is all delegated to the DeploymentRepository,
but as i was mentioning already most of that could be done by the Profile itself.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4207228#4207228
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4207228
15 years, 4 months
[Design of JBoss Remoting, Unified Invokers] - Re: Remoting 2: Timeout waiting on socket for InvokerLocator
by ron.sigal＠jboss.com
"sentcs" wrote :
| how to increase the number of connections
|
Normally, the default value is 50, as I said, and, normally, the parameter to set is "clientMaxPoolSize". However, setting that value in JBossMessaging's remoting-bisocket-service.xml would also affect callback clients on the server side, which the JBM guys didn't want to do, so they created a JBM specific parameter, "JBM_clientMaxPoolSize". Also, I see that they set it to "200" in remoting-bisocket-service.xml.
"sentcs" wrote :
| And i want know, any impact if i am going to change the number of connection
|
If you are actually exhausting the pool, and you increase the pool size, then you could get more activity on the client, for better or worse. Also, a single client could take up more of the server's resources. If the server isn't overloaded, then you might consider increasing the number of worker threads on the server, using the "maxPoolSize" parameter. The default is 300.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4207202#4207202
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4207202
15 years, 4 months