July 2008 - jboss-dev-forums - Jboss List Archives

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBPAPP-863 -- FC blocks during slow failure detection

by vblagojevic＠jboss.com

Brian, I combed through all the logs and I still could not figure out what went wrong. Just as a precaution we should as you suggest remove FC from one buddy configurations for the time being - until we track this one down. What puzzles me the most is how the views are not propagated upon merge along with the fact that FC is above GMS and of course MERGE2 and I do not see how *not* having FC in the stack makes the test pass and how having it does not. Unless maybe view handler thread gets somehow blocked in FC.down? Dominik, Could you please repeat this "experiment" but this time with GMS and MERGE2 turned on trace as well - not just FC. Thank you. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163635#4163635 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163635

17 years, 9 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: Transaction Status.STATUS_ROLLEDBACK

by mark.little＠jboss.com

You are so much quicker than me consulting my docs ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163631#4163631 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163631

17 years, 9 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: setting up a jboss as proxy for routing HTTP requests to

by bstansberry＠jboss.com

Please post user requests on the user forum. JBoss AS is not designed for use as an HTTP proxy loadbalancer. There used to be (I believe in 4.0.4 and earlier) a load balancer web application someone contributed that would do this (look in the varia module of the source distribution) but it wasn't maintained and was never the recommended solution for load balancing vs. mod_jk. It didn't have any association with the remote Java client load balancing policies you mention. mod_jk doesn't just support a round-robin approach; the recommended configuration uses sticky sessions, which has semantics similar to the FirstAvailable load balance policy. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163629#4163629 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163629

17 years, 9 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: Transaction Status.STATUS_ROLLEDBACK

by jhalliday

4.2.3.SP5 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163624#4163624 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163624

17 years, 9 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: Transaction Status.STATUS_ROLLEDBACK

by mark.little＠jboss.com

Well like I said, in the current code you can call rollback and it won't throw an exception if the transaction has already rolled back. I'm not sure which version of TS is in 4.2.1GA though. Maybe Jonathan can answer? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163621#4163621 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163621

17 years, 9 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: Transaction Status.STATUS_ROLLEDBACK

by huuskart

"mark.little(a)jboss.com" wrote : "huuskart" wrote : When a transaction timeout or some other unexpected situation occurs, the new JBoss transaction manager (in JBoss 4.2.1.GA) marks the transaction into state Status.STATUS_ROLLEDBACK. | | | | Have you read the transaction standards with which we comply? They make it very clear that on a timeout you MUST roll back the transaction. They also make it very clear that data consistency is very important for transaction systems. So any low-level system exception, for instance, should force the transaction to roll back. | My point was not at all to complain about the transaction getting rolled back. It is blindingly obvious that it must be rolled back. My point was that in BMT EJB code, seeing Status.STATUS_ROLLEDBACK is very puzzling, and even more so because you can't commit() nor rollback() the transaction (both throw an exception), nor can you call begin() on it again. "mark.little(a)jboss.com" wrote : You can always call suspend to remove the thread-to-transaction association. | No, I can't. In EJB code, all I have to work with is javax.transaction.UserTransaction, and it does not give me that kind of control (nor would I wish to see such controls in EJB session code). Sorry, I forgot to mention the version: I'm using JBoss AS 4.2.1.GA. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163600#4163600 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163600

17 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Handling Large Messages

by ataylor

anonymous wrote : I think we should extend the concept of splitting packets into fragments to other packets too - not just message sends and receives, since other packets have the possibility (however unlikely) of getting large, since there are not fixed length fields like address names in them. yeah so the 1st way i suggested would do this. basically the encode method of PAcketImpl would be something like: | public void encode(MessagingBuffer buffer) | { | //The standard header fields | buffer.putInt(0); //The length gets filled in at the end | buffer.putByte(type); | buffer.putLong(responseTargetID); | buffer.putLong(targetID); | buffer.putLong(executorID); | buffer.putInt(correlationId); | buffer.putBoolean(isLastMessage); | //if we are a small message | if(!isMultiPartMessage()) | { | encodeBody(buffer); | } | else | { | //else write the body to a cache and for each send only write 1k of body to the message | if(correlationId == 0) | { | bodyCache = buffer.createNewBuffer(1024); | encodeBody(bodyCache); | } | buffer.putBytes(bodyCache.array(), correlationId * 1024, 1024); | } | | //The length doesn't include the actual length byte | int len = buffer.position() - DataConstants.SIZE_INT; | | buffer.putInt(0, len); | | buffer.flip(); | } | Then we just keep on sending the same message but with the next part of the body. anonymous wrote : View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163599#4163599 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163599

17 years, 9 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Sources are not picked up from snapshots

by wolfc

Or mvn package -Ddownload.source So I keep confusing the options. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163597#4163597 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163597

17 years, 9 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBTHREE-1423 Test case for @RemoteBinding

by jaikiran

By the way, the @LocalBinding/@LocalHomeBinding/@RemoteHomeBinding are working fine. Do you want me to open a JIRA in JBossMetadata for tracking the @RemoteBinding issue? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163593#4163593 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163593

17 years, 9 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: Transaction Status.STATUS_ROLLEDBACK

by mark.little＠jboss.com

Which version of TS are you using BTW? A case of deja vu made me check the code and it seems that now we won't throw IllegalStateException. http://jira.jboss.com/jira/browse/JBTM-56 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163586#4163586 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163586

17 years, 9 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-dev-forums July 2008