[jBPM Users] - Duplicate KEYs/Indexes on JBPM tables
by jeckles933
JBPM 3.2.6 SP 1
MYSQL 5.0.51a-log
Most of the tables have duplicate keys, this is just one example
CREATE TABLE `jbpm_token` (
`ID_` BIGINT(20) NOT NULL AUTO_INCREMENT,
`VERSION_` INT(11) NOT NULL,
`NAME_` VARCHAR(255) DEFAULT NULL,
`START_` DATETIME DEFAULT NULL,
`END_` DATETIME DEFAULT NULL,
`NODEENTER_` DATETIME DEFAULT NULL,
`NEXTLOGINDEX_` INT(11) DEFAULT NULL,
`ISABLETOREACTIVATEPARENT_` BIT(1) DEFAULT NULL,
`ISTERMINATIONIMPLICIT_` BIT(1) DEFAULT NULL,
`ISSUSPENDED_` BIT(1) DEFAULT NULL,
`LOCK_` VARCHAR(255) DEFAULT NULL,
`NODE_` BIGINT(20) DEFAULT NULL,
`PROCESSINSTANCE_` BIGINT(20) DEFAULT NULL,
`PARENT_` BIGINT(20) DEFAULT NULL,
`SUBPROCESSINSTANCE_` BIGINT(20) DEFAULT NULL,
PRIMARY KEY (`ID_`),
KEY `IDX_TOKEN_PARENT` (`PARENT_`),
KEY `IDX_TOKEN_PROCIN` (`PROCESSINSTANCE_`),
KEY `IDX_TOKEN_NODE` (`NODE_`),
KEY `IDX_TOKEN_SUBPI` (`SUBPROCESSINSTANCE_`),
KEY `FK_TOKEN_SUBPI` (`SUBPROCESSINSTANCE_`),
KEY `FK_TOKEN_PROCINST` (`PROCESSINSTANCE_`),
KEY `FK_TOKEN_NODE` (`NODE_`),
KEY `FK_TOKEN_PARENT` (`PARENT_`),
CONSTRAINT `FK_TOKEN_NODE` FOREIGN KEY (`NODE_`) REFERENCES `jbpm_node` (`ID_`),
CONSTRAINT `FK_TOKEN_PARENT` FOREIGN KEY (`PARENT_`) REFERENCES `jbpm_token` (`ID_`),
CONSTRAINT `FK_TOKEN_PROCINST` FOREIGN KEY (`PROCESSINSTANCE_`) REFERENCES `jbpm_processinstance` (`ID_`),
CONSTRAINT `FK_TOKEN_SUBPI` FOREIGN KEY (`SUBPROCESSINSTANCE_`) REFERENCES `jbpm_processinstance` (`ID_`)
) ENGINE=INNODB DEFAULT CHARSET=latin1
Note these Keys:
KEY `IDX_TOKEN_PARENT` (`PARENT_`),
KEY `FK_TOKEN_PARENT` (`PARENT_`),
This is just one example, there are duplicate keys on almost all the tables.
This table was created using the script that came with 3.2.6 SP1.
Is there a reason for these duplicate keys??
Or is this a bug in the DB create script?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261117#4261117
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261117
16 years, 8 months
[Clustering] - Re: JGroups timing call inomalities
by bstansberry＠jboss.com
"axelerator" wrote : Hi Brian,
|
| thanks. That's a good lookout. Also I tested the setup and AS started without any itches and behaved pretty much normally.
| What I'm nevertheless a bit curious about is the use of synchronous RPC calls (callMethodOnCoordinator) with regards to performance and timings.
| Since we only use this method here, I'm a bit worried that that's not the "preferred" way to interact. Can you confirm that?
I wouldn't say it's not preferred. Historically a lot of JGroups use cases have been point-to-multipoint(e.g. callMethodOnCluster if done via HAPartition), but there is quite a bit of point-to-point usage as well (e.g. JBoss Cache buddy replication.) You use what meets the requirement of your application.
anonymous wrote :
| I ask because as far as I know, callMethodOnCoordinator does use JGroups to actually get the master server. Since we only have timings here (especially if there are a lot of calls requesting the same object) by seeing a lot of threads in collectResponse I'm quite curious.
The part of figuring out who the coordinator node is is quite lightweight.
Do you have large numbers of concurrent calls to the same service from each node? Those are going to be executed serially, since JGroups will only allow one RPC at a time from a given sender to be executing in the application.
anonymous wrote :
| Also, does the JIRA ticket with regards to a AtomicBoolan instead of a ReentrantLock come into play if there are a lot the same calls around?
Please provide a link to the JIRA you are talking about.
Best regards,
Axelerator
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261112#4261112
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261112
16 years, 8 months
[Clustering] - Re: JGroups timing call inomalities
by axelerator
Hi Brian,
thanks. That's a good lookout. Also I tested the setup and AS started without any itches and behaved pretty much normally.
What I'm nevertheless a bit curious about is the use of synchronous RPC calls (callMethodOnCoordinator) with regards to performance and timings.
Since we only use this method here, I'm a bit worried that that's not the "preferred" way to interact. Can you confirm that?
I ask because as far as I know, callMethodOnCoordinator does use JGroups to actually get the master server. Since we only have timings here (especially if there are a lot of calls requesting the same object) by seeing a lot of threads in collectResponse I'm quite curious.
Also, does the JIRA ticket with regards to a AtomicBoolan instead of a ReentrantLock come into play if there are a lot the same calls around?
Best regards,
Axelerator
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261110#4261110
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261110
16 years, 8 months
[JCA] - Re: ClassNotFoundException when moving JCA adaptor from 4.2.
by pwnell
I get this:
| net.za.pwnconsulting.logmon.rar.cci.data.client.LogMessage Information
| Not loaded in repository cache
|
I know my RAR is loaded:
| name='LogMonJCA.rar',service=RARDeployment
|
and as you can see LogMessage is indeed inside the RAR archive:
| root@waldopc:/opt/jboss-5.1.0.GA/bin# jar -tf ../server/default/deploy/LogMonJCA.rar | grep LogMessage
| net/za/pwnconsulting/logmon/rar/cci/data/client/LogMessage.class
|
Some additional info:
java2ClassLoadingCompliance = false
WarClassLoaderDeployer not commented out
I do not have WEB-INF/jboss-classloading.xml files.
I *do* make use of jboss-app.xml files - in the RAR and in the ear. In the RAR file:
| <jboss-app>
| <loader-repository>
| dot.com:loader=LogMonJCA
| <loader-repository-config>
| java2ParentDelegation=false
| </loader-repository-config>
| </loader-repository>
| </jboss-app>
|
In the ear file:
| <jboss-app>
| <loader-repository>
| dot.com:loader=LogMonConsole
| <loader-repository-config>
| java2ParentDelegation=false
| </loader-repository-config>
| </loader-repository>
| </jboss-app>
|
Not sure if these are the cause of the problem but I have always used it like this and it used to work just fine.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261107#4261107
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261107
16 years, 8 months
[jBPM Users] - Re: Catching invalid transition names in jBPM4
by sebastian.s
Honestly I can't answer your last question. But what about just trying to call execution.take(transitionName) and catching the exception in case of an invalid name?
anonymous wrote :
| void take(java.lang.String transitionName)
|
| takes the outgoing transition with the given name.
|
| This method can only be called from inside ExternalActivityBehaviour implementations.
|
| Transitions will be looked up recursively starting from the current activity and then up the activity-parent-hierarchy
|
| Parameters:
| transitionName - is the name of the transition to take. A null value will match the first unnamed transition.
| Throws:
| JbpmException - in case no such transition is found in the current activity or in case this method is called from inside an ActivityBehaviour.
|
|
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261104#4261104
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261104
16 years, 8 months
[jBPM Users] - Re: Catching invalid transition names in jBPM4
by bwestrich
Interesting to know that signal names have such flexibility. And I can imagine situations where that might be useful.
However, the way I've used jBPM 3.2.3, if I send a process instance a signal, I expect the signal to cause a transition (even if the transition is to the same state). So I add validation code between the client and the executing business process that notifies the client if they pass in a signal which is not a valid transition (and thus will not cause a transition).
I think I just figured out a way of doing such a validation using 4.x: Cast the Execution (interface) to an ExecutionImpl, call getActivity() to get the ActivityImpl, then call findOutgoingTransition(String name). If findOutgoingTransition returns a null, the transition is not valid. The below code shows this approach, as well as a way to list all valid transitions.
public class FirstEnterHandler implements ExternalActivityBehaviour {
| public void execute(ActivityExecution execution) throws Exception {
| String transitionName = "byListener?";
| ExecutionImpl executionImpl = (ExecutionImpl) execution;
| ActivityImpl activity = executionImpl.getActivity();
| TransitionImpl transition = activity.findOutgoingTransition(transitionName);
| if (transition == null) {
| String validTrans = activity.getOutgoingTransitions().toString();
| throw new RuntimeException("invalid transition " + transitionName
| + ", valid transitions are : " + validTrans);
| }
| execution.take(transitionName);
| }
| }
Even if this code works, it seems like a lot of use of internal implementation classes. Is this approach an ok way to validate signal names?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261101#4261101
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261101
16 years, 8 months
[Clustering] - Cluster invocation error
by mohitanchlia
We have stateless bean which is clustered. We have more than 8 nodes in a cluster and that bean is supposed to be clustered accross 8 nodes. Problem is that when one of the nodes is in process of going down for maintenance then the user request fails while connecting that node. What I don't understand is why would user requests fail when the bean is supposed to be clustered? Shouldn't the proxy object go to the next node in the cluster and process the request instead of returning an error?
| Caused by: java.lang.RuntimeException: cluster invocation failed, last exception was:
| at org.jboss.aspects.remoting.ClusterChooserInterceptor.invoke(ClusterChooserInterceptor.java:166)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:53)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.remoting.ClusteredIsLocalInterceptor.invoke(ClusteredIsLocalInterceptor.java:55)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.stateless.StatelessClusteredProxy.invoke(StatelessClusteredProxy.java:112)
| at $Proxy284.findFilingsByCmTokenId(Unknown Source)
| ... 61 more
| Caused by: org.jboss.remoting.CannotConnectException: Can not get connection to server. Problem establishing socket connection for InvokerLocator [socket://10.4.2.37:3873/?numberOfRetries=1]
| at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:532)
| at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
| at org.jboss.remoting.Client.invoke(Client.java:1634)
| at org.jboss.remoting.Client.invoke(Client.java:548)
| at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.remoting.ClusterChooserInterceptor.invoke(ClusterChooserInterceptor.java:77)
| ... 70 more
| Caused by: java.net.ConnectException: Connection refused
| at java.net.PlainSocketImpl.socketConnect(Native Method)
| at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
| at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
| at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
| at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
| at java.net.Socket.connect(Socket.java:516)
| at org.jboss.remoting.transport.socket.SocketClientInvoker.createSocket(SocketClientInvoker.java:187)
| at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.getConnection(MicroSocketClientInvoker.java:815)
| at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:525)
| at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
| at org.jboss.remoting.Client.invoke(Client.java:1634)
| at org.jboss.remoting.Client.invoke(Client.java:548)
| at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.remoting.ClusterChooserInterceptor.invoke(ClusterChooserInterceptor.java:77)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:53)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.remoting.ClusteredIsLocalInterceptor.invoke(ClusteredIsLocalInterceptor.java:55)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.stateless.StatelessClusteredProxy.invoke(StatelessClusteredProxy.java:112)
| at $Proxy284.findFilingsByCmTokenId(Unknown Source)
| at sun.reflect.GeneratedMethodAccessor174.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at com.intuit.engine.efp.efe.filer.FilingProcessorDelegate$FilingProcessorFipProxy.invoke(FilingProcessorDelegate.java:246)
| at $Proxy285.findFilingsByCmTokenId(Unknown Source)
| at com.intuit.engine.efp.efe.filer.FilingProcessorDelegate.findFilingsByCmTokenId(FilingProcessorDelegate.java:120)
| at com.intuit.engine.efp.efe.filer.FipFilerStrategy.sync(FipFilerStrategy.java:529)
| at com.intuit.engine.efp.efe.filer.server.common.FilerService.sync(FilerService.java:222)
| at sun.reflect.GeneratedMethodAccessor173.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at com.sun.xml.ws.api.server.InstanceResolver$1.invoke(InstanceResolver.java:246)
| at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:146)
| at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:257)
| at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:93)
| at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:598)
| at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:557)
| at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:542)
| at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:439)
| at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:243)
| at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:470)
| at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
| at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135)
| at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doGet(WSServletDelegate.java:129)
| at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doPost(WSServletDelegate.java:160)
| at com.sun.xml.ws.transport.http.servlet.WSServlet.doPost(WSServlet.java:75)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at com.intuit.engine.efp.efe.filer.filters.servlet.EmptyRespElementFilter.doFilter(EmptyRespElementFilter.java:73)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at com.intuit.engine.efp.efe.filer.filters.servlet.FixPortFilter.doFilter(FixPortFilter.java:68)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at com.intuit.engine.efp.efe.filer.filters.servlet.ClientAppVerifyFilter.doFilter(ClientAppVerifyFilter.java:74)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at com.intuit.engine.efp.efe.filer.filters.servlet.ValidatorFilter.doFilter(ValidatorFilter.java:269)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at com.intuit.engine.efp.efe.filer.filters.servlet.ExtractPayloadFilter.doFilter(ExtractPayloadFilter.java:90)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
| 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:230)
| at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
| at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
| at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
| at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
| at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
| at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
| at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
| at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
| at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:437)
| at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:381)
| at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:451)
| at java.lang.Thread.run(Thread.java:595)
| at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:74)
| ... 72 more
|
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261099#4261099
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261099
16 years, 8 months
[JBoss Tools Users] - Re: Where is a
by rob.stryker＠jboss.com
As for what "publish" does, some people run with the automatic publishing NOT enabled. This means when they make changes to their workspace, they do NOT publish the changes right away. These users love being in control of when the publish occurs, and prefer to have the button there to do it.
What the "publish" button does is initiate an incremental publish. If you already have automatic publishing turned on, then clicking the publish button likely won't do anything because by the time you click it, an automatic publish has probably already happened and the workspace is already in sync with the publish folder.
But for users who don't have automatic publishing turned on, clicking publish initiates this incremental change. So if you change 10 files with auto-publish turned off, you'll see nothing changes in your deploy folder, but the "resynchronize" is shown in the view, showing you they are not in sync right then.
Then you click publish, and those 10 files are published =]
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261098#4261098
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261098
16 years, 8 months
[JBoss Tools Users] - Re: Where is a
by rob.stryker＠jboss.com
Hmm... I'm not sure when they added 'clean' so I don't think it was there when I 'forked', but honestly, the history of the JBoss Servers View was that it was a Common Navigator based view. At the time of the fork, the official "Servers View" was not common navigator based but was rather a static view that could not be added to at all.
I later contributed a large base of code back to eclipse to convert their view to an extensible Common Navigator based view.
In all honesty what I *should* be working on now is removing the JBoss Servers View entirely and adding the extra actions which we have to their view. But I can add the clean action to my view temporarily until I get around to removing the JBoss Servers View entirely =] I should make some JIRAs for myself.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261096#4261096
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261096
16 years, 8 months