April 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Closed: (JBMESSAGING-410) java:/JmsXA in no-tx context does not work the same way as JBossMQ

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-410?page=all ] Tim Fox closed JBMESSAGING-410. ------------------------------- Resolution: Won't Fix Assignee: Tim Fox (was: Ovidiu Feodorov) > java:/JmsXA in no-tx context does not work the same way as JBossMQ > ------------------------------------------------------------------ > > Key: JBMESSAGING-410 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-410 > Project: JBoss Messaging > Issue Type: Bug > Components: Configuration and Management > Affects Versions: 1.0.1.CR2, 1.2.0.Beta2, 1.0.1.SP4 > Reporter: Elias Ross > Assigned To: Tim Fox > Priority: Critical > Fix For: Unscheduled > > > The same code I wrote that uses java:/JmsXA in a non-transacted environment with JBossMQ does not work with JBoss Messaging. And actually the same code does work correctly with SonicMQ as well, using the JCA adaptor with the Sonic XA connection factory. > Why allow the use java:/JmsXA without transactions? It makes sense to use a cached connection manager anyway, like you would with a database. And anyway, should be addressed for compatibility. > The following code *should* successfully send a message to a queue running without a transaction. Currently, it doesn't seem to do anything and no usage warnings are produced. > QueueConnectionFactory queueCF = (QueueConnectionFactory)new InitialContext.lookup("java:/JmsXA"); > ... > QueueConnection queueConnection = queueCF.createQueueConnection(); > QueueSession queueSession = > queueConnection.createQueueSession(false, QueueSession.AUTO_ACKNOWLEDGE); > QueueSender queueSender = queueSession.createSender(queue); > ObjectMessage om = queueSession.createObjectMessage(); > queueSender.send(om); > queueSender.close(); > queueSession.close(); > queueConnection.close(); -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBMESSAGING-170) JCA 1.5 Message Inflow

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-170?page=all ] Tim Fox closed JBMESSAGING-170. ------------------------------- Resolution: Out of Date This has already been done by Weston some time ago > JCA 1.5 Message Inflow > ---------------------- > > Key: JBMESSAGING-170 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-170 > Project: JBoss Messaging > Issue Type: Task > Components: AS Integration > Reporter: Ovidiu Feodorov > Assigned To: Tim Fox > Priority: Critical > Fix For: Unscheduled > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > See related task. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-479) Credits replenishments only return the bytes read *not* the full credits

by Bela Ban (JIRA)

Credits replenishments only return the bytes read *not* the full credits ------------------------------------------------------------------------- Key: JGRP-479 URL: http://jira.jboss.com/jira/browse/JGRP-479 Project: JGroups Issue Type: Sub-task Affects Versions: 2.4.1 SP1 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 Currently, a receiver always returns the full credits rather than the credits actually *received* by the receiver. Brian's description is below: FC does not control flow tightly enough. I believe this may be because credit replenishments bring a sender up to max_credits from *whatever credit level* the sender is at, which has no direct relationship to how many bytes the receiver had seen. This is more of a problem under sustained over load when sender threads are timing out while blocking and sending credit requests. For example, with a config of max_credits = 1,000,000 and min_credits = 100,000. Sender is under enough client load that it basically always has sender threads blocking with messages totalling 1,000,000 bytes. Sender sends 1,000,000 bytes and blocks. Receiver processes slowly. Receiver processes 900,000, sends credit replenishment 1. Meanwhile, sender times out; sends credit request 1. Sender gets credit replenishment 1; unblocks, sends another 1,000,000, blocks again. Receiver processes 100,000, then gets credit request 1 and sends replenishment 2. Sender times out; sends credit request 2. Sender gets replenishment 2 and unblocks, sends 1,000,000 bytes. At this point, the sender has sent 3,000,000 and the receiver has received 1,000,000. Further, there is a credit request in the channel, so after the receiver sees the next 1,000,000 bytes, it will have sent two more replenishments, theoretically allowing the sender to send 2,000,000 more bytes. This is an extreme example, but the key point is a credit replenishment gives the sender the right to send up to max_credits, even though the receiver may have only seen min_credits when it sent the message. Solution to this problem is two-fold: 1) Credit replenishment messages should include a payload indicating the number of bytes received. The sender only gives itself that many credits. -- 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, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-481) Send replenishments sooner: after min_credits bytes have been received *not* after max_credits - min_credits have been received

