[jBPM Users] - Re: [jBPM4] Synchronous process execution
by kukeltje
you call it a process, I call it a micro-flow... or orchestration or... what's in a name. You could also you bpel or something else for this.
>From a nice article:
anonymous wrote : I already have a service execution pipeline, why do I need additional service orchestration mechanisms?
|
| It might seem that that there is a lot of overlap between a service pipeline and service orchestration. In a nutshell, a service pipeline is a sequential orchestration of actions. The things that it does not support well, but are common orchestration requirements, are decisions, conditional transitions and parallel execution. Although technically you can do a lot these things as part of pipeline definition, it's not always easy. Our preference is to use a service pipeline for bringing together basic business functionality and additional infrastructure support, including data transformation, execution monitoring, etc and use jBPM for orchestration of these services.
|
| Additional consideration for this choice can be deployment requirements. If the same action(s) is used in a lot of cases, it might make sense to separate it (them) into a separate service so that it will be deployed only once and use jBPM for orchestration.
The full article is an interesting read, but yes, it still is debatable.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261150#4261150
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261150
16 years, 10 months
[JBoss Messaging Users] - Topic Listener MDB problems
by JBossBorot
MDB doesn't seem to connect to JMS Topic, message posted by j2se client to JMS Topic doesn't seem to show in Topic stats.
Setup: WinXP, JBoss 5.1, Eclipse Galileo, JDK 1.6.
JBoss setup seems to be functioning, as an EJB app has deployed and was tested just fine.
@MessageDriven(activationConfig = {
@ActivationConfigProperty(
propertyName = "destinationType",
propertyValue = "javax.jms.Topic") },
mappedName = "JMSTopic1",
name="TopicMDB1")
public class TopicMDB1 implements MessageDrivenBean, MessageListener {...}
Using Eclipse JEE plugin, the MDB is added to an EAR proj, which is then "deployed" {Run} on JBoss.
The deployment seems to conclude without errors, but there are no signs of the bean anywhere.
A j2se test client puts a simple text msg to the Topic, but there's no sign of that msg either in the JMS system, nor is it being consumed by anybody {obviously}.
I am a noob to JBoss, but have done this in Weblogic many times, if that counts for anything.
Any suggestions would be welcome.
karoy
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261148#4261148
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261148
16 years, 10 months
[JBoss Web Services Users] - JBoss 5.0.1/5.1.0: java.lang.UnsupportedOperationException:
by andersoj
Hi there,
While calling a web service deployed on JBoss 5.0.1 (and 5.1.0) I get the following server side error:
22:40:21,309 ERROR [SOAPFaultHelperJAXWS] SOAP request exception
| java.lang.UnsupportedOperationException: setProperty must be overridden by all subclasses of SOAPMessage
| at javax.xml.soap.SOAPMessage.setProperty(SOAPMessage.java:441)
| at org.jboss.ws.core.soap.SOAPMessageImpl.<init>(SOAPMessageImpl.java:87)
| at org.jboss.ws.core.soap.MessageFactoryImpl.createMessage(MessageFactoryImpl.java:215)
| at org.jboss.ws.core.soap.MessageFactoryImpl.createMessage(MessageFactoryImpl.java:193)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.processRequest(RequestHandlerImpl.java:455)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleRequest(RequestHandlerImpl.java:295)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.doPost(RequestHandlerImpl.java:205)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:131)
| at org.jboss.wsf.common.servlet.AbstractEndpointServlet.service(AbstractEndpointServlet.java:85)
| 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:829)
| at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
| at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
| at java.lang.Thread.run(Thread.java:619)
| 22:40:21,310 ERROR [RequestHandlerImpl] Error processing web service request
| org.jboss.ws.WSException: java.lang.UnsupportedOperationException: setProperty must be overridden by all subclasses of SOAPMessage
| at org.jboss.ws.WSException.rethrow(WSException.java:68)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleRequest(RequestHandlerImpl.java:336)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.doPost(RequestHandlerImpl.java:205)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:131)
| at org.jboss.wsf.common.servlet.AbstractEndpointServlet.service(AbstractEndpointServlet.java:85)
| 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:829)
| at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
| at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
| at java.lang.Thread.run(Thread.java:619)
| Caused by: java.lang.UnsupportedOperationException: setProperty must be overridden by all subclasses of SOAPMessage
| at javax.xml.soap.SOAPMessage.setProperty(SOAPMessage.java:441)
| at org.jboss.ws.core.soap.SOAPMessageImpl.<init>(SOAPMessageImpl.java:87)
| at org.jboss.ws.core.soap.MessageFactoryImpl.createMessage(MessageFactoryImpl.java:169)
| at org.jboss.ws.core.jaxws.SOAPFaultHelperJAXWS.createSOAPMessage(SOAPFaultHelperJAXWS.java:295)
| at org.jboss.ws.core.jaxws.SOAPFaultHelperJAXWS.toSOAPMessage(SOAPFaultHelperJAXWS.java:256)
| at org.jboss.ws.core.jaxws.SOAPFaultHelperJAXWS.exceptionToFaultMessage(SOAPFaultHelperJAXWS.java:187)
| at org.jboss.ws.core.jaxws.binding.SOAP11BindingJAXWS.createFaultMessageFromException(SOAP11BindingJAXWS.java:102)
| at org.jboss.ws.core.CommonSOAPBinding.bindFaultMessage(CommonSOAPBinding.java:671)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.processRequest(RequestHandlerImpl.java:496)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleRequest(RequestHandlerImpl.java:295)
| ... 24 more
| 22:40:21,310 ERROR [[Xmir]] Servlet.service() for servlet Xmir threw exception
| java.lang.UnsupportedOperationException: setProperty must be overridden by all subclasses of SOAPMessage
| at javax.xml.soap.SOAPMessage.setProperty(SOAPMessage.java:441)
| at org.jboss.ws.core.soap.SOAPMessageImpl.<init>(SOAPMessageImpl.java:87)
| at org.jboss.ws.core.soap.MessageFactoryImpl.createMessage(MessageFactoryImpl.java:169)
| at org.jboss.ws.core.jaxws.SOAPFaultHelperJAXWS.createSOAPMessage(SOAPFaultHelperJAXWS.java:295)
| at org.jboss.ws.core.jaxws.SOAPFaultHelperJAXWS.toSOAPMessage(SOAPFaultHelperJAXWS.java:256)
| at org.jboss.ws.core.jaxws.SOAPFaultHelperJAXWS.exceptionToFaultMessage(SOAPFaultHelperJAXWS.java:187)
| at org.jboss.ws.core.jaxws.binding.SOAP11BindingJAXWS.createFaultMessageFromException(SOAP11BindingJAXWS.java:102)
| at org.jboss.ws.core.CommonSOAPBinding.bindFaultMessage(CommonSOAPBinding.java:671)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.processRequest(RequestHandlerImpl.java:496)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleRequest(RequestHandlerImpl.java:295)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.doPost(RequestHandlerImpl.java:205)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:131)
| at org.jboss.wsf.common.servlet.AbstractEndpointServlet.service(AbstractEndpointServlet.java:85)
| 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:829)
| at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
| at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
| at java.lang.Thread.run(Thread.java:619)
Could someone please help me to find out how to solve this?
Misc info:
OS: FreeBSD 7.1
Java:
java version "1.6.0_07"
Diablo Java(TM) SE Runtime Environment (build 1.6.0_07-b02)
Diablo Java HotSpot(TM) 64-Bit Server VM (build 10.0-b23, mixed mode)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261144#4261144
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261144
16 years, 10 months
[Clustering] - Re: JGroups timing call inomalities
by bstansberry＠jboss.com
JGroups is only going to allow one message at a time from a particular sender to proceed up the stack past UNICAST. This is needed to ensure message are delivered in order. So, only one RPC at a time.
There's a JGroups JIRA to add an API whereby the application can define the scope to which message ordering is applied; e.g. your app could say all messages associated with "LockA" must be ordered, but a message associated with "LockB" wouldn't have to wait for "LockA" messages. But that won't be in JGroups 2.6.
How long does these RPCs take once the RPC is actually invoked on the coordinator? That's what's going to drive your throughput since the RPCs execute in series. Ah, you said 90ms, although AIUI that was for a remote client to get a response, so the actual server-side execution time is probably much less.
Worst case, lets assume it's 90ms. Your max throughput would be ~ 11 per second. If you are only executing 1 or 2 per second, serializing the execution shouldn't be adding more than an extra 90 ms delay to one RPC, and often wouldn't delay it at all.
The key thing here is the execution time of the RPC. With JBoss AS HTTP session replication, the same basic serialization of RPCs occurs at the JGroups level. Yet we handle hundreds of concurrent requests per node and thousands of requests per second. That's because the execution time of the RPC itself is very low.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261136#4261136
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261136
16 years, 10 months
[Clustering] - Re: JGroups timing call inomalities
by axelerator
Hi Brian,
okay - that wasn't the most intelligent post ever. So, let's clear things up.
I have a service, which is active on all nodes in the cluster. Nevertheless, if the node a method of this service is invoked on, is not the master node, the call is relayed to that master node (callMethodOnCoordinator).
What happens is that the master-node service is called not too heavily, but concurrently 1-2 times/second (to do some mutual exclusive stuff).
Therefor, as far as I understand you, the method I use isn't the most intelligent way to do this, since I want multi-threaded access to this services, besides that the service handles semaphore access internally.
Does this mean does using JGroups/Jboss Clustering, I can call the same service on each node only sequentially, but not multi-threaded? If so .. what would be your suggestion on handling this issue? I ask because I expected that this remoting call can be handled in a parallel environment.
The JIRA case I was referring to, is https://jira.jboss.org/jira/browse/JGRP-829 .
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261129#4261129
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261129
16 years, 10 months
[EJB 3.0 Users] - Re: Client calls Timer only once
by jaikiran
"Fuchs" wrote :
| After some changes the Timer-Tutorial is running.
|
What changes did you do? The tutorials should not require any changes (maybe just the JBOSS_HOME stuff) to run correctly. So let us know of the changes you did, so that we can fix them (if they are some bugs) accordingly.
"Fuchs" wrote :
| Now, the Server-Methode should be called every fifth sec.
| In my Application it is only once called.
|
Can you post the logs on the console from both the client and server side? Please do *not* post the server.log. Just the console log should be fine.
"Fuchs" wrote :
| I also add the following Argument to the Client Application:
| Djava.naming.factory.initial=com.sun.jndi.cosnaming.CNCtxFactory
|
That shouldn't be added. Any specific reason you are adding that?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261125#4261125
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261125
16 years, 10 months