On Tue, Jul 11, 2017 at 8:47 AM, Thusitha Thilina Dayaratne < thusit...@wso2.com> wrote:
> Hi Shafreen, > > IMHO it would be much easier if that functionality os provided by the > messaging layer. Otherwise, each and every MessageProcessors need to > implement that logic. Therefore wouldn't it be nice to implement the > getCopyOfFullMessageBody[1] method from carbon-messaging? > Understood :). I suppose it is sort of a common requirement for all the messageProcessors. Hence, it is good to have it in CarbonMessage itself. Let's see what other's opinion as well. > > [1] - https://github.com/wso2/carbon-messaging/blob/master/ > components/src/main/java/org/wso2/carbon/messaging/CarbonMessage.java#L223 > > Thanks > Thusitha > > On Mon, Jul 10, 2017 at 4:35 PM, Shafreen Anfar <shafr...@wso2.com> wrote: > >> Hi Thusitha, >> >> On Mon, Jul 10, 2017 at 11:37 AM, Thusitha Thilina Dayaratne < >> thusit...@wso2.com> wrote: >> >>> Hi Shafreen, >>> >>> +1 for the proposed implementation. In MSF4J point of view, we are >>> wrapping the carbon message with MSF4J Request/Response objects and use the >>> underlying messaging methods provided to retrieve/write back data in/out/. >>> >>> Are we considering a getting a message body clone with the re >>> architrecture? >>> >> >> Isn't cloning of the message body should be done using some util method >> at MessageProcessor level ? >> >> >>> >>> Thanks >>> Thusitha >>> >>> On Fri, Jul 7, 2017 at 6:18 PM, Shafreen Anfar <shafr...@wso2.com> >>> wrote: >>> >>>> Hi All, >>>> >>>> In addition to considering all the facts presented above, I also talked >>>> to each transport developer who actually came up with different types of >>>> carbon-messages. Based on those discussion I came up with below design. >>>> >>>> Originally, CarbonMessage is designed to carry data between two >>>> components and I believe it should stay the same. However, it should be >>>> able carry data relevant to each component. For instance, in JMS case, it >>>> should be able carry a map for map messages where as in websockets case it >>>> should be able carry a string. >>>> >>>> Therefore, I thought of creating a CarbonMessage with java generics. >>>> Then we can extend it accordingly. >>>> >>>> >>>> >>>> As you can see above, we can provide a DefaultCarbonMessage >>>> implementation. However, in HTTP case, we have done some specific >>>> implementation to optimize the transport. At the moment those logic also >>>> resides inside the abstract CarbonMessage. With the new design we can >>>> simply move them to something like ByteCarbonMessage<ByteBuffer>. >>>> >>>> I believe with this design we can have proper abstraction while >>>> reducing number of redundant carbon messages. >>>> >>>> >>>> On Thu, Jul 6, 2017 at 12:16 AM, Chanaka Fernando <chana...@wso2.com> >>>> wrote: >>>> >>>>> It seems there is room to improve the current CarbonMessage >>>>> implementation. Following are few main areas where we can improve its >>>>> functionality. >>>>> >>>>> - At the moment there are too many ways to get the message body >>>>> from the CarbonMessage >>>>> - getMessageBody() >>>>> - getInputStream() - This is a http specific impl. >>>>> - getMessageDateSource() >>>>> >>>>> The above 3 methods serve 3 different purposes. This design has been >>>>> done mainly thinking about the HTTP messages. In a message passthrough >>>>> scenario, content is kept in the content queue and accessed as a stream. >>>>> When the message content is accessed within intermediate layer (like >>>>> ballerina), it will be retrieved through messageDataSource. >>>>> >>>>> - There are too many types of CarbonMessages in carbon-messaging >>>>> that are only used by a specific transport implementation >>>>> - BinaryCarbonMessage >>>>> - ControlCarbonMessage >>>>> - DefaultCarbonMessage >>>>> - MapCarbonMessage >>>>> - SerializableCarbonMessage >>>>> - StatusCarbonMessage >>>>> - StreamingCarbonMessage >>>>> - TextCarbonMessage >>>>> >>>>> >>>>> - Most of above CarbonMessages do not adhere to the contract that >>>>> is imposed by the CarbonMessage interface. >>>>> >>>>> I agree on the fact that we need to refactor these different types of >>>>> CarbonMessage implementations. I think what Asitha suggested is a viable >>>>> approach to handle different types of messages. >>>>> >>>>> Considering these facts, I believe we should refactor CarbonMessage >>>>> before others starting using it in their implementations. Please let us >>>>> know your thoughts as well :) >>>>> >>>>> +1 for refactoring the carbon message and relevant implementations to >>>>> support non-HTTP use cases. In the meantime, we should support HTTP >>>>> messaging in an efficient manner since that will be the mostly used >>>>> scenario of ballerina. >>>>> >>>>> On Wed, Jul 5, 2017 at 4:55 PM, Irunika Weeraratne <irun...@wso2.com> >>>>> wrote: >>>>> >>>>>> Hi Shafreen and Asitha, >>>>>> In the first place, they were introduced after a long discussion in >>>>>> WebSocket scenarios. This was because when the WebSocket messages are >>>>>> arrived to transport level we already knew what kind of message it is. >>>>>> Eg: Text, Binary, Control, Status >>>>>> >>>>>> So I made sense to create the same type of carbon message in the >>>>>> transport. Then carbon message types were used to identify the scenarios >>>>>> we >>>>>> had to address in the application layer. >>>>>> Eg: If the carbon message is an instance of TextCarbonMessage we know >>>>>> what to do in the first place. Also converting text into byte buffer in >>>>>> the >>>>>> transport and then converting it again into text in the application layer >>>>>> doesn't make sense. >>>>>> >>>>>> Because of that, those message types were introduced. IMO while we >>>>>> reduce the no. of carbon message types we might need to keep some of the >>>>>> types because it will affect the performance. >>>>>> Also, we can always override the methods in default carbon message if >>>>>> in order to work with default scenarios. >>>>>> >>>>>> WDYT? >>>>>> >>>>>> Thanks, >>>>>> Irunika >>>>>> >>>>>> *Irunika Weeraratne* >>>>>> *Software Engineer | WSO2, Inc. <http://wso2.com/>* >>>>>> *Email : irun...@wso2.com <irun...@wso2.com>* >>>>>> *LinkedIn : https://lk.linkedin.com/in/irunika >>>>>> <https://lk.linkedin.com/in/irunika>* >>>>>> *Mobile : +94712403314 <071%20240%203314>* >>>>>> *Lean . Enterprise . Middleware* >>>>>> >>>>>> >>>>>> On Wed, Jul 5, 2017 at 3:54 PM, Asitha Nanayakkara <asi...@wso2.com> >>>>>> wrote: >>>>>> >>>>>>> Hi Shafreen, >>>>>>> >>>>>>> I would suggest having a single Carbon Message with the option to >>>>>>> set different types of data sources as the data source for the message. >>>>>>> For >>>>>>> that, we might need to go through the existing other message types and >>>>>>> think what kind of functionality to be added to carbon message. If our >>>>>>> intention is not to extend carbon message, we can make it a final >>>>>>> class. If >>>>>>> not we have to design it to be extended by other users. >>>>>>> >>>>>>> When reading the payload multiple times (building the message) we >>>>>>> need to clone messages (since data is represented as a stream). In pass >>>>>>> through scenarios, we should avoid cloning the message and use the >>>>>>> stream >>>>>>> once. >>>>>>> IMO we can implement this functionality by way of having package >>>>>>> level methods for transport to read from the internal blocking queue and >>>>>>> write to the output stream. If we invoke other public methods they will >>>>>>> make a clone of the message data and use. This way we avoid unnecessary >>>>>>> cloning in a pass-through scenario. And reading from the blocking queue >>>>>>> can >>>>>>> only be done from the transport. Outside users have to use message data >>>>>>> source to read the content, which might clone the data. >>>>>>> >>>>>>> WDYT? >>>>>>> >>>>>>> Regards, >>>>>>> Asitha >>>>>>> >>>>>>> On Wed, Jul 5, 2017 at 3:14 PM, Shafreen Anfar <shafr...@wso2.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> It seems there is room to improve the current CarbonMessage >>>>>>>> implementation. Following are few main areas where we can improve its >>>>>>>> functionality. >>>>>>>> >>>>>>>> - At the moment there are too many ways to get the message body >>>>>>>> from the CarbonMessage >>>>>>>> - getMessageBody() >>>>>>>> - getInputStream() - This is a http specific impl. >>>>>>>> - getMessageDateSource() >>>>>>>> >>>>>>>> >>>>>>>> - There are too many types of CarbonMessages in >>>>>>>> carbon-messaging that are only used by a specific transport >>>>>>>> implementation >>>>>>>> - BinaryCarbonMessage >>>>>>>> - ControlCarbonMessage >>>>>>>> - DefaultCarbonMessage >>>>>>>> - MapCarbonMessage >>>>>>>> - SerializableCarbonMessage >>>>>>>> - StatusCarbonMessage >>>>>>>> - StreamingCarbonMessage >>>>>>>> - TextCarbonMessage >>>>>>>> >>>>>>>> >>>>>>>> - Most of above CarbonMessages do not adhere to the contract >>>>>>>> that is imposed by the CarbonMessage interface. >>>>>>>> >>>>>>>> Considering these facts, I believe we should refactor CarbonMessage >>>>>>>> before others starting using it in their implementations. Please let us >>>>>>>> know your thoughts as well :) >>>>>>>> >>>>>>>> -- >>>>>>>> Regards, >>>>>>>> *Shafreen* >>>>>>>> Software Engineer >>>>>>>> WSO2 Inc >>>>>>>> Mobile : 077-556-395-1 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *Asitha Nanayakkara* <http://asitha.github.io/> >>>>>>> Senior Software Engineer >>>>>>> WSO2, Inc. <http://wso2.com/> >>>>>>> Mob: +94 77 853 0682 <+94%2077%20853%200682> >>>>>>> [image: https://wso2.com/signature] <https://wso2.com/signature> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Thank you and Best Regards, >>>>> Chanaka Fernando >>>>> Senior Technical Lead >>>>> m: +94 773337238 <+94%2077%20333%207238> >>>>> https://wso2.com <https://wso2.com/signature> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Regards, >>>> *Shafreen* >>>> Software Engineer >>>> WSO2 Inc >>>> Mobile : 077-556-395-1 >>>> >>> >>> >>> >>> -- >>> Thusitha Dayaratne >>> WSO2 Inc. - lean . enterprise . middleware | wso2.com >>> >>> Mobile +94712756809 <+94%2071%20275%206809> >>> Blog alokayasoya.blogspot.com >>> About http://about.me/thusithathilina >>> <http://wso2.com/signature> >>> >>> >> >> >> -- >> Regards, >> *Shafreen* >> Software Engineer >> WSO2 Inc >> Mobile : 077-556-395-1 >> > > > > -- > Thusitha Dayaratne > WSO2 Inc. - lean . enterprise . middleware | wso2.com > > Mobile +94712756809 <+94%2071%20275%206809> > Blog alokayasoya.blogspot.com > About http://about.me/thusithathilina > <http://wso2.com/signature> > > -- Regards, *Shafreen* Software Engineer WSO2 Inc Mobile : 077-556-395-1
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
