[Design of JBoss Transaction Services] - TransactionManager and AS' ServiceBindingManager
by bstansberry＠jboss.com
Follow-up on a brief discussion that came up on the jboss-as list a few weeks ago.
ServiceBindingManager is an AS service that provides support for preventing port conflicts if 2 AS instances are started on the same machine and the ASs aren't bound to different interfaces. I've been having to redo the SBM to allow it to deal with pojo services, since before it could only work with mbeans. If you're interested in details on that, see http://wiki.jboss.org/wiki/AS5ServiceBindingManager and the forum thread linked at the top of that wiki.
I can now get SBM working with all services that deploy in the AS, except the TransactionManager -- specifically its recovery manager, which is configured via conf/jbossjta-properties.xml. It appears the TM internally parses that file, so the existing SBM integration hooks won't work.
Some possibilities:
1) Expose some property on the "TransactionManager" bean that trumps the value that comes out of jbossjta-properties.xml. The microcontainer can then use the SBM as the source of the correct value.
2) Have whatever parses jbossjta-properties.xml support system property substitution, e.g.
<property name="com.arjuna.ats.arjuna.recovery.recoveryPort" value="${jbossts.recovery.port:4712}"/>
We'd then deploy a bean along with the SBM that sets the proper system property. Hacky, and leaves the problem of ensuring the SBM deploys before the TransactionManager.
3) If the location where this jbossjta-properties.xml comes from can be made configurable on the TransactionManager bean, we can use a hack like we use on the Tomcat server.xml file. The SBM is given the location of the base file, does an XSL Transform on it to put in the correct values, saves the result as a temp file, and the service is told to use the temp file for its configuration. A long-standing hack whose usage I for sure would hate to see expanded.
Any thoughts?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169971#4169971
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169971
17 years, 8 months
[Design of Messaging on JBoss (Messaging/JBoss)] - JBM and AS' ServiceBindingManager
by bstansberry＠jboss.com
I've been having to redo the JBoss AS ServiceBindingManager service to allow it to deal with pojo services. Before it could only work with mbeans. For details on the changes, see http://wiki.jboss.org/wiki/AS5ServiceBindingManager and the forum thread linked at the top of that wiki. Essential difference is that deployments that use ports go to the SBM as part of their configuration step to get the config value, rather than counting on SBM to know how to override their configuration.
This intersects with JBM because you guys provide the remoting-bisocket-service.xml file, which specifies the address/port for your remoting connector. For that file to work properly with the new SBM impl, we need to come up with a workable format for the jboss.messaging:service=Connector,transport=bisocket mbean.
The existing config:
| <mbean code="org.jboss.remoting.transport.Connector"
| name="jboss.messaging:service=Connector,transport=bisocket"
| display-name="Bisocket Transport Connector">
| <attribute name="Configuration">
| <config>
| <invoker transport="bisocket">
| <!-- There should be no reason to change these parameters - warning!
| Changing them may stop JBoss Messaging working correctly -->
| <attribute name="marshaller" isParam="true">org.jboss.jms.wireformat.JMSWireFormat</attribute>
| <attribute name="unmarshaller" isParam="true">org.jboss.jms.wireformat.JMSWireFormat</attribute>
| <attribute name="dataType" isParam="true">jms</attribute>
| <attribute name="socket.check_connection" isParam="true">false</attribute>
| <attribute name="serverBindAddress">${jboss.bind.address}</attribute>
| <attribute name="serverBindPort">4457</attribute>
| <attribute name="clientSocketClass" isParam="true">org.jboss.jms.client.remoting.ClientSocketWrapper</attribute>
| <attribute name="serverSocketClass">org.jboss.jms.server.remoting.ServerSocketWrapper</attribute>
|
| <attribute name="numberOfCallRetries" isParam="true">1</attribute>
| <attribute name="pingFrequency" isParam="true">214748364</attribute>
| <attribute name="pingWindowFactor" isParam="true">10</attribute>
| <attribute name="onewayThreadPool">org.jboss.jms.server.remoting.DirectThreadPool</attribute>
|
| <!-- End immutable parameters -->
|
| <attribute name="stopLeaseOnFailure" isParam="true">true</attribute>
|
| <!-- Periodicity of client pings. Server window by default is twice this figure -->
| <attribute name="clientLeasePeriod" isParam="true">10000</attribute>
|
| <attribute name="timeout" isParam="true">0</attribute>
|
| <!-- Number of seconds to wait for a connection in the client pool to become free -->
| <attribute name="numberOfRetries" isParam="true">10</attribute>
|
| <!-- Max Number of connections in client pool. This should be significantly higher than
| the max number of sessions/consumers you expect -->
| <attribute name="JBM_clientMaxPoolSize" isParam="true">200</attribute>
|
| <!-- The maximum time to wait before timing out on trying to write a message to socket for delivery -->
| <attribute name="callbackTimeout">10000</attribute>
|
|
| <!-- Use these parameters to specify values for binding and connecting control connections to
| work with your firewall/NAT configuration
| <attribute name="secondaryBindPort">xyz</attribute>
| <attribute name="secondaryConnectPort">abc</attribute>
| -->
|
| </invoker>
|
| <handlers>
| <handler subsystem="JMS">org.jboss.jms.server.remoting.JMSServerInvocationHandler</handler>
| </handlers>
| </config>
| </attribute>
| </mbean>
A version that asked the ServiceBindingManager to provide the configuration with the appropriate address/port would look like this:
| <mbean code="org.jboss.remoting.transport.Connector"
| name="jboss.messaging:service=Connector,transport=bisocket"
| display-name="Bisocket Transport Connector">
| <attribute name="Configuration">
|
| <value-factory bean="ServiceBindingManager" method="getElementBinding">
| <parameter>
| jboss.messaging:service=Connector,transport=bisocket
| </parameter>
| <parameter><![CDATA[
| <config>
| <invoker transport="bisocket">
| <!-- There should be no reason to change these parameters - warning!
| Changing them may stop JBoss Messaging working correctly -->
| <attribute name="marshaller" isParam="true">org.jboss.jms.wireformat.JMSWireFormat</attribute>
| <attribute name="unmarshaller" isParam="true">org.jboss.jms.wireformat.JMSWireFormat</attribute>
| <attribute name="dataType" isParam="true">jms</attribute>
| <attribute name="socket.check_connection" isParam="true">false</attribute>
| <attribute name="serverBindAddress">${host}</attribute>
| <attribute name="serverBindPort">${port}</attribute>
| <attribute name="clientSocketClass" isParam="true">org.jboss.jms.client.remoting.ClientSocketWrapper</attribute>
| <attribute name="serverSocketClass">org.jboss.jms.server.remoting.ServerSocketWrapper</attribute>
|
| <attribute name="numberOfCallRetries" isParam="true">1</attribute>
| <attribute name="pingFrequency" isParam="true">214748364</attribute>
| <attribute name="pingWindowFactor" isParam="true">10</attribute>
| <attribute name="onewayThreadPool">org.jboss.jms.server.remoting.DirectThreadPool</attribute>
|
| <!-- End immutable parameters -->
|
| <attribute name="stopLeaseOnFailure" isParam="true">true</attribute>
|
| <!-- Periodicity of client pings. Server window by default is twice this figure -->
| <attribute name="clientLeasePeriod" isParam="true">10000</attribute>
|
| <attribute name="timeout" isParam="true">0</attribute>
|
| <!-- Number of seconds to wait for a connection in the client pool to become free -->
| <attribute name="numberOfRetries" isParam="true">10</attribute>
|
| <!-- Max Number of connections in client pool. This should be significantly higher than
| the max number of sessions/consumers you expect -->
| <attribute name="JBM_clientMaxPoolSize" isParam="true">200</attribute>
|
| <!-- The maximum time to wait before timing out on trying to write a message to socket for delivery -->
| <attribute name="callbackTimeout">10000</attribute>
|
|
| <!-- Use these parameters to specify values for binding and connecting control connections to
| work with your firewall/NAT configuration
| <attribute name="secondaryBindPort">xyz</attribute>
| <attribute name="secondaryConnectPort">abc</attribute>
| -->
|
| </invoker>
|
| <handlers>
| <handler subsystem="JMS">org.jboss.jms.server.remoting.JMSServerInvocationHandler</handler>
| </handlers>
| </config>
| ]]>
| </parameter>
| </value-factory>
| </attribute>
| </mbean>
Basically, the whole "config" element is passed as a parameter to the SBM, which does a replacement operation on the embedded ${host} and ${port}.
That's quite ugly but works. An alternative is to no longer configure the connector as an mbean with an injected element, but rather as an MC pojo with an injected org.jboss.remoting.ServerConfiguration bean. The bean exposes the properties above. The port still comes from the SBM but all the CDATA messiness is gone.
Another issue is where this file comes from. It won't look like one used outside the AS; don't know if that's an issue for you. If it is an issue, a third possibility is to keep the file as-is, except replace
<attribute name="serverBindPort">4457</attribute>
with
<attribute name="serverBindPort">${jboss.messaging.connector.bisocket.port:4457}</attribute>
The AS would then need to deploy a bean alongside the SBM that sets the jboss.messaging.connector.bisocket.port system property from the SBM before JBM deploys. That's kind of hacky, but does decouple JBM from all this stuff.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169967#4169967
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169967
17 years, 8 months
[Design of POJO Server] - Moving AS5_trunk to latest MC Betas
by alesj
I've committed my changes from this thread:
- http://www.jboss.com/index.html?module=bb&op=viewtopic&t=140655
- JBAS-5848
- JBAS-5804
- JBAS-5807
But I get a few smoke-tests failures,
which I don't see how can they be related to MC update.
Test org.jboss.test.cts.test.CtsCmp2UnitTestCase FAILED
| javax.naming.NamingException: Could not dereference object [Root exception is javax.naming.NameNotFoundException: cts-v1cmp not bound]" type="java.rmi.ServerException">java.rmi.ServerException: testV1 failed; nested exception is:
| javax.naming.NamingException: Could not dereference object [Root exception is javax.naming.NameNotFoundException: cts-v1cmp not bound]
| at org.jboss.test.cts.ejb.CtsCmp2SessionBean.testV1(CtsCmp2SessionBean.java:62)
| at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
| at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
| at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
| at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
| at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
| at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
| at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350)
| at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
| at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:248)
| at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:83)
| at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
| at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
| at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:651)
| at org.jboss.ejb.Container.invoke(Container.java:1028)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
| at org.jboss.invocation.unified.server.UnifiedInvoker.invoke(UnifiedInvoker.java:232)
| at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:847)
| at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:681)
| at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:634)
| at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:486)
| at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:197)
|
Test org.jboss.test.web.test.WebIntegrationUnitTestCase FAILED
Couple of these:
| <testcase classname="org.jboss.test.web.test.WebIntegrationUnitTestCase" name="testENCServlet" time="0.172">
| <error message="Expected reply code:200, actual=500" type="java.io.IOException">java.io.IOException: Expected reply code:200, actual=500
| at org.jboss.test.util.web.HttpUtils.accessURL(HttpUtils.java:137)
| at org.jboss.test.util.web.HttpUtils.accessURL(HttpUtils.java:108)
| at org.jboss.test.util.web.HttpUtils.accessURL(HttpUtils.java:96)
| at org.jboss.test.util.web.HttpUtils.accessURL(HttpUtils.java:82)
| at org.jboss.test.web.test.WebIntegrationUnitTestCase.testENCServlet(WebIntegrationUnitTestCase.java:91)
| at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
| at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
| at junit.extensions.TestSetup.run(TestSetup.java:23)
|
Test org.jboss.test.xml.DDValidatorUnitTestCase FAILED
| <testcase classname="org.jboss.test.xml.DDValidatorUnitTestCase" name="testJBossWeb" time="0.968">
| <failure message="1 from 55 are invalid: [Failed to parse: C:\projects\jboss5\trunk\testsuite\output\resources\cluster\http\http-sr\WEB-INF\jboss-web.xml: cvc-elt.1: Cannot find the declaration of element 'jboss-web'. [3,12]] expected:<0> but was:<1>" type="junit.framework.AssertionFailedError">junit.framework.AssertionFailedError: 1 from 55 are invalid: [Failed to parse: C:\projects\jboss5\trunk\testsuite\output\resources\cluster\http\http-sr\WEB-INF\jboss-web.xml: cvc-elt.1: Cannot find the declaration of element 'jboss-web'. [3,12]] expected:<0> but was:<1>
| at org.jboss.test.xml.DDValidatorUnitTestCase.validate(DDValidatorUnitTestCase.java:145)
| at org.jboss.test.xml.DDValidatorUnitTestCase.testJBossWeb(DDValidatorUnitTestCase.java:126)
|
Can authors / 'involved in those test areas' please check if my
changes are the real cause of those failures?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169965#4169965
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169965
17 years, 8 months