[JBoss JIRA] Closed: (JBPM-593) suspend() and resume() failing in JBPM 3.1
by Tom Baeyens (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-593?page=all ]
Tom Baeyens closed JBPM-593.
----------------------------
Resolution: Done
i applied the proposed updates and introduced the message alias.
> suspend() and resume() failing in JBPM 3.1
> ------------------------------------------
>
> Key: JBPM-593
> URL: http://jira.jboss.com/jira/browse/JBPM-593
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Core Engine
> Affects Versions: jBPM 3.1
> Environment: Windows XP Pro, JDK 1.5.0_06, jBPM 3.1
> Reporter: Romin Irani
> Assigned To: Tom Baeyens
> Priority: Blocker
> Fix For: jBPM 3.1.3
>
>
> The resume() and suspend() methods on the ProcessInstance are failing in jBPM 3.1. The resume() and suspend() methods on the ProcessInstance are failing in jBPM 3.1. The error is a SQL Syntax error "unknown column 'token'". On debugging, I have found the following named queries in the org/jbpm/db/hibernate.queries.hbm.xml as given below:
> Code:
> <query name="MessagingSession.suspendMessagesForToken">
> <![CDATA[
> update org.jbpm.msg.Message
> set isSuspended = true
> where token = :token
> ]]>
> </query>
> <query name="MessagingSession.resumeMessagesForToken">
> <![CDATA[
> update org.jbpm.msg.Message
> set isSuspended = false
> where token = :token
> ]]>
> </query>
> On changing them to the following
> <query name="MessagingSession.suspendMessagesForToken">
> <![CDATA[
> update org.jbpm.msg.Message m
> set m.isSuspended = true
> where m.token = :token
> ]]>
> </query>
> <query name="MessagingSession.resumeMessagesForToken">
> <![CDATA[
> update org.jbpm.msg.Message m
> set m.isSuspended = false
> where m.token = :token
> ]]>
> </query>
> and replacing the file in JBPM JAR file, it worked. Note : I added the alias 'm'.
> This is happening with the Hibernate JAR's that are shipped with JBPM 3.1 itself. I have not tried it out with Hibernate 3.1 standalone downloaded directly from the Hibernate site.
--
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
19 years, 10 months
[JBoss JIRA] Commented: (JBPM-593) suspend() and resume() failing in JBPM 3.1
by Tom Baeyens (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-593?page=comments#action_12340206 ]
Tom Baeyens commented on JBPM-593:
----------------------------------
what i still don't get completely is the following: In which versions of hibernate does this query give a problem and in which versions it works:
update org.jbpm.msg.Message
set isSuspended = true
where token = :token
also, in the versions of hibernate where it gives a problem, what is the workaround ?
> suspend() and resume() failing in JBPM 3.1
> ------------------------------------------
>
> Key: JBPM-593
> URL: http://jira.jboss.com/jira/browse/JBPM-593
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Core Engine
> Affects Versions: jBPM 3.1
> Environment: Windows XP Pro, JDK 1.5.0_06, jBPM 3.1
> Reporter: Romin Irani
> Assigned To: Tom Baeyens
> Priority: Blocker
> Fix For: jBPM 3.1.3
>
>
> The resume() and suspend() methods on the ProcessInstance are failing in jBPM 3.1. The resume() and suspend() methods on the ProcessInstance are failing in jBPM 3.1. The error is a SQL Syntax error "unknown column 'token'". On debugging, I have found the following named queries in the org/jbpm/db/hibernate.queries.hbm.xml as given below:
> Code:
> <query name="MessagingSession.suspendMessagesForToken">
> <![CDATA[
> update org.jbpm.msg.Message
> set isSuspended = true
> where token = :token
> ]]>
> </query>
> <query name="MessagingSession.resumeMessagesForToken">
> <![CDATA[
> update org.jbpm.msg.Message
> set isSuspended = false
> where token = :token
> ]]>
> </query>
> On changing them to the following
> <query name="MessagingSession.suspendMessagesForToken">
> <![CDATA[
> update org.jbpm.msg.Message m
> set m.isSuspended = true
> where m.token = :token
> ]]>
> </query>
> <query name="MessagingSession.resumeMessagesForToken">
> <![CDATA[
> update org.jbpm.msg.Message m
> set m.isSuspended = false
> where m.token = :token
> ]]>
> </query>
> and replacing the file in JBPM JAR file, it worked. Note : I added the alias 'm'.
> This is happening with the Hibernate JAR's that are shipped with JBPM 3.1 itself. I have not tried it out with Hibernate 3.1 standalone downloaded directly from the Hibernate site.
--
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
19 years, 10 months
[JBoss JIRA] Commented: (JBPM-593) suspend() and resume() failing in JBPM 3.1
by Tom Baeyens (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-593?page=comments#action_12340205 ]
Tom Baeyens commented on JBPM-593:
----------------------------------
for some reason or another, this issue slipped through and didn't make it in the 3.1.2 release. we will work on it and release 3.1.3 more rapidly.
> suspend() and resume() failing in JBPM 3.1
> ------------------------------------------
>
> Key: JBPM-593
> URL: http://jira.jboss.com/jira/browse/JBPM-593
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Core Engine
> Affects Versions: jBPM 3.1
> Environment: Windows XP Pro, JDK 1.5.0_06, jBPM 3.1
> Reporter: Romin Irani
> Assigned To: Tom Baeyens
> Priority: Blocker
> Fix For: jBPM 3.1.3
>
>
> The resume() and suspend() methods on the ProcessInstance are failing in jBPM 3.1. The resume() and suspend() methods on the ProcessInstance are failing in jBPM 3.1. The error is a SQL Syntax error "unknown column 'token'". On debugging, I have found the following named queries in the org/jbpm/db/hibernate.queries.hbm.xml as given below:
> Code:
> <query name="MessagingSession.suspendMessagesForToken">
> <![CDATA[
> update org.jbpm.msg.Message
> set isSuspended = true
> where token = :token
> ]]>
> </query>
> <query name="MessagingSession.resumeMessagesForToken">
> <![CDATA[
> update org.jbpm.msg.Message
> set isSuspended = false
> where token = :token
> ]]>
> </query>
> On changing them to the following
> <query name="MessagingSession.suspendMessagesForToken">
> <![CDATA[
> update org.jbpm.msg.Message m
> set m.isSuspended = true
> where m.token = :token
> ]]>
> </query>
> <query name="MessagingSession.resumeMessagesForToken">
> <![CDATA[
> update org.jbpm.msg.Message m
> set m.isSuspended = false
> where m.token = :token
> ]]>
> </query>
> and replacing the file in JBPM JAR file, it worked. Note : I added the alias 'm'.
> This is happening with the Hibernate JAR's that are shipped with JBPM 3.1 itself. I have not tried it out with Hibernate 3.1 standalone downloaded directly from the Hibernate site.
--
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
19 years, 10 months
[JBoss JIRA] Updated: (JBPM-593) suspend() and resume() failing in JBPM 3.1
by Tom Baeyens (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-593?page=all ]
Tom Baeyens updated JBPM-593:
-----------------------------
Fix Version/s: jBPM 3.1.3
(was: jBPM 3.1.2)
> suspend() and resume() failing in JBPM 3.1
> ------------------------------------------
>
> Key: JBPM-593
> URL: http://jira.jboss.com/jira/browse/JBPM-593
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Core Engine
> Affects Versions: jBPM 3.1
> Environment: Windows XP Pro, JDK 1.5.0_06, jBPM 3.1
> Reporter: Romin Irani
> Assigned To: Tom Baeyens
> Priority: Blocker
> Fix For: jBPM 3.1.3
>
>
> The resume() and suspend() methods on the ProcessInstance are failing in jBPM 3.1. The resume() and suspend() methods on the ProcessInstance are failing in jBPM 3.1. The error is a SQL Syntax error "unknown column 'token'". On debugging, I have found the following named queries in the org/jbpm/db/hibernate.queries.hbm.xml as given below:
> Code:
> <query name="MessagingSession.suspendMessagesForToken">
> <![CDATA[
> update org.jbpm.msg.Message
> set isSuspended = true
> where token = :token
> ]]>
> </query>
> <query name="MessagingSession.resumeMessagesForToken">
> <![CDATA[
> update org.jbpm.msg.Message
> set isSuspended = false
> where token = :token
> ]]>
> </query>
> On changing them to the following
> <query name="MessagingSession.suspendMessagesForToken">
> <![CDATA[
> update org.jbpm.msg.Message m
> set m.isSuspended = true
> where m.token = :token
> ]]>
> </query>
> <query name="MessagingSession.resumeMessagesForToken">
> <![CDATA[
> update org.jbpm.msg.Message m
> set m.isSuspended = false
> where m.token = :token
> ]]>
> </query>
> and replacing the file in JBPM JAR file, it worked. Note : I added the alias 'm'.
> This is happening with the Hibernate JAR's that are shipped with JBPM 3.1 itself. I have not tried it out with Hibernate 3.1 standalone downloaded directly from the Hibernate site.
--
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
19 years, 10 months
[JBoss JIRA] Closed: (JBAS-3360) No ability to override CMD_STOP in JBOSS_HOME/bin/jboss_init_redhat.sh
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3360?page=all ]
Dimitris Andreadis closed JBAS-3360.
------------------------------------
Fix Version/s: JBossAS-5.0.0.Beta
JBossAS-4.0.5.CR1
JBossAS-3.2.8.SP2
Resolution: Done
Assignee: Dimitris Andreadis
Start and Stop commands can be overriden now.
They are also renamed to:
JBOSS_CMD_START
JBOSS_CMD_STOP
to make it more evident.
> No ability to override CMD_STOP in JBOSS_HOME/bin/jboss_init_redhat.sh
> ----------------------------------------------------------------------
>
> Key: JBAS-3360
> URL: http://jira.jboss.com/jira/browse/JBAS-3360
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: JBossAS-4.0.4.GA
> Environment: Ubuntu
> Reporter: Jon Stevens
> Assigned To: Dimitris Andreadis
> Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.CR1, JBossAS-3.2.8.SP2
>
>
> The subject says it all:
> No ability to override CMD_STOP in JBOSS_HOME/bin/jboss_init_redhat.sh
> I would love to see something like this:
> < CMD_STOP="java -classpath $JBOSSCP org.jboss.Shutdown --shutdown"
> > CMD_STOP=${CMD_STOP:-"java -classpath $JBOSSCP org.jboss.Shutdown --shutdown"}
> I need to override this because I want to pass --server to the Shutdown class. So, another option would be to allow me to do that as well.
--
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
19 years, 10 months
[JBoss JIRA] Created: (JGRP-264) Multiplexer: reconnect fails
by Bela Ban (JIRA)
Multiplexer: reconnect fails
----------------------------
Key: JGRP-264
URL: http://jira.jboss.com/jira/browse/JGRP-264
Project: JGroups
Issue Type: Bug
Affects Versions: 2.3 SP1, 2.3, 2.2.9 SP3 (2.2.9.3), 2.2.9.2, 2.2.9.1, 2.2.9, 2.2.8
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.4
[Brian Stansberry]
AS test o.j.t.c.partition.test.PartitionRestartUnitTestCase surfaced an
issue with the multiplexer and a disconnect followed by a reconnect (w/o
close()).
Problem is basically the Map<String, Channel> service field in
Multiplexer. A service gets added to this map when a MuxChannel is
created. It currently gets removed as part of
Multiplexer.handleServiceDown(), which gets called as part of
disconnect().
Problem is once its removed, it doesn't get added again as part of
connect() processing, so thereafter things fail. I think it should be
removed as part of close(), but haven't looked carefully enough to see
if would have side effects.
I've added a couple tests to MultiplexerTest to ensure things work with
a disconnect() followed by a new connect().
I looked at it a little bit and it seemed an easy solution was to move
the call to Multiplexer.unregister() from
Multiplexer.handleServiceDown() to JChannelFactory.close().
Index: JChannelFactory.java
===================================================================
RCS file:
/cvsroot/javagroups/JGroups/src/org/jgroups/JChannelFactory.java,v
retrieving revision 1.29
diff -u -r1.29 JChannelFactory.java
--- JChannelFactory.java 14 Jul 2006 12:17:24 -0000 1.29
+++ JChannelFactory.java 26 Jul 2006 21:35:24 -0000
@@ -389,6 +389,7 @@
if(addr != null) {
try {
mux.sendServiceDownMessage(ch.getId(),
addr);
+ mux.unregister(ch.getId());
}
catch(Exception e) {
if(log.isErrorEnabled())
Index: mux/Multiplexer.java
===================================================================
RCS file:
/cvsroot/javagroups/JGroups/src/org/jgroups/mux/Multiplexer.java,v
retrieving revision 1.17
diff -u -r1.17 Multiplexer.java
--- mux/Multiplexer.java 14 Jul 2006 13:09:25 -0000 1.17
+++ mux/Multiplexer.java 26 Jul 2006 21:35:26 -0000
@@ -599,9 +599,9 @@
}
}
- Address local_address=getLocalAddress();
- if(local_address != null && host != null &&
host.equals(local_address))
- unregister(service);
+// Address local_address=getLocalAddress();
+// if(local_address != null && host != null &&
host.equals(local_address))
+// unregister(service);
}
With this, as the MultiplexerTest cases pass, as does the AS integration
test.
--
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
19 years, 10 months
[JBoss JIRA] Created: (JBSER-85) Can't serialize double[]
by Clebert Suconic (JIRA)
Can't serialize double[]
------------------------
Key: JBSER-85
URL: http://jira.jboss.com/jira/browse/JBSER-85
Project: JBoss Serialization
Issue Type: Bug
Affects Versions: 1.0.1 GA, 1.0.0 GA
Reporter: Clebert Suconic
Assigned To: Clebert Suconic
Fix For: 1.0.2 GA
Reading a double[] will always cause
Caused by: java.io.IOException: The hierarchy of [D is different in your current classPath
at org.jboss.serial.classmetamodel.StreamingClass.readStream(StreamingClass.java:90)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:381)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readObject(DataContainer.java:836)
at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)
at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readObject(DataContainer.java:836)
at org.jboss.serial.io.JBossObjectInputStream.readObjectUsingDataContainer(JBossObjectInputStream.java:152)
at org.jboss.serial.benchmarks.SizeBenchmarkTestCase.doTestJBossSerializationInDirect(SizeBenchmarkTestCase.java:296)
at org.jboss.serial.benchmarks.SizeBenchmarkTestCase.executTest(SizeBenchmarkTestCase.java:99)
... 19 more
--
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
19 years, 10 months
[JBoss JIRA] Updated: (JBCACHE-658) Fast locking for mostly-read PojoCache
by Ben Wang (JIRA)
[ http://jira.jboss.com/jira/browse/JBCACHE-658?page=all ]
Ben Wang updated JBCACHE-658:
-----------------------------
Component/s: PojoCache
Fix Version/s: POJOCache
> Fast locking for mostly-read PojoCache
> --------------------------------------
>
> Key: JBCACHE-658
> URL: http://jira.jboss.com/jira/browse/JBCACHE-658
> Project: JBoss Cache
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: PojoCache
> Reporter: Nitzan Niv
> Assigned To: Ben Wang
> Fix For: POJOCache
>
>
> The locking mechanism locks all the nodes in the path from the tree root to the modified node. If the cache contains a deep hierarchy of nodes (e.g., PojoCache that contains complex objects) and the usage of the cache
> is mostly-read the locking overhead is unnecessarilly large.
> To enable REPEATABLE_READ isolation level with minimal overhead (but with reduced update parallelism) just the tree root should be locked instead of the nodes-path. To define this policy as a new isloation level ("single"):
> Change in PessimisticLockInterceptor (line 199):
> else {
> if(isolation_level == IsolationLevel.SINGLE) {//XXX
> if (i == 0) {
> acquired=child_node.acquire(owner, lock_timeout, lock_type);
> }
> } else {
> if(lock_type == DataNode.LOCK_TYPE_WRITE && i == (treeNodeSize - 1)) {
> acquired=child_node.acquire(owner, lock_timeout, DataNode.LOCK_TYPE_WRITE);
> }
> else {
> acquired=child_node.acquire(owner, lock_timeout, DataNode.LOCK_TYPE_READ);
> }
> }//XXX
> }
> in LockStrategyFactory.java:
> if (lockingLevel == IsolationLevel.REPEATABLE_READ || lockingLevel == IsolationLevel.SINGLE) //XXX
> return new LockStrategyRepeatableRead();
> and add the "SINGLE" isolation level to IsolationLevel.java.
--
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
19 years, 10 months
[JBoss JIRA] Updated: (JBAS-2861) HttpSession sharing between WAR modules
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2861?page=all ]
Brian Stansberry updated JBAS-2861:
-----------------------------------
Fix Version/s: JBossAS-4.0.6.CR1
(was: JBossAS-4.0.5.CR1)
Priority: Major (was: Critical)
We will get this done in Q4 '06 or at latest early Q1 '07.
> HttpSession sharing between WAR modules
> ---------------------------------------
>
> Key: JBAS-2861
> URL: http://jira.jboss.com/jira/browse/JBAS-2861
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Tomcat) service, Clustering
> Affects Versions: JBossAS-3.2.7 Final, JBossAS-3.2.6 Final
> Reporter: Brian Stansberry
> Assigned To: Brian Stansberry
> Fix For: JBossAS-4.0.6.CR1
>
>
> Creating a redacted version of JBAS-1909, which was opened as a non-public JIRA issue by a customer.
> Our J2EE application is composed of several modules, each one addressing one facet of our business process, and currently this application has one web module (WAR) and several JAR modules (EJB).
> We need to divide this web module into several smaller web modules.
> In order to separate our unique WAR file into several WARs we must guarantee HttpSession sharing. This is due to the fact that we have a lot of session attributes that are used throughout the entire application and we cannot afford to refactor the application, in fact, that's impossible.
> The security aspects for this requirement are completely addressed by the JBoss/Tomcat Single Sign-On mechanism but the session sharing requirements are not.
> The ideal scenario is to keep the same HttpSession (same object in the heap, same session ID) when authenticating into one application (HttpSession created) and then forwarding to another application.
> The current SSO mechanism allows the user to access the second application without reauthentication, as you know, but it creates a new HttpSession object. Also, if the two WARs have different session timeouts, if you access application A, migrates to application B, stays there until session in application A expires and then returns to application A from application B, a new HttpSession is also created in application A.
> The ideal solution is to have one unique, monolithic session to all web applications configured to share a common session. IBM WebSphere and BEA WebLogic do have this configuration and feature. Please check the links below in case you want more information:
> WebSphere Application Server V5: Sharing Session Context - http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/tips0215.ht...
> BEA Weblogic - Enabling Web applications to share the same session - http://e-docs.bea.com/wls/docs90/webapp/sessions.html
--
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
19 years, 10 months