[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Cluster - Destination SecurityConfig Lost
by aslak
The cluster consist of 2 identical nodes. The Client connects to the Cluster using a ClusteredConnection.
It then creates a Temporary destination for replyTo on node1. Node1 is killed, and the ClusteredConnection tries a failover to node2, but failes to lookup the Temporary Destination with the following exception:
| 30276 [main] ERROR org.jboss.jms.client.FailoverCommandCenter - Failover failed
| javax.jms.InvalidDestinationException: No such destination: JBossTemporaryQueue[f-46mldp6f-1-75lldp6f-izthbc-273333a] has it been deployed?
| at org.jboss.jms.server.endpoint.ServerSessionEndpoint.createConsumerDelegateInternal(ServerSessionEndpoint.java:1872)
| at org.jboss.jms.server.endpoint.ServerSessionEndpoint.createConsumerDelegate(ServerSessionEndpoint.java:245)
| at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionAdvised$createConsumerDelegate$aop(SessionAdvised.java:87)
| at org.jboss.jms.server.endpoint.advised.SessionAdvised$createConsumerDelegate_8721389917985689973.invokeNext(SessionAdvised$createConsumerDelegate_8721389917985689973.java)
| at org.jboss.jms.server.container.SecurityAspect.handleCreateConsumerDelegate(SecurityAspect.java:123)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:597)
| at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:121)
| at org.jboss.jms.server.endpoint.advised.SessionAdvised$createConsumerDelegate_8721389917985689973.invokeNext(SessionAdvised$createConsumerDelegate_8721389917985689973.java)
| at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
| at org.jboss.jms.server.endpoint.advised.SessionAdvised$createConsumerDelegate_8721389917985689973.invokeNext(SessionAdvised$createConsumerDelegate_8721389917985689973.java)
| at org.jboss.jms.server.endpoint.advised.SessionAdvised.createConsumerDelegate(SessionAdvised.java)
| at org.jboss.jms.wireformat.SessionCreateConsumerDelegateRequest.serverInvoke(SessionCreateConsumerDelegateRequest.java:100)
| at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:144)
| at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:769)
| at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:573)
| at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:387)
| at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:166)
|
The lookup in createConsumerDelegateIneral is looking for the Destination in the DestinationManager.
| ManagedDestination mDest = dm.getDestination(jmsDestination.getName(), jmsDestination.isQueue());
| if (mDest == null)
| {
| throw new InvalidDestinationException("No such destination: " + jmsDestination + " has it been deployed?");
| }
|
As far as I have debuged; the Temporary Destination MappingInfo is sent to node2 so the Destination
is bound in memory, but not in the DestinationManager.
-aslak-
(if Destinations had been bound to the DestinationManager, shouldn't deploying destinations only on one node also work?)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085239#4085239
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085239
18 years, 6 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Can't configure a single, shared JGroups channel
by bstansberry＠jboss.com
This shouldn't be an issue. From the JBM point of view, you have two separate channels. Code written to use your control channel will not see messages destined for your data channel, and vice versa. It's just that the JGroups multiplexes them on top of the same underlying JChannel.
When you call JChannelFactory.createMultiplexerChannel("udp", "DefaultPartition-JMS", true, "DefaultPartition-JMS") you're asking the channel factory to give you a channel based on the "udp" config. If there isn't already a multiplexed channel based on "udp" the factory will create a regular JChannel based on the "udp" config. It will then attach an instance of Multiplexer to that JChannel. It will then create an instance of MuxChannel and register it with the Multiplexer under the id "DefaultPartition-JMS". That MuxChannel is what gets returned to you. When you send messages using the MuxChannel, the Multiplexer adds "DefaultPartition-JMS" as a header to the message. On the other side, the Multiplexer reads messages off the underlying JChannel, reads out the "DefaultPartition-JMS" header, and passes them on to the correct MuxChannel.
Note that the factory will only create one underlying JChannel based on "udp"; anyone who passes "udp" as an arg will get a MuxChannel that's using that same underlying JChannel. So, if other AS services also use "udp", they'll be sharing the same underlying channel with JBM.
The problem I'm describing occurs from this usage in MultiplexerJChannelFactory:
| public JChannel createControlChannel() throws Exception
| {
| return (JChannel) server.invoke(this.channelFactory, MUX_OPERATION,
| new Object[]{syncStack, uniqueID, Boolean.TRUE, uniqueID}, MUX_SIGNATURE);
| }
|
| public JChannel createDataChannel() throws Exception
| {
| return (JChannel) server.invoke(this.channelFactory, MUX_OPERATION,
| new Object[]{asyncStack, uniqueID, Boolean.TRUE, uniqueID}, MUX_SIGNATURE);
| }
|
If syncStack and asyncStack are the same, JGroups will barf when you ask for the 2nd channel. This fixes the problem in a brute way:
| public JChannel createControlChannel() throws Exception
| {
| String controlId = uniqueId + "-CTRL";
| return (JChannel) server.invoke(this.channelFactory, MUX_OPERATION,
| new Object[]{syncStack, controlId, Boolean.TRUE, controlID}, MUX_SIGNATURE);
| }
|
| public JChannel createDataChannel() throws Exception
| {
| String dataId = uniqueId + "-DATA";
| return (JChannel) server.invoke(this.channelFactory, MUX_OPERATION,
| new Object[]{asyncStack, dataID, Boolean.TRUE, dataID}, MUX_SIGNATURE);
| }
|
BTW, I see in MultiplexerJChannelFactory you're casting the return from createMultiplexerChannel() to the concrete class JChannel. The API for the method returns interface Channel. The cast works because MuxChannel subclasses JChannel. But that's really an implementation detail you *shouldn't* count on. I doubt Bela will change it any time soon, but...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085228#4085228
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085228
18 years, 6 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Cluster - Destination SecurityConfig Lost
by timfox
"aslak" wrote : This issue came up during something that might have been a missconfiguration.
| I was trying to setup a two node cluster where the destinations were only deployed on one node(not using farm),
| figuring that they would be transferred over to the second node.
| InMemoryBindings are added to the second node, but the SecurityMetaData is missing.
| After adding some code to transferred the SecurityMetaData, I found that they are never bound to the DestinationManager,
| so they are never found by any deployed mdbs on the second node.
|
Any clustered destinations need to be deployed on all nodes
anonymous wrote :
| I tried a different setup deploying the same destinations on both nodes, that's when I saw this problem:
| http://www.jboss.org/index.html?module=bb&op=viewtopic&t=118320
|
| When removing the security, it failes on the temporary destination not being bound.
| The scenario is:
| Using the ClusteredConnectionFactory, create a temporary destination on node1.
| Kill node1, the failover to node2 failes because there is no Temporary Destination
| with name X bound in node2s DestinationManager.
|
| The next potential issue is somehow the connection to the second node has to get the connection id of the first connection, or register itself as the owner of the temporary destination to be able to keep up the tempdestination.createdConnectionId == connection.id security constraint.
| I havn't looked into this yet, it might work already.
|
| -aslak-
I'm having a bit of a problem understanding your explanation - could you possibly rephrase it?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085204#4085204
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085204
18 years, 6 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Cluster - Destination SecurityConfig Lost
by aslak
This issue came up during something that might have been a missconfiguration.
I was trying to setup a two node cluster where the destinations were only deployed on one node(not using farm),
figuring that they would be transferred over to the second node.
InMemoryBindings are added to the second node, but the SecurityMetaData is missing.
After adding some code to transferred the SecurityMetaData, I found that they are never bound to the DestinationManager,
so they are never found by any deployed mdbs on the second node.
I tried a different setup deploying the same destinations on both nodes, that's when I saw this problem:
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=118320
When removing the security, it failes on the temporary destination not being bound.
The scenario is:
Using the ClusteredConnectionFactory, create a temporary destination on node1.
Kill node1, the failover to node2 failes because there is no Temporary Destination
with name X bound in node2s DestinationManager.
The next potential issue is somehow the connection to the second node has to get the connection id of the first connection, or register itself as the owner of the temporary destination to be able to keep up the tempdestination.createdConnectionId == connection.id security constraint.
I havn't looked into this yet, it might work already.
-aslak-
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085189#4085189
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085189
18 years, 6 months
[Design of Security on JBoss] - Re: Security Integration in JBAS5
by scott.stark＠jboss.org
"anil.saldhana(a)jboss.com" wrote :
| c) SecurityContextClassName - The Container creates a security context in the thread of execution. This FQN tells which SecurityContext implementation needs to be created.
| The container after creating the SC, injects the SecurityManagement instance into the SC, such that whenever any code asks the SC for a SecurityManager, it can delegate it to the SecurityManagement instance.
|
|
| war-deployer-beans.xml
| |
| | <!-- The WebMetaData to service mbean deployer -->
| | <bean name="WarDeployer" class="org.jboss.web.tomcat.service.deployers.Tomcat
| | Deployer">
| | ...
| | <!-- Specify a SecurityManagement Wrapper -->
| | <property name="securityManagement">
| | <inject bean="JNDIBasedSecurityManagement"/>
| | </property>
| |
| | <!-- Specify a SecurityContext FQN class name -->
| | <property name="securityContextClassName">org.jboss.security.plugins.JBos
| | sSecurityContext</property>
| |
|
| Similar case exists for the EJB deployer.
Ultimately this should be outside of the deployer in the security interceptor configuration. Configs like the ejb3-interceptors-aop.xml should be injecting the Security related beans that are defined in the security-deployer-beans.xml or similar. I don't see these properties in the current TomcatDeployer. Is this checked in?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085142#4085142
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085142
18 years, 6 months