September 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Closed: (JBMESSAGING-228) Re-enable DistributedTopicTest testDistributedTopic_2() and testDistributedTopic_4()

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-228?page=all ] Tim Fox closed JBMESSAGING-228. ------------------------------- Resolution: Done > Re-enable DistributedTopicTest testDistributedTopic_2() and testDistributedTopic_4() > ------------------------------------------------------------------------------------- > > Key: JBMESSAGING-228 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-228 > Project: JBoss Messaging > Issue Type: Task > Components: Tests and Performance > Reporter: Ovidiu Feodorov > Assigned To: Tim Fox > Fix For: 1.2.0.Alpha1 > > > I have overridden org.jboss.test.messaging.core.distributed.topic.base.DistributedTopicTestBase's testDistributedTopic_2() and testDistributedTopic_4(() > because they don't match the current assumption that a Channel has only one receiver, and still we want a clean test run. > Adjust tests accordingly and enable them when this assumption will be better wired into the core and DistributedTopic reviewed. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBMESSAGING-200) Complete XA transaction recovery

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-200?page=all ] Tim Fox closed JBMESSAGING-200. ------------------------------- Resolution: Done Fix Version/s: 1.2.0.Alpha1 (was: 1.2.0.Beta1) > Complete XA transaction recovery > -------------------------------- > > Key: JBMESSAGING-200 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-200 > Project: JBoss Messaging > Issue Type: Task > Components: JMS Facade > Reporter: Tim Fox > Assigned To: Tim Fox > Priority: Critical > Fix For: 1.2.0.Alpha1 > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Complete XA transaction recovery. > Most of the work is already in place for this. > The remaining pars mainly revolve around integrating with Transaction Managers e.g. Arjuna (and maybe others!) so they can obtain a handle to the XAResource in order to carry out recovery. > The mechanism for this is not specified and so will vary from Transaction Manager to transaction manager. We need to supply wrappers for each popular Transaction Manager. > We also need to complete the tests for this. (Perhaps Arjuna already has some tests we can re-use?) -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBMESSAGING-199) Fix or mothball remotetopic so it does not require multiple deliveries per message reference

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-199?page=all ] Tim Fox closed JBMESSAGING-199. ------------------------------- Resolution: Done > Fix or mothball remotetopic so it does not require multiple deliveries per message reference > -------------------------------------------------------------------------------------------- > > Key: JBMESSAGING-199 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-199 > Project: JBoss Messaging > Issue Type: Task > Components: Messaging Core Distributed Support > Reporter: Tim Fox > Assigned To: Tim Fox > Fix For: 1.2.0.Alpha1 > > > Re-implement remote topic to be a router with multiple channels - one per peer. > This means it is not necessary to store receiver id persistently and there is only one delivery per reference per channel. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBMESSAGING-197) Refactor Channel, Distributor etc so there is only one receiver per channel

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-197?page=all ] Tim Fox closed JBMESSAGING-197. ------------------------------- Resolution: Done > Refactor Channel, Distributor etc so there is only one receiver per channel > --------------------------------------------------------------------------- > > Key: JBMESSAGING-197 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-197 > Project: JBoss Messaging > Issue Type: Task > Components: Messaging Core > Reporter: Tim Fox > Assigned To: Tim Fox > Fix For: 1.2.0.Alpha1 > > Original Estimate: 3 days > Remaining Estimate: 3 days > > Currently channels, allow multiple receivers. > This is unnecessary and adds extra complecity. > There is no need for a channel to ever have more than one active delivery per message reference at any one time. > Channel should be refactored to only have one receiver. > This gives us a much smaller and simpler base building block. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBMESSAGING-192) Refactor Replicator so it won't be forced to provide noop implementation for Distributor's methods.

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-192?page=all ] Tim Fox closed JBMESSAGING-192. ------------------------------- Resolution: Done > Refactor Replicator so it won't be forced to provide noop implementation for Distributor's methods. > --------------------------------------------------------------------------------------------------- > > Key: JBMESSAGING-192 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-192 > Project: JBoss Messaging > Issue Type: Task > Components: Messaging Core Distributed Support > Affects Versions: 1.0.0 alpha PR2 (clustered) > Reporter: Ovidiu Feodorov > Assigned To: Tim Fox > Priority: Minor > Fix For: 1.2.0.Alpha1 > > > A replicator doesn't really need to implement org.jboss.messaging.core.Router, since its receivers are remote. It only needs support for > Set handle(DeliveryObserver observer, Routable routable, Transaction transaction) > However, currently the easiest way to plug a Replicator into the ChannelSupport implementation is to declare it Router. Refractor this and split the Router interface (and ChannelSupport implementation) in two distinct parts: MultiReceiver (or some other name) and Distributor. > Look for UnsupportedOperationException in org.jboss.messaging.core.distributed.replicator.Replicator. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] Reopened: (JBMESSAGING-425) Naming of Pipe and Distributed Pipe

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-425?page=all ] Tim Fox reopened JBMESSAGING-425: --------------------------------- > Naming of Pipe and Distributed Pipe > ----------------------------------- > > Key: JBMESSAGING-425 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-425 > Project: JBoss Messaging > Issue Type: Task > Affects Versions: 1.0.1.CR3 > Reporter: Tim Fox > Assigned To: Tim Fox > Priority: Minor > Fix For: 1.2.0.Alpha1 > > > The "Pipe" instance is basically a reliable channel that forwards from input to output. > However the "DistributedPipe" is not a channel at all and seems to be just an abstraction of a remote connection, so seems to have no relation whatsoever to a "Pipe". > Suggestion is to rename these classes to something that makes a bit more sense and is less confusing. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] Reopened: (JBMESSAGING-422) Move channel mapper logic into Queue, Topic, Subscription classes

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-422?page=all ] Tim Fox reopened JBMESSAGING-422: --------------------------------- > Move channel mapper logic into Queue, Topic, Subscription classes > ----------------------------------------------------------------- > > Key: JBMESSAGING-422 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-422 > Project: JBoss Messaging > Issue Type: Task > Reporter: Tim Fox > Assigned To: Tim Fox > Fix For: 1.2.1 > > > Much of the logic in the channel mapper is very non OO and should be moved into it's appropriate places in the relevant Queue, Topic or Subscription classes. > It's currently a bit of a mess. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] Reopened: (JBMESSAGING-414) Simplify delivery hierarchy

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-414?page=all ] Tim Fox reopened JBMESSAGING-414: --------------------------------- > Simplify delivery hierarchy > --------------------------- > > Key: JBMESSAGING-414 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-414 > Project: JBoss Messaging > Issue Type: Task > Affects Versions: 1.0.1.CR2 > Reporter: Tim Fox > Assigned To: Tim Fox > Fix For: 1.2.0.Alpha1 > > > The current delivery hierarchy seems over complex. > A delivery only ever comes from one Receiver so the all we need is a: > Delivery interface > and > SimpleDelivery implementation > Methods like acknowledge(), cancel() should be in the Delivery interface. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] Reopened: (JBMESSAGING-404) Remove Channel::deliver(Receiver r) method

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-404?page=all ] Tim Fox reopened JBMESSAGING-404: --------------------------------- > Remove Channel::deliver(Receiver r) method > ------------------------------------------ > > Key: JBMESSAGING-404 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-404 > Project: JBoss Messaging > Issue Type: Task > Reporter: Tim Fox > Assigned To: Tim Fox > Fix For: 1.2.0.Alpha1 > > Original Estimate: 2 days > Remaining Estimate: 2 days > > This method is used to effectively do a synchronous receive() on a channel. > The functionality could be more simply implemented by doing adding a MessageReference receive() method. > This would also help in a clustered environment since we would have one less network RPC. > Most of the complexity here is in updating tests. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] Reopened: (JBMESSAGING-361) WireFormatTest.testNullResponse(), testDeactivateResponse() fragments invalid

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-361?page=all ] Tim Fox reopened JBMESSAGING-361: --------------------------------- > WireFormatTest.testNullResponse(), testDeactivateResponse() fragments invalid > ----------------------------------------------------------------------------- > > Key: JBMESSAGING-361 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-361 > Project: JBoss Messaging > Issue Type: Sub-task > Components: JMS Facade > Affects Versions: 1.0.0 > Reporter: Ovidiu Feodorov > Assigned To: Tim Fox > Fix For: 1.2.0.Alpha1 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > Switching to jboss-serialization 1.0.0.CR7 uncovered what apparently seems to be an invalid test section in WireFormatTest > public void testNullResponse() throws Exception > { > MessagingMarshallable mm = new MessagingMarshallable((byte)77, null); > InvocationResponse resp = new InvocationResponse(null, mm, false, null); > ByteArrayOutputStream bos = new ByteArrayOutputStream(); > JBossObjectOutputStream oos = new JBossObjectOutputStream(bos); > > wf.write(resp, oos); > oos.flush(); > > ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray()); > DataInputStream dis = new DataInputStream(bis); > > // First byte should be version > assertEquals(77, dis.readByte()); > ........... > } > It doesn't make sense to me to write stuff to a JBossObjectOutputStream and then try to read the serialized content using a DataInputStream, and yet this is what this test section does. JBoss Serialization doesn't guarantee this in its public contract. > Excerpt form a conversation with Clebert: > flanker707: Does JBossSerialization guarantee that something written with on a JBossObjectOutuptStream can be read with DataInputStream? > Clebert Suconic: no... I didn't mean to > flanker707: is this in the public contract? > Clebert Suconic: If you use the same thing with ObjectInputStream.. you would have the same problem > testNullResponse(), testDeactivateResponse() sections commented out until clarified. -- 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, 8 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 September 2006