by Bela Ban (JIRA)

Send replenishments sooner: after min_credits bytes have been received *not* after max_credits - min_credits have been received ------------------------------------------------------------------------------------------------------------------------------- Key: JGRP-481 URL: http://jira.jboss.com/jira/browse/JGRP-481 Project: JGroups Issue Type: Sub-task Affects Versions: 2.4.1 SP1 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 2) #1 alone will hurt performance in a steady-state system. If A and B are sending messages to each other, with a config of max_credits = 1,000,000 and min_credits=100,000, B will send A 900,000 credits when it has read that many. It will take a while for the credit replenishment to reach A (since B is also sending), so A will send 100,000 more and begin blocking. It will then get the 900,000 credit replenishment, send 900,000 and begin blocking again. Under the old system it would have gotten 1,000,000 bytes -- now it only gets 900,000. Solution to that is to change the meaning of min_credits. Currently, receiver sends credit when it has received_bytes >= (max_credits - min_credits). If min_credits is 100,000, credits will only be sent when the sender is almost out. The standard value of min_threshold=0.10 is very conservative, but was needed because the more frequently replenishment messages with no set number of bytes get sent, the more likely the sender is to get too many credits and OOME. If credit replenishment messages only give the number of bytes the receiver has read, then there is no OOME risk. Therefore, sending replenishment messages frequently makes sense. So, I propose the receiver should send credit when received_bytes >= min_credits, rather than the current approach of sending when received_bytes >= max_credit - min_credit. -- 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, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBBUILD-323) JBossBuild needs to be able to calculate component version using highest common denominator algorithm

by Alex Pinkin (JIRA)

JBossBuild needs to be able to calculate component version using highest common denominator algorithm ----------------------------------------------------------------------------------------------------- Key: JBBUILD-323 URL: http://jira.jboss.com/jira/browse/JBBUILD-323 Project: JBoss Build System Issue Type: Feature Request Affects Versions: JBossBuild-1.1 DR2 Reporter: Alex Pinkin We've already had this discussion, and thought that it's not easy to implement. However, I do think we need this done since I don't want all projects to enumerate all their 3rd party dependencies in build-thirdparty.xml. Example: these products include the following javassist versions 1. aop 1.5.0.GA: javassist 3.2.0.CR1, 3.2.0.CR2, 3.3.0.GA 2. ws 1.0.0.GA: javassist 3.2.0.CR1, 3.2.0.CR2, 3.3.0.GA 3. ejb3 1.0.0.CR8: javassist 3.2.0.CR1, 3.2.0.CR2, 3.2.0.GA JBossBuild needs to be able to determine that javassist 3.2.0.CR2 is the highest common denominator. Current behaviour is that JBossBuild takes the highest version of the component whenever it runs into it for the first time during the dependency graph traversal. Does Maven already support this? It seems like this should be one of the core maven features. Could you please look more info feasibility of implementing this in JBossBuild? -- 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, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (JGRP-482) Remove (modified) SFC and copy it to 2.5

by Bela Ban (JIRA)

Remove (modified) SFC and copy it to 2.5 ---------------------------------------- Key: JGRP-482 URL: http://jira.jboss.com/jira/browse/JGRP-482 Project: JGroups Issue Type: Task Affects Versions: 2.4.1 SP2 Reporter: Bela Ban Assigned To: Bela Ban Priority: Minor Fix For: 2.4.1 SP2 The changes (especially sending credits when min_credits have been exceeded) need further investigation. I'm moving this to 2.5, so we can copty the good changes over to the SFC present in 2.5 -- 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, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-4279) failing org.jboss.test.cmp2.lob.LOBUnitTestCase in jboss-3.2-compatiblity-matrix

by Dimitris Andreadis (JIRA)

failing org.jboss.test.cmp2.lob.LOBUnitTestCase in jboss-3.2-compatiblity-matrix -------------------------------------------------------------------------------- Key: JBAS-4279 URL: http://jira.jboss.com/jira/browse/JBAS-4279 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Test Suite Reporter: Dimitris Andreadis Fix For: JBossAS-4.2.0.GA http://cruisecontrol.jboss.com/cc/buildresults/jboss-3.2-compatibility-ma... org.jboss.test.cmp2.cmrtree.test.CascadeDeleteUnitTestCase::testCascadeDelete org.jboss.test.cmp2.lob.LOBUnitTestCase::testBinaryLoad LOBUnitTestCase fails for most library combination, so maybe either this or the previous CascadeDeleteUnitTestCase doens't cleanup properly? -- 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, 3 months

