September 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Assigned: (JBMESSAGING-269) Review ChannelMapper interface for possible functionality separation

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-269?page=all ] Tim Fox reassigned JBMESSAGING-269: ----------------------------------- Assignee: Tim Fox > Review ChannelMapper interface for possible functionality separation > -------------------------------------------------------------------- > > Key: JBMESSAGING-269 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-269 > Project: JBoss Messaging > Issue Type: Task > Components: Messaging Core > Reporter: Ovidiu Feodorov > Assigned To: Tim Fox > Priority: Minor > Fix For: 1.2.1 > > Original Estimate: 3 days > Remaining Estimate: 3 days > > Currently, ChannelMapper seem to cram two different sets of concerns (core channel to destination mapping and durable subscription management) under the same interface. Review the interface (and the implementation) in search for a better solution, possibly involving service separation (DurableSubscriptionStore and ChannelMapper). -- 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 Assignee: Tim Fox (was: Ovidiu Feodorov) > 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.1 > > 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-414) Simplify delivery hierarchy

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-414?page=all ] Tim Fox closed JBMESSAGING-414. ------------------------------- Resolution: Done > 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.1 > > > 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] Closed: (JBMESSAGING-425) Naming of Pipe and Distributed Pipe

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-425?page=all ] Tim Fox closed JBMESSAGING-425. ------------------------------- Assignee: Tim Fox Resolution: Won't Fix These classes no longer exist > 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.1 > > > 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] Closed: (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 closed JBMESSAGING-422. ------------------------------- Resolution: Done These classes no longer exist > 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] Closed: (JBMESSAGING-310) Investigate whether rw lock on ServerConnectionEndpoint is necessary

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-310?page=all ] Tim Fox closed JBMESSAGING-310. ------------------------------- Resolution: Done It's been removed > Investigate whether rw lock on ServerConnectionEndpoint is necessary > -------------------------------------------------------------------- > > Key: JBMESSAGING-310 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-310 > Project: JBoss Messaging > Issue Type: Task > Reporter: Tim Fox > Assigned To: Tim Fox > Fix For: 1.2.1 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > -- 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-332) Consider how best to factor paging logic out of channel state

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-332?page=all ] Tim Fox closed JBMESSAGING-332. ------------------------------- Resolution: Done Now abstracted out into PagingChannel > Consider how best to factor paging logic out of channel state > ------------------------------------------------------------- > > Key: JBMESSAGING-332 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-332 > Project: JBoss Messaging > Issue Type: Task > Reporter: Tim Fox > Assigned To: Tim Fox > Fix For: 1.2.1 > > Original Estimate: 2 days > Remaining Estimate: 2 days > > Need to consider whether to make paging strategy pluggable and factor current implementation out into a concrete implementation. -- 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: Duplicate Issue Duplicate of 407 > 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.Beta1 > > 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-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: Won't Fix Assignee: Tim Fox (was: Ovidiu Feodorov) Replicator no longer exists in new clustering code base > 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] Closed: (JBMESSAGING-361) WireFormatTest.testNullResponse(), testDeactivateResponse() fragments invalid

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-361?page=all ] Tim Fox closed JBMESSAGING-361. ------------------------------- Resolution: Done > 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