[JBoss Messaging Development] - Time taken for messages to failover in a cluster
by Atul Singh
Atul Singh [http://community.jboss.org/people/iamatul] created the discussion
"Time taken for messages to failover in a cluster"
To view the discussion, visit: http://community.jboss.org/message/538852#538852
--------------------------------------------------------------
Hi
I am new to JMS and have to deal with a very advanced issue because of some reasons. Would be thankful for any pointers as the available documentation on JBoss JMS clustering is very vague/complex/diifcult to understand.
I am running JBoss 5.1 GA. I will have a cluster of two nodes. I want to have a (one) distributed JMS queue. There will be MDBs running on both the queues reading from the single distributed queue. The documentation suggests that on each node the distributed queue will be partial. With this background I have the following questions
1. Does this means that a message inserted into the queue will be visible to the MDB on on node only *?*
2. If one of the node fails (say hardware crash) then will the messages on the failed node will become available on the partial queue on the working node ? If yes then how long will it take ?
Thanks a lot,
Any tips pointers are greatly appreciated.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/538852#538852]
Start a new discussion in JBoss Messaging Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
[JBoss Cache] - NullMarkerNodeForRemoval issue
by Thomas Heute
Thomas Heute [http://community.jboss.org/people/thomas.heute%40jboss.com] created the discussion
"NullMarkerNodeForRemoval issue"
To view the discussion, visit: http://community.jboss.org/message/538849#538849
--------------------------------------------------------------
The NullMarkerNodeForRemoval object introduced to solve the following issue:
https://jira.jboss.org/jira/browse/JBCACHE-1493 https://jira.jboss.org/jira/browse/JBCACHE-1493
is generating a NPE:
java.lang.NullPointerException
at org.jboss.cache.invocation.NodeInvocationDelegate.clearDataDirect(NodeInvocationDelegate.java:243)
at org.jboss.cache.commands.write.ClearDataCommand.perform(ClearDataCommand.java:79)
at org.jboss.cache.interceptors.CallInterceptor.invokeCommand(CallInterceptor.java:108)
at org.jboss.cache.interceptors.CallInterceptor.handleAlterCacheMethod(CallInterceptor.java:173)
at org.jboss.cache.interceptors.CallInterceptor.visitClearDataCommand(CallInterceptor.java:149)
at org.jboss.cache.commands.write.ClearDataCommand.acceptVisitor(ClearDataCommand.java:86)
at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.jboss.cache.interceptors.EvictionInterceptor.visitClearDataCommand(EvictionInterceptor.java:235)
at org.jboss.cache.commands.write.ClearDataCommand.acceptVisitor(ClearDataCommand.java:86)
at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.jboss.cache.interceptors.MVCCLockingInterceptor.handleClearDataCommand(MVCCLockingInterceptor.java:124)
at org.jboss.cache.interceptors.base.PrePostProcessingCommandInterceptor.visitClearDataCommand(PrePostProcessingCommandInterceptor.java:167)
at org.jboss.cache.commands.write.ClearDataCommand.acceptVisitor(ClearDataCommand.java:86)
at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.jboss.cache.interceptors.ReplicationInterceptor.handleCrudMethod(ReplicationInterceptor.java:150)
at org.jboss.cache.interceptors.ReplicationInterceptor.visitClearDataCommand(ReplicationInterceptor.java:137)
at org.jboss.cache.commands.write.ClearDataCommand.acceptVisitor(ClearDataCommand.java:86)
at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131)
at org.jboss.cache.commands.AbstractVisitor.visitClearDataCommand(AbstractVisitor.java:80)
at org.jboss.cache.commands.write.ClearDataCommand.acceptVisitor(ClearDataCommand.java:86)
at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.jboss.cache.interceptors.TxInterceptor.replayModifications(TxInterceptor.java:501)
at org.jboss.cache.interceptors.TxInterceptor.handleRemotePrepare(TxInterceptor.java:388)
at org.jboss.cache.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:134)
at org.jboss.cache.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:68)
at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131)
at org.jboss.cache.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:140)
at org.jboss.cache.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:68)
at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.jboss.cache.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:178)
at org.jboss.cache.interceptors.InvocationContextInterceptor.visitPrepareCommand(InvocationContextInterceptor.java:106)
at org.jboss.cache.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:68)
at org.jboss.cache.interceptors.InterceptorChain.invokeRemote(InterceptorChain.java:316)
at org.jboss.cache.commands.remote.ReplicateCommand.processSingleCommand(ReplicateCommand.java:139)
at org.jboss.cache.commands.remote.ReplicateCommand.perform(ReplicateCommand.java:115)
at org.jboss.cache.marshall.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:319)
at org.jboss.cache.marshall.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:246)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:637)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:545)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:368)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:775)
at org.jgroups.JChannel.up(JChannel.java:1336)
at org.jgroups.mux.Multiplexer$Task.run(Multiplexer.java:1185)
at org.jgroups.mux.Multiplexer$ExecuteTask.run(Multiplexer.java:1208)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
We found out about this while doing more extensive QA on GateIn:
https://jira.jboss.org/jira/browse/GTNPORTAL-855 https://jira.jboss.org/jira/browse/GTNPORTAL-855
The code returning the NPE is simply:
public void clearDataDirect()
{
node.clear();
}
Looks like a bug, if you confirm I can create the Jira
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/538849#538849]
Start a new discussion in JBoss Cache at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
Re: [jboss-user] [jBPM] - jBPM 4 is dead?
by eric schabell
eric schabell [http://community.jboss.org/people/eschabell] replied to the discussion
"jBPM 4 is dead?"
To view the discussion, visit: http://community.jboss.org/message/538847#538847
--------------------------------------------------------------
Mark,
Red Hat has always been clear on jBPM 4, it is and never has reach any state that was ever considered for inclusion in her products. I have mentioned this before to more than one member of the community here.
The JBoss SOA-P product has always been the entry point for a supported release of jBPM. True, it used to be possible to have framework support on only jBPM, but it was always for the versions included in the JBoss SOA-P product. These are the ones that made it through Red Hat's QA, testing and integration process. Finally, it was decided to only provide support for jBPM through a JBoss SOA-P subscription.
Any member of Red Hat asked with regards to sales support of jBPM 4 should have always told you that support is possible for jBPM v3.2.x (depending on time frame, but this is the only supported branch for some time now), and for 5 years for each release.
It seems to me that it is up to the community to take a project in any direction it so desires. This is no different for jBPM.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/538847#538847]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
Re: [jboss-user] [JCA Development] - JcaXAResourceRecovery
by Jesper Pedersen
Jesper Pedersen [http://community.jboss.org/people/jesper.pedersen] replied to the discussion
"JcaXAResourceRecovery"
To view the discussion, visit: http://community.jboss.org/message/538845#538845
--------------------------------------------------------------
[14:07] <jpederse> asaldhan: so can I pass a null string as securityDomainName to createSecurityContext ?
[14:07] <asaldhan> jpederse: pass any dummy
[14:08] <jpederse> asaldhan: k, but I''m not seeing any setPrincipal() / setCredential() on SubjectInfo
[14:09] <asaldhan> jpederse: did u set it on SecurityContextAssociation?
[14:10] <jpederse> asaldhan: how ? It only takes the SecurityContext
[14:11] <jpederse> asaldhan: also; do I need the SecurityContextAssociation part at all ? I just need the Subject as a local variable
[14:11] <jpederse> asaldhan: this is not run in a context of something
[14:12] <jpederse> asaldhan: Its "ManagedConnection mc = mcf.createManagedConnection(subject, null)"
[14:14] <asaldhan> jpederse: but the creation of subject has to go through authentication. So at that time, the subjectfactory will look at the SCA for the latest SC and picks username/cred from there. After you have the subject, u then pass it to MCF
[14:14] <asaldhan> jpederse: so u need to do the SCA/SC/princ/cred
[14:15] <jpederse> asaldhan: k, then I just need to find the place where I input my username and password strings
[14:16] <jpederse> asaldhan: as the securityDomainName is null
[14:16] <asaldhan> jpederse: I have told u the sequence, I think u will have to figure out where to do the necessary things. The SDN should not be null. U r probably doing it wrong someplace
[14:17] <jpederse> asaldhan: look at my latest post - there isn't a security-domain configured in the -ds.xml
[14:17] <asaldhan> jpederse: there are two pieces: security to check whether u can create a subject. Once u have a subject, u pass it to the MCF. The MCF deals with the EIS.
[14:17] <jpederse> asaldhan: that is the common case for AS
[14:18] <asaldhan> jpederse: in that case, it probably just defaults to "other"
[14:18] <jpederse> asaldhan: yes, and I need the create the Subject - based on the information from the two use-cases
[14:18] <jpederse> asaldhan: I'm not talking about application-policy's
[14:18] <asaldhan> jpederse: if u have the AS setup, try debugging and seeing what the SD is for the case when -ds.xml does not have SD.
[14:18] <asaldhan> jpederse: the security domain translates to app policy
[14:19] <asaldhan> jpederse: SD = app policy defs
[14:19] <jpederse> asaldhan: yeah, I know - so it is probably the "other" case
[14:19] <asaldhan> jpederse: best is to debug the classic ds.xml usecases.[14:20] <jpederse> asaldhan: yeah, that would be the next thing
[14:21] <jpederse> asaldhan: and what about the principal / credential case ? I need to plug them in where ?
[14:22] <asaldhan> jpederse: dont know how the current ds setup does it.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/538845#538845]
Start a new discussion in JCA Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
[JBoss Web Services] - Provider based service
by Mike Finn
Mike Finn [http://community.jboss.org/people/mikefinnx] created the discussion
"Provider based service"
To view the discussion, visit: http://community.jboss.org/message/538844#538844
--------------------------------------------------------------
Trying to deploy top-down provider based service to AS 5.1.0 (I am down to a trivial sample). The app seems to deploy OK, and jbossws services listing shows it. However, the WSDL URL listed does not work (404), nor does the endpoint shown in the generated WSDL (404).
Steps-
1. New EAR + Web project, named: EchoServiceApp, EchoServiceWeb
2. Write WSDL - simple echo service (see below). Place in WEB-INF
3. Build provider class (see below for src)
4. Write web.xml (see below for src)
5. Deploy. Following shows in log:
14:18:30,077 INFO [TomcatDeployment] deploy, ctxPath=/EchoServiceWeb
14:18:30,217 INFO [WSDLFilePublisher] WSDL published to: file:/C:/apps/jboss/jboss-5.1.0.GA/server/standard/data/wsdl/EchoServiceApp.ear/EchoServiceWeb.war/echo.wsdl
6. Look at JBossWS con. Service listing shows:
| Endpoint Name | jboss.ws:context=EchoServiceApp-EchoServiceWeb,endpoint=Endpoint |
| Endpoint Address | http://localhost:8080/EchoServiceApp-EchoServiceWeb?wsdl |
7. Try to access Endpoint Address in browser, with and without "?wsdl". HTTP 404.
8. Load WSDL from file above into test tool (SOAPUI in this case). Endpoint address from WSDL matches above.
9. Invoke service, results in HTTP404 error message.
I cannot figure out where JBossWS is ACTUALLY mounting the endpoint to. Any ideas?
TIA,
Mike
EchoProvider.java
package echo;
import javax.xml.soap.SOAPMessage;
import javax.xml.ws.Provider;
import javax.xml.ws.ServiceMode;
import javax.xml.ws.WebServiceProvider;
@WebServiceProvider(portName = "EchoPort", serviceName = "EchoService", targetNamespace = "http://echo/", wsdlLocation = "WEB-INF/echo.wsdl")
@ServiceMode(value = javax.xml.ws.Service.Mode.MESSAGE)
public class EchoProvider implements Provider<SOAPMessage> {
@Override
public SOAPMessage invoke(SOAPMessage rqst) {
System.out.println("invoke()");
return rqst;
}
}
echo.wsdl:
<?xml version="1.0" encoding="UTF-8"?>
<definitions name='EchoService' targetNamespace='http://echo/'
xmlns='http://schemas.xmlsoap.org/wsdl/' xmlns:soap='http://schemas.xmlsoap.org/wsdl/soap/'
xmlns:tns='http://echo/' xmlns:xsd='http://www.w3.org/2001/XMLSchema'>
<types>
<xs:schema targetNamespace='http://echo/' version='1.0'
xmlns:tns='http://echo/' xmlns:xs='http://www.w3.org/2001/XMLSchema'>
<xs:element name='echo' type='tns:echo' />
<xs:element name='echoResponse' type='tns:echoResponse' />
<xs:complexType name='echo'>
<xs:sequence>
<xs:element minOccurs='0' name='arg0' type='xs:string' />
</xs:sequence>
</xs:complexType>
<xs:complexType name='echoResponse'>
<xs:sequence>
<xs:element minOccurs='0' name='return' type='xs:string' />
</xs:sequence>
</xs:complexType>
</xs:schema>
</types>
<message name='EchoMessage'>
<part element='tns:echo' name='echo' />
</message>
<message name='EchoResponseMessage'>
<part element='tns:echoResponse' name='echoResponse' />
</message>
<portType name='Echo'>
<operation name='echo' parameterOrder='echo'>
<input message='tns:EchoMessage' />
<output message='tns:EchoResponseMessage' />
</operation>
</portType>
<binding name='EchoBinding' type='tns:Echo'>
<soap:binding style='document'
transport='http://schemas.xmlsoap.org/soap/http' />
<operation name='echo'>
<soap:operation soapAction='' />
<input>
<soap:body use='literal' />
</input>
<output>
<soap:body use='literal' />
</output>
</operation>
</binding>
<service name='EchoService'>
<port binding='tns:EchoBinding' name='EchoPort'>
<soap:address location='REPLACE_WITH_ACTUAL_URL' />
</port>
</service>
</definitions>
web.xml
<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_ID" version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
<servlet>
<servlet-name>Endpoint</servlet-name>
<servlet-class>echo.EchoProvider</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Endpoint</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
</web-app>
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/538844#538844]
Start a new discussion in JBoss Web Services at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
Re: [jboss-user] [jBPM Development] - Mail template for custom MailProducer
by Alejandro Guizar
Alejandro Guizar [http://community.jboss.org/people/alex.guizar%40jboss.com] replied to the discussion
"Mail template for custom MailProducer"
To view the discussion, visit: http://community.jboss.org/message/538838#538838
--------------------------------------------------------------
> By the way, most user only create create a custom MailProducer to bypass the requirement of the default MailProducerImpl that mail recepients need to exist in the Indentity tables.
>
> ~~~~~~
> List<User> users = identitySession.findUsersById(userIds);
> ~~~~~
>
> Don't quite understand that, especially if I want the workflow to trigger an email to an external customer.
The code you indicate is guarded by a condition:
String userList = fromTemplate.getUsers();
if (userList != null) {
String[] userIds = tokenizeActors(userList, execution);
List<User> users = identitySession.findUsersById(userIds);
email.addFrom(resolveAddresses(users, addressResolver));
}
If you don't need users and groups from the identity tables, your template should only specify the *addresses* attribute to enumerate recipients. Avoiding the *users* and *groups* attributes also prevents access to the identity session. However, since you have looked at the source code you probably knew this already - am I missing something?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/538838#538838]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
Re: [jboss-user] [jBPM] - jBPM 4 is dead?
by Manuel Jordan
Manuel Jordan [http://community.jboss.org/people/dr_pompeii] replied to the discussion
"jBPM 4 is dead?"
To view the discussion, visit: http://community.jboss.org/message/538834#538834
--------------------------------------------------------------
Hello Sebastian
Thanks for the reply
> The graphical process designer is a subproject and do not expect it to be finished in 4.4
OK, but please resolve my doubt, since GPD has not all features yet like previous release, In a good sense
Must I configure by hand in *source* tab pane my jpdl requeriments that I can't do by *properties* window approach?
> You're welcome to join the discussion on the mailing list
Sounds great, can you provide me the link to join me?, mostly what kind of discussion cover such list?
> At the moment there is the idea to even aim for support for a couple of dependency frameworks (*Spring*
I think that is wise have integration with Spring, both frameworks are powerful
Best Regards!
-Manuel
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/538834#538834]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years