March 2009 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - org.jboss.messaging.default-call-timeout

by timfox

Anyone know why this has appeared in ClientSessionFactoryImpl: | static | { | long value; | try | { | // This system-variable is used on tests. | value = Long.parseLong(System.getProperty("org.jboss.messaging.default-call-timeout", "30000")); | } | catch (Exception e) | { | | // Security Managemen is probably in use on the VM | value = 30000; | } | | DEFAULT_CALL_TIMEOUT = value; | } | Is it really the appropriate place to put it? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218942#4218942 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218942

17 years

1
0
0 / 0

[Design of JBossCache] - Re: Lock striping broken for Second Level Cache use case

by manik.surtani＠jboss.com

This is always going to be a problem when you have shared locks, and increasing concurrency level will only mitigate the problem, not resolve it altogether. There is, unfortunately, a fundamental problem with a lock-per-fqn scheme, in that the lock needs to exist somewhere, even on a non-existent Fqn (for creates, or removes on nodes that don't exist). We had this problem in PL since locks (per node) were stored in the node, and it involved all sorts of hacks to get it to work, severely degrading performance and still exposing a few race conditions. Not pleasant stuff. Let me think about alternate approaches here, and what can be done. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218939#4218939 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218939

17 years

1
0
0 / 0

[Design of JBoss jBPM] - ant task for starting jboss

by tom.baeyens＠jboss.com

in the context of running hudson platform independent, i was searching for the ant task to start jboss and i found it. the ant task spawns a separate jboss process and it listens to the console as long as it doesn't see the message: " started in " so if someone wants to give it a go to leverage this ant task in our current build, let me know and I'll make the classes available somewhere View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218919#4218919 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218919

17 years

1
0
0 / 0

[Design of JBoss jBPM] - config generation committed

by tom.baeyens＠jboss.com

config generation committed View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218915#4218915 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218915

17 years

1
0
0 / 0

[Design of JBoss Web Services] - Re: Remoting 3 and HTTP client

by alessio.soldano＠jboss.com

"trustin" wrote : Hi Alessio, | | Remoting 3.1 will have HTTP transport, although it's not going to be backward-compatible in wire-level. Release date is not sure yet unfortunately. | | As an alternative, I'd like to suggest you to try Netty HTTP codec - http://www.jboss.org/netty/ | | Check the HTTP client / server example in the documentation section - http://tinyurl.com/5w3fpb (HttpClient, HttpClientPipelineFactory, and HttpResponseHandler are all you need to see.) | | It's supposed to be very efficient in dealing with large number of concurrent HTTP connections thanks to the effectiveness and robustness of its core. Thanks Trustin, this is exactly the kind of suggestion I expected from you guys ;-) I'll try Netty first for sure. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218900#4218900 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218900

17 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Semantic on Session.stop and MessageHandler

by timfox

Yes, once session.stop() has returned it should be guaranteed no more messages will be received on a handler until it's started again. However we shouldn't wait for all messages in the buffer to be processed - this might take a long time. We should only wait for the currently executing one to complete. The same behaviour should be on close() and setMessageHandler(null). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218893#4218893 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218893

17 years

1
0
0 / 0

[Design of JBoss Web Services] - Re: Remoting 3 and HTTP client

by richard.opalka＠jboss.com

It's not clear to me what's going to happen with remoting? Is it going to remove client side abstraction or is it going to change binary protocol in incompatible way so using it cross different AS versions is not an option anymore? Do we need to remove remoting dependency from our client side? If we need to remove dependency on remoting and provide pluggible client transport layer then note that we have nontrivial dependencies on JBoss Remoting: * FastInfosetConnectionHTTP * JsonConnectionHTTP * SOAPProtocolConnectionHTTP * SOAPProtocolConnectionJMS i.e. new transport should allow us to do http(s) & jms messages exchange at least. We should also consider socket reuse (this is issue of our current implementation - many customers are complaining about it) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218887#4218887 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218887

17 years

1
0
0 / 0

[Design of JBoss Web Services] - Re: Remoting 3 and HTTP client

by trustin

Hi Alessio, Remoting 3.1 will have HTTP transport, although it's not going to be backward-compatible in wire-level. Release date is not sure yet unfortunately. As an alternative, I'd like to suggest you to try Netty HTTP codec - http://www.jboss.org/netty/ Check the HTTP client / server example in the documentation section - http://tinyurl.com/5w3fpb (HttpClient, HttpClientPipelineFactory, and HttpResponseHandler are all you need to see.) It's supposed to be very efficient in dealing with large number of concurrent HTTP connections thanks to the effectiveness and robustness of its core. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218873#4218873 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218873

17 years

1
0
0 / 0

[Design of JBossCache] - Lock striping broken for Second Level Cache use case

by bstansberry＠jboss.com

The unit test dukehoops has posted on http://www.jboss.org/index.html?module=bb&op=viewtopic&t=151524&start=20 is showing the fundamental problem with using lock striping. Eventually you are going to get failures due to deadlocks as different txs acquire different stripes. But with some of the stuff 2LC does, particularly if query caching is enabled and a shared cache is used, the probability is quite high. Assume you have a tx (all Fqns below are for example only): writes to /ENTITIES/Contacts/1 locks a stripe writes to /ENTITIES/Contacts/2 locks a stripe beforeCompletion() by Hibernate and JBC afterCompletion() by Hibernate tries to update the timestamps cache: non-tx write to /TIMESTAMPS/Contacts For sure within a relatively small # of txs, some Fqn /ENTITIES/Contacts/x is going to map to the stripe needed by /TIMESTAMPS/Contacts. Therafter, no tx involving that Fqn is every going to succeed. The test dukehoops submitted runs 200 tx's involving about 205 fqns (plus structure). It fails with the default 500 concurrencyLevel 100% of the time. If I increase concurrencyLevel to 5000, it fails with about 7500 txs, maybe less. There needs to be some sort of lock-per-fqn scheme here. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218836#4218836 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218836

17 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Semantic on Session.stop and MessageHandler

by clebert.suconic＠jboss.com

I am writing this following test on ClientConsumerTest. If I just call session.stop, the MessageHandler keeps being called until all the messages on the clientBuffer are consumed, but if I call consumer.setHandler(null) I would have the behaviour I expected. So.. what's the expected semantic from the user's perspective? Shouldn't session.stop prevent any messages being delivered to the handler after stop is called? | public void testStopConsumer() throws Exception | { | ClientSessionFactory sf = new ClientSessionFactoryImpl(new TransportConfiguration("org.jboss.messaging.core.remoting.impl.invm.InVMConnectorFactory")); | | final ClientSession session = sf.createSession(false, true, true); | | session.createQueue(QUEUE, QUEUE, null, false, false); | | ClientProducer producer = session.createProducer(QUEUE); | | final int numMessages = 100; | | for (int i = 0; i < numMessages; i++) | { | ClientMessage message = createMessage(session, "m" + i); | producer.send(message); | } | | final ClientConsumer consumer = session.createConsumer(QUEUE, null, true); | | session.start(); | | final CountDownLatch latch = new CountDownLatch(10); | | // Message should be in consumer | | class MyHandler implements MessageHandler | { | boolean failed; | boolean started = true; | | public void onMessage(final ClientMessage message) | { | | try | { | if (!started) | { | failed = true; | } | | latch.countDown(); | | if (latch.getCount() == 0) | { | started = false; | session.stop(); | consumer.setMessageHandler(null); // the test will fail if we comment out this line | } | | message.acknowledge(); | } | catch (Exception e) | { | } | } | } | | MyHandler handler = new MyHandler(); | | consumer.setMessageHandler(handler); | | latch.await(); | | Thread.sleep(100); | | assertFalse(handler.failed); | | // Make sure no exceptions were thrown from onMessage | assertNull(consumer.getLastException()); | | for (int i = 0; i < 90; i++) | { | ClientMessage msg = consumer.receive(1000); | assertNotNull(msg); | msg.acknowledge(); | } | | assertNull(consumer.receiveImmediate()); | | session.close(); | } | | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218814#4218814 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218814

17 years

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 March 2009