[JBoss Messaging] - Bridge Deployment Failures: queue not bound on AS startup, r
by rnicholson10
If I start jboss AS 5, my bridge will not deploy as it would appear that the local queue is created after the attempt to start the bridge. If I then touch the bridge configuration once jboss has started, the bridge starts ok (In this case the remote node is up and running). Is there some way I can make the bridge deployment be dependent on the local queue being active?
| 2009-02-04 13:50:20,790 ERROR [org.jboss.system.server.profileservice.ProfileServiceBootstrap] (main) Failed to load profile: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
|
| *** CONTEXTS IN ERROR: Name -> Error
|
| jboss.messaging:name=TestBridge,service=Bridge -> javax.naming.NameNotFoundException: queue not bound
|
The other problem I have is that if the remote node is not running when I deploy the bridge after startup, deployment fails and so the bridge never starts. Surely the bridge should start regardless of the state of the other node, and connect when the node becomes available?
My bridge configuration is as follows:
| <mbean code="org.jboss.jms.server.bridge.BridgeService" name="jboss.messaging:service=Bridge,name=TestBridge" xmbean-dd="xmdesc/Bridge-xmbean.xml">
|
| <depends optional-attribute-name="SourceProviderLoader">jboss.messaging:service=JMSProviderLoader,name=JMSProvider</depends>
| <depends optional-attribute-name="TargetProviderLoader">jboss.messaging:service=JMSProviderLoader,name=RemoteJMSProvider</depends>
|
| <attribute name="SourceDestinationLookup">/queue/speQueue</attribute>
| <attribute name="TargetDestinationLookup">/queue/speQueueEnd</attribute>
| <attribute name="QualityOfServiceMode">2</attribute>
| <attribute name="MaxBatchSize">1</attribute>
| <attribute name="MaxBatchTime">-1</attribute>
| <attribute name="FailureRetryInterval">5000</attribute>
| <attribute name="MaxRetries">-1</attribute>
| <attribute name="AddMessageIDInHeader">false</attribute>
| </mbean>
|
Once the bridge is up and running everything is fine. The remote node can appear/disappear all it wants and the bridge delivers messages everytime the remote node becomes available.
Any help appreciated, thanks
Ross
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206984#4206984
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206984
17 years, 2 months
[Remoting] - Re: Problem using JaxWS over HTTPS connection from within a
by adinn
Ok, I resolved the SSLSocketBuilder error by adding
| -Djavax.net.ssl.trustStore=$JBOSS_HOME/server/default/conf/wsse.truststore -Djavax.net.ssl.trustStorePassword=jbossws -Djavax.net.ssl.keyStore=$JBOSS_HOME/server/default/conf/wsse.keystore -Djavax.net.ssl.keyStorePassword=jbossws
|
to JAVA_OPTS. I am now getting a different which is actually more baffling.
| 13:56:38,256 INFO [STDOUT] CLIENT: obtaining userTransaction...
| 13:56:38,257 INFO [STDOUT] CLIENT: starting the transaction...
| 13:56:38,949 ERROR [SOAPFaultHelperJAXWS] SOAP request exception
| java.io.IOException: Could not transmit message
| at org.jboss.ws.core.client.HTTPRemotingConnection.invoke(HTTPRemotingConnection.java:264)
| at org.jboss.ws.core.client.SOAPProtocolConnectionHTTP.invoke(SOAPProtocolConnectionHTTP.java:71)
| at org.jboss.ws.core.CommonClient.invoke(CommonClient.java:340)
| at org.jboss.ws.core.jaxws.client.ClientImpl.invoke(ClientImpl.java:291)
| at org.jboss.ws.core.jaxws.client.ClientProxy.invoke(ClientProxy.java:170)
| at org.jboss.ws.core.jaxws.client.ClientProxy.invoke(ClientProxy.java:150)
| at $Proxy205.createCoordinationContextOperation(Unknown Source)
| at com.arjuna.webservices11.wscoor.client.ActivationCoordinatorClient.sendCreateCoordination(ActivationCoordinatorClient.java:86)
| at com.arjuna.wsc11.ActivationCoordinator.createCoordinationContext(ActivationCoordinator.java:76)
| at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.startTransaction(UserTransactionImple.java:195)
| at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.begin(UserTransactionImple.java:78)
| at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.begin(UserTransactionImple.java:68)
| at com.jboss.jbosstm.xts.demo.client.BasicClient.testAtomicTransaction(BasicClient.java:456)
| at com.jboss.jbosstm.xts.demo.client.BasicClient.doGet(BasicClient.java:408)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
| at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
| at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
| at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
| at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
| at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
| at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
| at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
| at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
| at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
| at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
| at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
| at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
| at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
| at java.lang.Thread.run(Thread.java:595)
| Caused by: org.jboss.remoting.CannotConnectException: Can not connect http client invoker after 1 attempt(s)
| at org.jboss.remoting.transport.http.HTTPClientInvoker.makeInvocation(HTTPClientInvoker.java:246)
| at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:158)
| at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:160)
| at org.jboss.remoting.Client.invoke(Client.java:1708)
| at org.jboss.remoting.Client.invoke(Client.java:612)
| at org.jboss.ws.core.client.HTTPRemotingConnection.invoke(HTTPRemotingConnection.java:242)
| ... 35 more
| Caused by: java.io.IOException: HTTPS hostname wrong: should be <127.0.0.1>
| at sun.net.www.protocol.https.HttpsClient.checkURLSpoofing(HttpsClient.java:490)
| at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:415)
| at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166)
| at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:857)
| at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:230)
| at org.jboss.remoting.util.SecurityUtility.getOutputStream(SecurityUtility.java:1514)
| at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:331)
| at org.jboss.remoting.transport.http.HTTPClientInvoker.makeInvocation(HTTPClientInvoker.java:228)
| ... 40 more
|
So, I noticed the fairly generous hint provided by the error message "HTTPS hostname wrong: should be <127.0.0.1>".
I modified my keystore and truststore to include certificates with -alias 127.0.0.1 -dname "CN=127.0.0.1". I also modified my Activation Service proxy to use address "https:127.0.0.1:8443/ws-c11/ActrivationService". I checked and this was the address passed into the remoting layer. No joy.
As a last ditch measure I tried booting JBossAS using -b 127.0.0.1. Still no joy.
Any ideas?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206981#4206981
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206981
17 years, 2 months
[JBoss Cache: Core Edition] - Re: Problems with Transaction Manager
by fatboysuns
Yes I have, When I try JbossTransactionManagerLookup, I get a classcast exception. I did try the JbossstandaloneJTAlookup too with no luck.
I have tried to even upgrade my jboss from 4.05 to 4.23 with no luck. The surprising thing there was, When I ran a test to basically typecast arjuna.ats.JbossATX.transactionManager, which was the transactionManager that was getting returned in 4.23, to javax.transaction.TransactionManager, It ran fine. I did see that it had a parent class which implements TransactionManager. But When I ran I via the app, I got a classcast Exception again. I am not sure what I should do.
This was just a test as I dont think I can upgrade Jboss in production anytime soon too. Do you think I should use jboss-cache 2.x version instead of the 3.x version? If so which version does support jboss searchable?
Any help would be great.
Thanks
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206970#4206970
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206970
17 years, 2 months