[JBoss JIRA] Created: (BPEL-282) Engine runs process instances in serie instead of in parallel
by Santiago Erquicia (JIRA)
Engine runs process instances in serie instead of in parallel
-------------------------------------------------------------
Key: BPEL-282
URL: http://jira.jboss.com/jira/browse/BPEL-282
Project: JBoss jBPM BPEL
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Engine
Affects Versions: jBPM BPEL 1.1 beta 3
Environment: RHEL
Reporter: Santiago Erquicia
Assigned To: Alejandro Guizar
We are stress testing a BPEL process and we found out that the engine runs all the requests it receives in serie. That means that if there are two or more concurrent users of the system, one has to wait till the first process instance stops at some point (wait state) so the other request can be processed.
On our test environment, we are calling a web service which is also calling another web service. The are connection problems with the second one, so from time to time the web service just times out. This means that a concurrent user has to wait for that time out, and whatever is left of that process instance, in order to be processed.
On our JMeter test, the throughput keeps stable even if there number of request is bigger than the throughput of the BPEL engine. The result is that the time for response of each process request increases indefinitely if the usage is bigger than the throughput. This obviously doesn't scale at all for the processing requirement we are considering.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 8 months
[JBoss JIRA] Created: (JBPM-958) Can't display the non-ISO8859-1 characters!
by David Chan (JIRA)
Can't display the non-ISO8859-1 characters!
-------------------------------------------
Key: JBPM-958
URL: http://jira.jboss.com/jira/browse/JBPM-958
Project: JBoss jBPM
Issue Type: Bug
Components: Web Interface
Affects Versions: jBPM jPDL 3.2
Environment: Windows XP Professional English
JDK 1.5
Eclipse 3.2.2
JPDL Suite 3.2 GA
Reporter: David Chan
Assigned To: Tom Baeyens
When I run the console application, log in as the user bert, then start the sample process websale, it display a form.
So I input some Chinese characters as task variable, see the attachment(JPG). After click the save button, what the input has been saved into database and page was rendered again, but the character displayed is not same as I just inputed.
Please see the second attachment(JPG), I really don't know how the strange character came out.
I also checked the page encoding, which is all UTF-8.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 8 months
[JBoss JIRA] Created: (JBCACHE-1164) NodeNotExistException with concurent put/remove operations
by Jacek Halat (JIRA)
NodeNotExistException with concurent put/remove operations
----------------------------------------------------------
Key: JBCACHE-1164
URL: http://jira.jboss.com/jira/browse/JBCACHE-1164
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: PojoCache
Affects Versions: 1.4.1.SP4
Environment: Windows XP, Sun jdk150_06
Reporter: Jacek Halat
Assigned To: Jason T. Greene
When 2 Threads are putting/removing data from this same node, put operation fails with exception
org.jboss.cache.NodeNotExistsException: node /a/b/c/d not found (gtx=GlobalTransaction::2, caller=Thread[Thread-0,5,main])
at org.jboss.cache.TreeCache._put(TreeCache.java:4618)
at org.jboss.cache.TreeCache._put(TreeCache.java:4579)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330)
at org.jboss.cache.interceptors.CallInterceptor.invoke(CallInterceptor.java:52)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:89)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
(...)
Thread 1 is calling:
cache.remove("/a/b/c/d");
cache.remove("/a");
Thread 2 is calling:
cache.putObject("/a/b/c/d", "text" + x);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 8 months
[JBoss JIRA] Created: (JGRP-603) FLUSH: problems with TCP and concurrent startup/shutdowns
by Bela Ban (JIRA)
FLUSH: problems with TCP and concurrent startup/shutdowns
---------------------------------------------------------
Key: JGRP-603
URL: http://jira.jboss.com/jira/browse/JGRP-603
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assigned To: Vladimir Blagojevic
The attached ZIP file has code that reproduces this.
Modify props.props (pf.cluster.transport.protocol=udp) to "tcp" and "tcp-nio" if you want to test the different stacks.
To reproduce:
- Start a number of instances (e.g. 5) concurrently. This almost never works, even under "udp". Joiners' JOIN requests time out and they have to retry (possibly because the coord is busy with the FLUSH protocol). They become singleton members and *never* merge !
- This works fine without FLUSH
- With "udp", it works almost always, with "tcp" it works 50% of the time, with "tcp-nio" is almost never works
- Randomly kill and restart instances
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 8 months
[JBoss JIRA] Created: (JBRULES-1310) java.lang.NullPointerException at org.drools.rule.builder.dialect.java.JavaConsequenceBuilder.build(JavaConsequenceBuilder.java:54)
by Shiva Shankar Reddy (JIRA)
java.lang.NullPointerException at org.drools.rule.builder.dialect.java.JavaConsequenceBuilder.build(JavaConsequenceBuilder.java:54)
-----------------------------------------------------------------------------------------------------------------------------------
Key: JBRULES-1310
URL: http://jira.jboss.com/jira/browse/JBRULES-1310
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Drl Parser/Builder
Affects Versions: 4.0.3
Environment: OS: Windows
hardware : Pentium Duo Core2,
Server: JBOSS4.X
Drools: 4.0.3
Reporter: Shiva Shankar Reddy
when i am using drools 3.x jars then rules are getting fired in a proper manner and working perfectly.
I have tried to migrate from 3.x to 4.0.3 then i am getting the following error.
I have tried changing jars and so on....
2007-10-31 16:20:48,120 ERROR [STDERR] java.lang.NullPointerException
2007-10-31 16:20:48,120 ERROR [STDERR] at org.drools.rule.builder.dialect.java.JavaConsequenceBuilder.build(JavaConsequenceBuilder.java:54)
2007-10-31 16:20:48,120 ERROR [STDERR] at org.drools.rule.builder.RuleBuilder.build(RuleBuilder.java:67)
2007-10-31 16:20:48,120 ERROR [STDERR] at org.drools.compiler.PackageBuilder.addRule(PackageBuilder.java:446)
2007-10-31 16:20:48,120 ERROR [STDERR] at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:304)
2007-10-31 16:20:48,120 ERROR [STDERR] at com.ess.framework.service.remote.rules.RulesEngineInvoker.readRule(RulesEngineInvoker.java :103)
2007-10-31 16:20:48,120 ERROR [STDERR] at com.ess.framework.service.RuleService.doProcess(RuleService.java:318)
2007-10-31 16:20:48,120 ERROR [STDERR] at com.ess.framework.service.FetchFSSData.invokeRuleService (FetchFSSData.java:140)
2007-10-31 16:20:48,120 ERROR [STDERR] at com.ess.framework.service.FetchFSSData.triggerData(FetchFSSData.java:68)
2007-10-31 16:20:48,120 ERROR [STDERR] at com.ess.framework.service.FetchFSSData$1.run (FetchFSSData.java:84)
2007-10-31 16:20:48,120 ERROR [STDERR] at java.util.TimerThread.mainLoop(Timer.java:512)
2007-10-31 16:20:48,120 ERROR [STDERR] at java.util.TimerThread.run(Timer.java:462)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 9 months
[JBoss JIRA] Created: (JBAS-3468) JMS Connection starts ping thread before ClientID is set resulting in the ClientMonitorInterceptor to close the connection after client timeout
by Francis Labaere (JIRA)
JMS Connection starts ping thread before ClientID is set resulting in the ClientMonitorInterceptor to close the connection after client timeout
-----------------------------------------------------------------------------------------------------------------------------------------------
Key: JBAS-3468
URL: http://jira.jboss.com/jira/browse/JBAS-3468
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JMS service
Affects Versions: JBossAS-4.0.2 Final
Environment: Windows XP
Reporter: Francis Labaere
Assigned To: Adrian Brock
Priority: Minor
Fix For: JBossAS-4.0.5.GA
When creating a JMS connection using HTTPConnectionFactory for a user without preconfigured ClientID, mq.Connection starts the ping thread before the ClientID of the Connection is set (explicitely using setClientID or implicitely). The ping thread starts pinging the server with ConnectionToken/@ClientID equal to null.
The ClientMonitorInterceptor adds this ConnectionToken to its clients HashMap. When the ClientID of the Connection is set (e.g. to XXX) later, the next call to the server will add the updated ConnectionToken to the ClientMonitorInterceptor's clients HashMap with the same SessionID as the previous one. When the ClientMonitorInterceptor checks timedout clients, it will close the session for the first ConnectionToken. Subsequent calls to the server will generate exceptions: User session is not valid.
On the JBoss server, the ClientMonitorInterceptor closes the client with ConnectionToken:null/0e9cae0c268a6d4aeb393f40552ce059
2006-08-04 11:53:12,261 DEBUG [org.jboss.mq.server.ClientMonitorInterceptor] Checking for timedout clients.
2006-08-04 11:53:12,261 DEBUG [org.jboss.mq.server.ClientMonitorInterceptor] Disconnecting client due to inactivity timeout: ConnectionToken:null/0e9cae0c268a6d4aeb393f40552ce059
2006-08-04 11:53:12,261 TRACE [org.jboss.mq.il.http.HTTPClientIL] close()
2006-08-04 11:53:12,261 TRACE [org.jboss.mq.il.http.HTTPClientILStorageQueue] getInstance()
2006-08-04 11:53:12,261 TRACE [org.jboss.mq.il.http.HTTPClientILStorageQueue] put(HTTPILRequest asynchClose(), String 105)
2006-08-04 11:53:12,261 DEBUG [org.jboss.mq.il.http.HTTPClientILStorageQueue] ClientIL #105 has existing storage queue, adding request to it.
Later (e.g. after sending a JMS message) the SecurityInterceptor checks the connection with the same sessionID ,but different ClientID: ConnectionToken:ID:4/0e9cae0c268a6d4aeb393f40552ce059 subId=-2147483648
2006-08-04 13:17:57,294 TRACE [org.jboss.mq.security.ServerSecurityInterceptor] Checking receive authorize on ConnectionToken:ID:4/0e9cae0c268a6d4aeb393f40552ce059 subId=-2147483648
2006-08-04 13:17:57,294 TRACE [org.jboss.mq.server.TracingInterceptor] EXCEPTION : receive:
javax.jms.JMSSecurityException: User session is not valid
at org.jboss.mq.security.SecurityManager.authorize(SecurityManager.java:230)
at org.jboss.mq.security.ServerSecurityInterceptor.authorizeRead(ServerSecurityInterceptor.java:233)
at org.jboss.mq.security.ServerSecurityInterceptor.receive(ServerSecurityInterceptor.java:98)
at org.jboss.mq.server.ClientMonitorInterceptor.receive(ClientMonitorInterceptor.java:231)
at org.jboss.mq.server.TracingInterceptor.receive(TracingInterceptor.java:579)
at org.jboss.mq.server.JMSServerInvoker.receive(JMSServerInvoker.java:226)
at org.jboss.mq.il.http.servlet.HTTPServerILServlet.processRequest(HTTPServerILServlet.java:204)
at org.jboss.mq.il.http.servlet.HTTPServerILServlet.doPost(HTTPServerILServlet.java:287)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:307)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:385)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678)
at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
2006-08-04 13:17:57,294 TRACE [org.jboss.mq.server.TracingInterceptor] RETURN : receive
2006-08-04 13:17:57,294 DEBUG [org.jboss.mq.il.http.servlet.HTTPServerILServlet] Threw an exception of type 'javax.jms.JMSSecurityException' with a message of 'User session is not valid.' This exception is being propogated to the client as a HTTPILResponse.
2006-08-04 13:17:57,404 TRACE [org.jboss.mq.il.http.servlet.HTTPServerILServlet] doPost() defers to processRequest, see the parameters in its trace.
2006-08-04 13:17:57,404 TRACE [org.jboss.mq.il.http.servlet.HTTPServerILServlet] processRequest(HttpServletRequest org.apache.catalina.connector.RequestFacade@2bac2b, HttpServletResponse org.apache.catalina.connector.ResponseFacade@1343c2a)
On the Client side: following stacktrace is visible
13:17:57 [MessageListenerThread - MyTopic] WARN org.jboss.mq.SpyMessageConsumer - Message consumer closing due to error in listening thread.
javax.jms.JMSSecurityException: User session is not valid
at org.jboss.mq.security.SecurityManager.authorize(SecurityManager.java:230)
at org.jboss.mq.security.ServerSecurityInterceptor.authorizeRead(ServerSecurityInterceptor.java:233)
at org.jboss.mq.security.ServerSecurityInterceptor.receive(ServerSecurityInterceptor.java:98)
at org.jboss.mq.server.ClientMonitorInterceptor.receive(ClientMonitorInterceptor.java:231)
at org.jboss.mq.server.TracingInterceptor.receive(TracingInterceptor.java:579)
at org.jboss.mq.server.JMSServerInvoker.receive(JMSServerInvoker.java:226)
at org.jboss.mq.il.http.servlet.HTTPServerILServlet.processRequest(HTTPServerILServlet.java:204)
at org.jboss.mq.il.http.servlet.HTTPServerILServlet.doPost(HTTPServerILServlet.java:287)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:307)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:385)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678)
at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
mq.Connection should start the ping thread after the ClientID is known.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 9 months
[JBoss JIRA] Created: (JBFORUMS-247) forums and commons-fileupload-1.1
by Luca Stancapiano (JIRA)
forums and commons-fileupload-1.1
---------------------------------
Key: JBFORUMS-247
URL: http://jira.jboss.com/jira/browse/JBFORUMS-247
Project: JBoss Forums
Issue Type: Bug
Environment: JBoss as from http://anonsvn.jboss.org/repos/jbossas/tags/JBoss_4_0_5_GA_CP06,
JBoss Portal from http://anonsvn.jboss.org/repos/portal/trunk since 9 july 2007,
JBoss Forums from http://anonsvn.jboss.org/repos/labs/labs/jbossforums/branches/forums101P26 since 9 july 2007
Reporter: Luca Stancapiano
Assigned To: Ryszard Kozmik
Attachments: ForumsJSFPortlet.java
hi....I send you to see http://jira.jboss.com/jira/browse/JBPORTAL-1550 by me reported. It is the same problem......if you post messages using 'multipart/form-data' through commons-fileupload libs, you miss character encoding because there is a incompatibility between tomcat 5.5.23 and fileupload 1.1, and then if you try to send messages with characters as à, è, ì, ò, ù you 'll get problems of decoding with strange characters of response. Also for Forums I send you a patch. I substituted getString() method of org.apache.commons.fileupload.disk.DiskFileItem class with getString( String ...) method, passing inside the character encoding of the request:
org.jboss.portlet.forums.ui.ForumsJSFPortlet : row 560
I write :
newParams.put(item.getFieldName(), new String[]{item.getString(req.getCharacterEncoding())});
instead of:
newParams.put(item.getFieldName(), new String[]{item.getString()});
org.jboss.portlet.forums.ui.ForumsJSFPortlet : row 564
I write:
String value = item.getString(req.getCharacterEncoding());
instead of:
String value = item.getString();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 9 months