[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Server side HA and failover
by timfox
"bstansberry(a)jboss.com" wrote :
|
| The stuff that should be reused is the interceptor model.
|
|
This is the client side interceptor model?
anonymous wrote :
|
| 2) The JGroups view can't be used directly, as a JGroups Address is not suitable for use as a Remoting InvokerLocator. At minimum a different port. Quite possibly a different IP address (e.g. client connections use a different NIC than clustering traffic.) I think the thing to do is something like adding another Request type where a server publishes its InvokerLocator(s); the rest of the cluster maintains a map of that data. That's basically the DistributedReplicantManager concept.
|
|
I think we would need to replicate both the remoting invoker locator and the JGroups address.
The client needs to know the locator list but a particular server also needs to know who it's failover server(s) are, this is so it can do stuff like cast messages to it's failover servers when we do in memory message replication. A JGroups address would be ideal for this.
We should be able to support multiple failover servers for a particular server.
anonymous wrote :
|
| Perhaps an approach where the client fails over to anyone, but if the server isn't the appropriate one it communicates that back to the client, along with the updated topology and info as to who the failover server should be.
|
I like this idea.
anonymous wrote :
| Stupid question: why does the client need to fail over to a particular server? The failover server needs to do work to recover persistent messages from the store, but once it's done that, aren't they available to a client connecting to any server?
Each server maintains it's own set of queues each containing different sets of messages.
So when a node fails the failover node needs to take over responsibility for the queues on the node that failed.
This means creating those queues in memory and loading any persistent messages from storage into those queues (if in memory replication is being used the messages will already be there so no need to load from storage).
This means clients need to reconnect the node which now hosts those queues so they can continue as if nothing happened.
As an added complication we also need to decide what happens when the failed node comes back to life.
Does it take over responsbility for the original queues it has?
Actually I don't think this is possible unless there are no clients using those queues on the failover node, since we would have to disconnect and reconnect the connections on the resurrected node which would mean losing any persistent messages delivered in those sessions which would be unacceptable.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977484#3977484
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977484
19 years, 6 months
[Design of JBoss jBPM] - Re: MessageService and JMS
by mteira
It seems that the problem is related with the fact that JBoss is not exposing the UserTransaction under java:comp/UserTransaction (that I think it's the standard or at least recommended place to expose it), it's exposed under the global JNDI namespace as 'UserTransaction'. So, I've made changes as shown in this patch:
### Eclipse Workspace Patch 1.0
| #P jbpm
| Index: jpdl/jar/src/main/config/hibernate.cfg.xml
| ===================================================================
| RCS file: /cvsroot/jbpm/jbpm.3/jpdl/jar/src/main/config/hibernate.cfg.xml,v
| retrieving revision 1.11
| diff -u -r1.11 hibernate.cfg.xml
| --- jpdl/jar/src/main/config/hibernate.cfg.xml 22 Sep 2006 14:23:25 -0000 1.11
| +++ jpdl/jar/src/main/config/hibernate.cfg.xml 11 Oct 2006 10:20:58 -0000
| @@ -26,7 +26,7 @@
|
| <!-- JTA transaction properties (begin) ===
| <property name="hibernate.transaction.factory_class">org.hibernate.transaction.JTATransactionFactory</property>
| - <property name="jta.UserTransaction">java:comp/UserTransaction</property>
| + <property name="jta.UserTransaction">UserTransaction</property>
| ==== JTA transaction properties (end) -->
|
| <!-- CMT transaction properties (begin) ===
Regards.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977483#3977483
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977483
19 years, 6 months
[Design of JBoss Portal] - LDAP Support expectations
by bdaw
I would like to ask for your opinions about expected LDAP support in JBoss Portal 2.6 as it's being implemented currently
For JBoss Portal 2.6 we decided to split identity responsibilities among four modules
- UserModule - users retreival and creation
| --- findUserByUserName()
| --- findUserById
| --- createUser()
| --- removeUser()
| --- ....
- RoleModule - roles retreival and creation
| --- findRoleByName()
| --- findRoleById
| --- createRole()
| --- removeRole()
| --- ....
- MembershipModule - discover and assign user/role relationship
| --- getRoles(User u)
| --- getUsers(Role r)
| --- assignRoles()
| --- assignUsers()
- UserProfileModule - takes care about user properties (name, surname, email...)
| --- getProperty()
| --- setProperty()
| --- getProperties()
| (This will enables to explicitly map user properties to specific attributes in ldap or columns in db)
Such split should enable more flexible implementation and usage for DB or LDAP. It is also designed
to be easily extendable by swapping any element by own implementation targeting more complex environment.
For LDAP
1) MembershipModule
Because user/role relationship can be defined in LDAP using several ways it will be based of pluggable
MembershipStrategy interface implementation. So out of box we plan to implement few base strategies like:
- StaticRoleLDAPMembershipStrategy
- StaticGroupLDAPMembershipStrategy
2) UserModule and RoleModule
We plan to provide two implementations for each
- Simple
--- user/role can be retrieved from only one specific location (like ou=Pople,dc=example,dc=com and ou=Roles,dc...)
--- user/role create() and remove() operation is supported
- Extended
--- user/role can be retrieved in more sophisticated way (like in http://wiki.jboss.org/wiki/Wiki.jsp?page=LdapExtLoginModule)
--- user/role create() and remove() operation is NOT supported
--- user/role relationship assignment operations in MembershipModule could be limited in some way
The requirenment for the implementation of whole is that LDAPUserImpl or LDAPRoleImpl instance is aware of it's DN,
to enable altering of this entry
This is the big picture from the design point of view.
What I'm interesting to learn from the JBoss Portal community are the expectations about user provisioning
features. LDAP servers are designed to be centralized identity repositories for whole organizations and in most cases
come with their own powerful management tools. In such cases portal will probably be one of many ldap server clients. So:
- are you interested of creating/removing users from within portal administration tools (like RolePortlet)
- are you interested in managing user/role relationship from within the portal?
Currently it's not our goal to provide any comprehensive ldap management console within the portal. We target the "simple"
implementation of UserModule and RoleModule to cover smaller deployments with simple ldap trees. We assume that
more complex tree shapes are managed with external tools anyway and just expect flexible authentication capabilities like those covered by LdapExtLoginModule in JBossSX framework.
Any thoughts about that?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977480#3977480
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977480
19 years, 6 months
[Design of POJO Server] - Re: Ordering of nested deployments
by scott.stark＠jboss.org
"adrian(a)jboss.org" wrote :
| This is just scheduling of deployments. It says, I'm going to deploy
| these components.
|
| The real deployment is done width first in a staged manner.
|
| I don't see the need to differentiate inner from outer deployments?
|
| Is there a case where stage N of an outer deployment depends
| upon stage N of an inner deployment?
| Why?
How do I control the order in which deployers that both rely on ServiceMetaData components to have these services started in the correct order? Its the old issue of lacking explicit service dependencies, having a coarse module based ordering mechanism. Currently the war deployer is a AbstractSimpleRealDeployer with the same relative order as the RARDeployer. A war with a nested rar has no guarentee of correct startup of the rar without an explicit dependency on its service. Maybe it will be irrelevant in the end as interaction with the rar services will be through injection and the required dependencies will show up, and this will be a non-issue.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977434#3977434
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977434
19 years, 6 months
[Design of POJO Server] - Property name compatibility issue
by scott.stark＠jboss.org
One issue I'm having is with translating legacy service descriptors to bean descriptor. There is a minor case problem with properties translated from mbean attribute names. The tomcat deployer is expecting lower case names for the properties, which were upper case in the jboss-service.xml:
| 21:07:22,475 ERROR [AbstractKernelController] Error installing to Configured: name=WarDeployer state=Instantiated
| org.jboss.joinpoint.spi.JoinpointException: Property DefaultSecurityDomain not found for AbstractBeanInfo(a)536c21db{name=org.jboss.web.tomcat.tc6.deployers.TomcatDeployer classInfo= properties=[useJBossWebLoader, authenticators, deleteWorkDirOnContextDestroy, defaultSecurityDomain, cacheName, java2ClassLoadingCompliance, snapshotInterval, useLocalCache, managerClass, httpHeaderForSSOAuth, lenientEjbLink, relativeOrder, acceptNonWarDirs, allowSelfPrivilegedWebApps, name, unpackWars, class, filteredPackages, snapshotMode, useJK, securityManagerService, deployedApplications, configFile, domain, subjectAttributeName, contextMBeanCode, sessionCookieForSSOAuth, sessionIdAlphabet] methods=[hashCode, setSubjectAttributeName, setSubjectAttributeName, addDeployedApp, setHttpHeaderForSSOAuth, clone0, getSnapshotInterval, setSessionCookieForSSOAuth, getDefaultSecurityDomain, setAllowSelfPrivilegedWebApps, getDeployedApp, setFilteredPackages, getDeployedApplications, getSessionIdAlphabet, commitUndeploy, setDeleteWorkDirOnContextDestroy, getJava2ClassLoadingCompliance, prepareUndeploy, wait, wait, wait, notify, getDomain, getLenientEjbLink, getSnapshotMode, setManagerClass, setSnapshotMode, getFilteredPackages, getDeleteWorkDirOnContextDestroy, isAllowSelfPrivilegedWebApps, setDefaultSecurityDomain, getSessionCookieForSSOAuth, getServer, isRelevant, setSecurityManagerService, getObjectName, getManagerClass, setCacheName, addURLs, getName, setUseJBossWebLoader, setAuthenticators, getSubjectAttributeName, getSubjectAttributeName, getTmpLoader, setConfigFile, start, start, setSessionIdAlphabet, setDomain, clone, undeploy, undeploy, undeploy, undeploy, undeploy, setJava2ClassLoadingCompliance, deployWebModule, deploy, deploy, deploy, deploy, deploy, commitDeploy, getCacheName, setUnpackWars, setContextMBeanCode, getAcceptNonWarDirs, stop, stop, buildWebContext, handoff, isUseJK, getUseJBossWebLoader, equals, runFinalizer, setUseLocalCache, startConnectors, getClass, toString, getClassLoaderURLs, getUnpackWars, setLenientEjbLink, notifyAll, getRelativeOrder, getRelativeOrder, getConfigFile, setUseJK, stopConnectors, prepareDeploy, finalize, getAuthenticators, handleNotification, getContextMBeanCode, setAcceptNonWarDirs, getDeployment, getDeployment, removeDeployedApp, getDeploymentType, getHttpHeaderForSSOAuth, setSnapshotInterval, isUseLocalCache] constructors=[] events=}
| at org.jboss.kernel.plugins.config.Configurator.resolveProperty(Configurator.java:668)
| at org.jboss.kernel.plugins.config.Configurator.getPropertySetterJoinPoint(Configurator.java:442)
| at org.jboss.kernel.plugins.config.Configurator.getPropertySetterJoinPoints(Configurator.java:407)
| at org.jboss.kernel.plugins.config.AbstractKernelConfigurator.getPropertySetterJoinPoints(AbstractKernelConfigurator.java:120)
| at org.jboss.kernel.plugins.dependency.ConfigureAction.installAction(ConfigureAction.java:52)
| at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.install(KernelControllerContextAction.java:96)
| at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:226)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:709)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:429)
|
|
Its easy enough to change the names in the descriptor.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977416#3977416
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977416
19 years, 6 months