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

[Design of EJB 3.0] - Re: EJBTHREE-1607 Update EJB3.0 Tutorials

by jaikiran

Thanks Andrew. A new run is in progress, will let you know how it goes. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4197507#4197507 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4197507

17 years

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Remoting 3: Decision time...

by david.lloyd＠jboss.com

OK, so I just released Beta2. We need to decide what else, if anything, we need to add before releasing 3.0.0.GA. Right now we've got: * Basic protocol (intended to be a model for implementations, not for primary usage) * Multiplex protocol (this will be the basis of JRPP which is multiplex + SSH + some option negotiation protocol) * A complete discovery API, but no (production-grade) mechanisms yet * Transporters, at least on a basic level (I can envision many more features to add, but this isn't a priority for us) * A complete streaming API (via JBoss Marshalling), but no (production-grade) mechanisms yet Things that are currently scheduled for 3.1 or later and for the supporting projects: * SSH + negotiation protocol to round out the multiplex transport * Discovery mechanism based on SLP (RFC 2608) implementation (this is has an SLP component and a Remoting component) * Streaming mechanisms for Multiplex+SSH * Maybe some generic streaming mechanisms for streaming directly over TCP? * Protocol compatibility layer for older Remoting wire protocols * Discovery mechanism based on JGroups (?) * An improved standalone API to make simple clients and servers be very easy to write * Remoting MC integration * Strategy for creating EJB2, EJB3, Remote JMX, Remote JDBC, Remote JNDI etc. services, including addressing compatibility Inclusion into JBossAS hinges on most (if not all) of the future scheduled tasks being complete as well. What do you guys think? Is 3.0 production ready? Is there a target audience for it as it is right now? I'm inclined to put it out there more or less as it is now, personally, and get a move on the other features I've listed for 3.1, locking in to a 12- or 16-week release cycle. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4197501#4197501 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4197501

17 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-1460 - ScheduledDeliveryTest on JBM 1.4

by gaohoward

Yes this is a bug. The 1460 fix doesn't handle the count correctly. look at the method public void removeAllReferences() throws Throwable { synchronized (lock) { .....//removing all non scheduled msg from memory. deliveringCount.set(0); } //clear sch clearAllScheduledDeliveries(true); So the count will go minus. I should have put it before the deliveringCount.set(0); and the count should be OK. Sorry, I'll correct it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4197498#4197498 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4197498

17 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Failover on LargeMessages

by clebert.suconic＠jboss.com

When sending LargeMessages (server2client), I need to have the masterNode inform the backupNode what's happening on the sending. The process of sending small messages on clustering seems simple to me, as you can do it atomically. You inform the backup about sending the message, and the backup will place it on the buffer. And receiving the confirmation on flow-control is also simple. However on largeMessages this is a little bit different: I - I inform the backup node that I'm starting a MessageSend, so the backup-node will take out the delivery from the queue, and create the LargeMessages. II - I can't just let the backup-node call largeMessageSender.send, or the backup could be running faster than the server. (Running out of Credits first for instance). So I'm currently implementing it in a way the live-node is aways informing the backup-node what position of the LargeMessage is being sent to the client. In case of failure the backup-node will resume from that chunk forward. (of course using the logic that is already in place for packet confirmation). Another option I have is reset everything and start sending large message again from its beginning in case of failure. I will check that option tomorrow. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4197484#4197484 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4197484

17 years

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBTHREE-1607 Update EJB3.0 Tutorials

by ALRubinger

Jaikiran: I've released: JBossAS Maven Plugins 0.1.0 ("example" is 0.1.1) jboss-server-manager:1.0.1.GA These should give you some hard dependencies to rely upon. Please give them a spin in the morning and let me know if they'll be sufficient, I'll be offline for a few days. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4197477#4197477 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4197477

17 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-1460 - ScheduledDeliveryTest on JBM 1.4

by clebert.suconic＠jboss.com

deliveringCount.decrement is being called twice. I did some debugging and deliveringCount become negative at acknowledgeInternal. (I added some System.out to debug it) protected void acknowledgeInternal(Delivery d, Transaction tx, boolean persist) throws Exception | { | | .... | if (!d.isRecovered()) | { | if (deliveringCount.decrement() < 0) | { | System.out.println("Oops... deliveringCount became negative at acknowledgeInternal"); // I added this print here | } | } | | ...... | } | Why the test is asserting for -1? it seems to me the valid condition would be 0, and deliveringCount being decremented to -1 would be a bug? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4197471#4197471 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4197471

17 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-1460 - ScheduledDeliveryTest on JBM 1.4

by clebert.suconic＠jboss.com

BTW: I would fix it myself, but I was a little puzzled to why you are testing for the -1. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4197468#4197468 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4197468

17 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - JBMESSAGING-1460 - ScheduledDeliveryTest on JBM 1.4

by clebert.suconic＠jboss.com

Howard, testRemoveAllReferences was added on JBM 1.4 Branch. //https://jira.jboss.org/jira/browse/JBMESSAGING-1460 | public void testRemoveAllReferences() throws Exception | { | | .... | assertRemainingMessages(-1); // (Why?) | | .... | } | Why assertRemainingMessages for -1 and not 0? The following test after this is failing, as setup aways check for remainingMessages = 0. I'm adding the same check on setUp, so it is more clear the test is failing. I'm reopening the JIRA as the test is failing. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4197467#4197467 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4197467

17 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: FailoverTests consuming a lot of memory...

by clebert.suconic＠jboss.com

"timfox" wrote : "clebert.suconic(a)jboss.com" wrote : | | I'm changing RandomFailoverTest and MultiThreadRandomFailoverTest to disable JMX on Management. | | | | . | | How about fixing management, rather than disabling it in the tests? :) BTW: I"m not disabling Management. I"m just disabling JMX. We should verify if there there is a leak on registering Objects on JMX. (queue... etc) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4197458#4197458 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4197458

17 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: FailoverTests consuming a lot of memory...

by clebert.suconic＠jboss.com

I'm not sure if it's broken yet and JMX is not part of those tests. And I posted a little bit more of information, so we could keep looking to why it happened. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4197454#4197454 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4197454

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 December 2008