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

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Weird deadlock I had today...

by timfox

Increased to 1 million messages and test still passes | Thread Thread-10 finished sending in 603769 milliseconds | Thread Thread-18 finished sending in 604207 milliseconds | Thread Thread-9 finished sending in 605579 milliseconds | Thread Thread-17 finished sending in 605947 milliseconds | Thread Thread-8 finished sending in 608785 milliseconds | Thread Thread-16 finished sending in 609078 milliseconds | Thread Thread-19 finished sending in 611433 milliseconds | Thread Thread-11 finished sending in 613736 milliseconds | Thread Thread-7 finished sending in 615404 milliseconds | Thread Thread-14 finished sending in 615485 milliseconds | Thread Thread-15 finished sending in 615514 milliseconds | Thread Thread-6 finished sending in 615672 milliseconds | Thread Thread-5 finished sending in 678608 milliseconds | Thread Thread-13 finished sending in 678615 milliseconds | Thread Thread-21 finished sending in 678629 milliseconds | Thread Thread-20 finished sending in 680410 milliseconds | Thread Thread-4 finished sending in 680474 milliseconds | Thread Thread-12 finished sending in 680461 milliseconds | Total Time: 680485 milliseconds what represented 1205 per second | main 10:26:02,531 WARN [RemotingConnectionImpl] The conn has been closed by the server | main 10:26:02,689 WARN [RemotingConnectionImpl] The conn has been closed by the server | main 10:26:02,689 WARN [RemotingConnectionImpl] The conn has been closed by the server | main 10:26:02,690 WARN [RemotingConnectionImpl] The conn has been closed by the server | main 10:26:02,690 WARN [RemotingConnectionImpl] The conn has been closed by the server | main 10:26:02,690 WARN [RemotingConnectionImpl] The conn has been closed by the server | main 10:26:02,691 WARN [RemotingConnectionImpl] The conn has been closed by the server | main 10:26:02,691 WARN [RemotingConnectionImpl] The conn has been closed by the server | Full thread dump Java HotSpot(TM) Server VM (1.5.0_13-b05 mixed mode): | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194285#4194285 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194285

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Weird deadlock I had today...

by timfox

Hmm, I tried with no changes (50000 messages) and the test passes for me. I increased messages to 200000 and the test still passes for me.... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194279#4194279 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194279

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2.0 Strict ordering via ordering groups

by ataylor

good idea, that solves it and makes it simpler as well. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194277#4194277 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194277

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Weird deadlock I had today...

by timfox

Assuming you meant it had to wait for the backlog of commands on the connection to be processed rather than completions, then a couple of observations. I notice you have sync on persistent set to true on server, but set to false on the connection factory. I'm not sure if that makes sense (it might cause backlogs), perhaps we should disallow that combination. What happens if you have sync on send set on the session factory too? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194273#4194273 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194273

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2.0 Strict ordering via ordering groups

by timfox

Why not pin groups to consumers irrespective of whether they're started or not? I think that would make more sense anyway, e.g. with a pool of MDBs View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194267#4194267 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194267

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Task Management component?

by camunda

Cool, I am waiting for more :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194242#4194242 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194242

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2.0 Strict ordering via ordering groups

by ataylor

actually, calling start as a blocking call won't make a difference since the sender will probably be on different sessions. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194228#4194228 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194228

17 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: java.util.logging Bridge Component

by scott.stark＠jboss.org

Maybe there will be one less logging api in the future: "log4j-dev(a)logging.apache.org" wrote : | On Dec 3, 2008, at 5:41 AM, Ceki Gulcu wrote: | | > Hello, | > | > As you are probably aware, more and more projects are adopting the | > SLF4J API. I would venture say that SLF4J's adoption rate is roughly | > equivalent to that of log4j itself. Although the SLF4J API is not | > perfect, most SLF4J users seem to be extremely happy with it. | > | > Harry Metske synthesized various logging paths in JSPWiki | > | > https://issues.apache.org/jira/secure/attachment/12394188/jspwiki-log.odp | > | > I was taken aback by the picture he paints. I think we as log4j | > committers owe it to Java developers to propose a saner logging model. | > | > Given the multiplicity of logging APIs in the Java world, I propose | > that log4j implement the SLF4J API directly. This can be done in the | > next version of log4j, say 1.3 or 2.0. | > | > Unfortunately, the adoption of the SLF4J API by log4j will be break | > 100% compatibility with existing log4j clients. More precisely, | > logging statements passing java.lang.Object as the message parameter | > will need to be changed to java.lang.String. Assuming that the | > proportion of logging statements using objects instead string is | > extremely small, comparatively few users will be affected. More | > importantly, in my experience, even very large projects can be | > migrated to the SLF4J API within half an hour. | > | > There is even a tool called slf4j-migrator to help with such | > migration [1]. | > | > Is there support for my proposal? | > | > [1] http://www.slf4j.org/migrator.html | | > -- Ceki GÃ¼lcÃ¼ | > | | I've logged this issue as https://issues.apache.org/jira/browse/LOG4J2-27 and Scott's desire for increased support for properties as https://issues.apache.org/jira/browse/LOG4J2-28. I've attached a PDF version of the referenced OpenOffice file to LOG4J2-27. | | If the proposal is that direct support for SLF4J be considered as a potential feature of log4j 2.0 as previously described on this list (a designed for Java 5 replacement for log4j 1.x with fine grained concurrency), then LOG4J2-27 captures that potential feature for consideration at the proper time. | | If the proposal is to create a branch of the log4j 1.2 code base that directly implements SLF4J, that is a different matter. I could recount all sorts of previous discussions on the issues involved, but I don't want to do that if that is not the proposal. | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194213#4194213 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194213

17 years, 4 months

1
0
0 / 0

[Design of JBoss ESB] - Cluster of JBoss ESB?

by jsports

will JBoss ESB add cluster feature? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194209#4194209 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194209

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Weird deadlock I had today...

by timfox

"clebert.suconic(a)jboss.com" wrote : What happened on my test was a call to close taking longer than PING_TIME. | | The test was sending 100 messages, in 10 threads. All the sends were being performed asynchronously, and every PersistentMessage sent was syncing the page (it would be same effect on Journal if using NIO). When close was called, it had to wait the pending commands to finish, what took longer than the PING_TIME. | | But you shouldn't have a DeadLock on that case.. right? | | Why are you waiting for completion at close? For non transactional persistent messages you should be waiting for completion at send time, and for transactional at commit. In no case should you be waiting for completion at close. It's crucial that all commands can execute quickly so they prevent the remoting thread from executing other commands View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194207#4194207 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194207

17 years, 4 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 December 2008