2
11
0 / 0

[JBoss JIRA] Commented: (JBBUILD-176) Look into populating the public maven repository with jboss release binaries

by Paul Gier (JIRA)

[ http://jira.jboss.com/jira/browse/JBBUILD-176?page=comments#action_12359729 ] Paul Gier commented on JBBUILD-176: ----------------------------------- This issue is now being discussed with IT. Since rsync is a new feature to our repository servers, it will take some time to research. > Look into populating the public maven repository with jboss release binaries > ---------------------------------------------------------------------------- > > Key: JBBUILD-176 > URL: http://jira.jboss.com/jira/browse/JBBUILD-176 > Project: JBoss Build System > Issue Type: Feature Request > Reporter: Scott M Stark > Assigned To: Paul Gier > Fix For: MavenBuild 1.2 > > > look into populating the public maven repository with the jboss release binaries. > http://maven.apache.org/maven-1.x/reference/repository-upload.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, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBBUILD-336) Create Maven pom for JBoss Test project

by Paul Gier (JIRA)

Create Maven pom for JBoss Test project --------------------------------------- Key: JBBUILD-336 URL: http://jira.jboss.com/jira/browse/JBBUILD-336 Project: JBoss Build System Issue Type: Feature Request Components: Maven Environment: All environments. Reporter: Paul Gier The jboss microcontainer is dependent on a recent version of JBoss Test. Since several projects are dependent on JBoss Test, it would be good to have a maven build of this project, and schedule it in cruise control. -- 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, 3 months

2
3
0 / 0

[JBoss JIRA] Closed: (JBPM-395) SwimlaneInstance PooledActor assignment bug (not re-assignment issue)

by Tom Baeyens (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-395?page=all ] Tom Baeyens closed JBPM-395. ---------------------------- Resolution: Out of Date Britt, if i read this correctly the issue is resolved and you have been able to remove the workaround from your code, is that right ? If not, please reopen this issue. > SwimlaneInstance PooledActor assignment bug (not re-assignment issue) > --------------------------------------------------------------------- > > Key: JBPM-395 > URL: http://jira.jboss.com/jira/browse/JBPM-395 > Project: JBoss jBPM > Issue Type: Bug > Components: Core Engine > Affects Versions: jBPM 3.0.1 > Environment: JDK 1.5, Postgresql, JBoss 4.0.2 > Reporter: Britt Miner > Assigned To: Tom Baeyens > > Initializing swimlaneInstances at process creation (or perhaps any time prior to creation of an associated task) will persist any configured actorId to the database, but configured PooledActors are not persisted. The AssignmentHandler functionality seems to work fine--the newly initialized swimlaneInstance has both actorId and pooledActors set correctly; however, the pooledActors will not be persisted. Allowing the swimlaneInstance to be initialized at creation of a related task does result in both actorId and pooledActors being properly persisted. > This issue is similar, though not identical, to http://jira.jboss.com/jira/browse/JBPM-375 and http://jira.jboss.com/jira/browse/JBPM-378 which are both related to swimlane assignment issues. > Why initialize swimlaneInstances at process creation? So that swimlane assignments can be made based on the initiator of the process (responsibilities broken down by regional groups, etc.), and so that those assignments are available for reporting/forcasting purposes. > This is the code fragment used to initialize the swimlanes: > ... > Map swimlanes = processDefinition.getTaskMgmtDefinition().getSwimlanes(); > Iterator itr = swimlanes.keySet().iterator(); > while(itr.hasNext()) { > Swimlane swimlane = (Swimlane)swimlanes.get(itr.next()); > SwimlaneInstance swi = pi.getTaskMgmtInstance().getInitializedSwimlaneInstance(new Execution > Context(pi.getRootToken()), swimlane); > //at this point, swi contains both actors and PooledActors that were specified in configuration and > populated with an appropriate AssignmentHandler > } > graphSession.saveProcessInstance(pi); > jbpmSession.commitTransaction(); > Thanks, > Britt -- 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, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2007