For polling inbound endpoints we will be introducing a new parameter
called sequential. (default value is true)
when the sequential value is set to true poll message will be handled with
the running thread itself.
when the sequential value is set to false polled message will be handled
with a new
Following are the main decisions taken in the review meeting held on 28th
July.
Thread pool in Inbound Endpoint
--
Introduce two new parameters to inbound endpoint configuration.
1. Sequenial (default = false)
This is needed to be set to true when it is
Hi all,
In the current implementation of JMS and File inbound EPs all the parameter
are prefixed with transport.jms or transport.vfs. I think we should get rid
of this.
On Fri, Jul 18, 2014 at 11:19 PM, Malaka Silva wrote:
> After the fixes by Ishan coordination seems to be working fine with
>
We need to test the coordination behavior of inbound endpoints and make
sure it executes only on manager and an elected worker node.
@Ishan : Please update the thread once we are done with the
implementation/verification.
On Mon, Apr 28, 2014 at 8:01 AM, Kasun Indrasiri wrote:
>
>
>
> On Mon, A
On Mon, Apr 28, 2014 at 7:20 AM, Malaka Silva wrote:
> Hi Kasun,
>
> Is there any reason why sequence is added as a different entry?
>
> Initially I thought about having inline message flows with in an inbound
config itself. May be it is more clear to have it as a reference.
I'm +1 for the syntax
Hi Kasun,
Is there any reason why sequence is added as a different entry?
Current
http://ws.apache.org/ns/synapse";
name="MyVFSListenerEP"
protocol="vfs" interval="5" suspend="false">
/home/malaka/work/vfs/files
ftp://malaka:malaka@127.0.0.1/home/malaka/wor
Great :)
Thanks
Suho
On Fri, Apr 25, 2014 at 8:33 PM, Malaka Silva wrote:
> Hi Suho,
>
> That is the main idea. We are moving the message build and sequence
> injection part to a handle for VFS and Inbound.
>
> Anyone can reuse this and get the raw output.
>
> Best Regards,
> Malaka
>
>
> On F
Hi Suho,
That is the main idea. We are moving the message build and sequence
injection part to a handle for VFS and Inbound.
Anyone can reuse this and get the raw output.
Best Regards,
Malaka
On Fri, Apr 25, 2014 at 5:44 PM, Sriskandarajah Suhothayan wrote:
> Thanks, This code reuse is very u
Thanks, This code reuse is very useful.
CEP team will start integrating when this its ready.
Regards
Suho
On Fri, Apr 25, 2014 at 4:24 PM, Kasun Indrasiri wrote:
> Hi Suho,
>
> As per the offline chat we had, we did change the design so that we can
> obtain the native format and we can registe
Hi Suho,
As per the offline chat we had, we did change the design so that we can
obtain the native format and we can register a handler which can build the
message in to any required format. Malaka is working on applying these
changes and lets do a review once we have it up and running.
On Mon,
Great :)
Please make then to work in their native form.
i.e When using the JMS Utils they will return the message received in the
native format itself (XML, JSON, Map) and it will not auto convert all
messages to XML like what axis2 JMS transport was doing etc.
We'll work with you on the integrati
Hi Suho,
We are not dependent on any axis2 related transport. The generic
functionalities related to protocols such as JMS and VFS are implemented as
Utils.
So, we should be able to reuse them with in CEP too.
On Sat, Apr 19, 2014 at 10:37 AM, Sriskandarajah Suhothayan
wrote:
> @Kasun
>
> Can y
Hi Kasun,
On Wed, Apr 9, 2014 at 3:01 PM, Kasun Indrasiri wrote:
>
>
>
> On Mon, Apr 7, 2014 at 10:18 PM, Sanjiva Weerawarana wrote:
>
>> I don't understand what doesn't support MT means in this case. Lets take
>> SMTP- each inbound endpoint will give its own email address and poll from
>> that.
@Kasun
Can you elaborate a bit on the backend.
Are we reusing/improving the Axis2 JMS transport or will this be a new
implementation or module ?
This is because CEP also has use-cases on working with JMS Brokers so its
good if CEP can also reuse this implementation.
Regards
Suho
On Wed, Apr 16
We need to finalize the tooling aspect of this too. Ideally this is another
entry point to ESB, which is very similar to a proxy service or a REST api.
Any thoughts on how we should proceed with the tooling aspect of this?
On Wed, Apr 9, 2014 at 3:01 PM, Kasun Indrasiri wrote:
>
>
>
> On Mon, A
On Mon, Apr 7, 2014 at 10:18 PM, Sanjiva Weerawarana wrote:
> I don't understand what doesn't support MT means in this case. Lets take
> SMTP- each inbound endpoint will give its own email address and poll from
> that. Where's MTness involved?
>
> Isn't the same true or JMS? You just give a queue
I don't understand what doesn't support MT means in this case. Lets take
SMTP- each inbound endpoint will give its own email address and poll from
that. Where's MTness involved?
Isn't the same true or JMS? You just give a queue - its someone else's
problem to make sure queues are properly allocate
On Sun, Apr 6, 2014 at 4:03 PM, Dushan Abeyruwan wrote:
> Hi
> A different view from end user perspective, how any particular tenant
> developer knows which connection (JMS etc..) to select, have we thought of
> UI perspective of these inbound?
>
This should be treated as a inbound message sourc
Hi
A different view from end user perspective, how any particular tenant
developer knows which connection (JMS etc..) to select, have we thought of
UI perspective of these inbound?
Obviously from Stratos perspective how we enable different tenants to
select different Message Brokers ? are we goin
We will get a similar problem when implementing VFS.
Since the file locking is enabled by default we can keep that as it is and
remove the option for the user to disable this?
Best Regards,
Malaka
On Fri, Apr 4, 2014 at 1:39 PM, Ravi Undupitiya wrote:
> A small issue with this:
>
> With JMS I
A small issue with this:
With JMS Inbound EP's we let the users define the destination they would
like to poll - if the destination doesn't exist we will create it for them
(including any tenancy identifier in the destination name).
But if the user simply wants to listen to a particular destinati
In MB we prefix the queue name with the tenant domain name. for example If
the tenant is 'wso2.com', the name of the queue is 'ordersQueue' the queue
name reflected through the tenant will be "wso2.com/ordersQueue".
Thanks,
Pamod
On Fri, Apr 4, 2014 at 12:08 PM, Paul Fremantle wrote:
> We alre
We already have a multi-tenant JMS model in MB. We should use the same.
Paul
On 4 April 2014 07:25, Jeewantha Dharmaparakrama wrote:
> When multi tenancy is used with JMS transport it might be a good idea to
> make the queue name unique for a tenent maybe with some format like
> .. This can re
When multi tenancy is used with JMS transport it might be a good idea to
make the queue name unique for a tenent maybe with some format like
.. This can reduce the risk of two tenants using
the same queue.
On Fri, Apr 4, 2014 at 10:51 AM, Kasun Indrasiri wrote:
> Hi,
>
> We have been working on
Hi,
We have been working on the initial design for the Inbound Endpoint support
for ESB.
- Inbound endpoint is a dynamically configured message source for ESB.
- The current axis2 based transports other than HTTP/S doesn't work in
multitenant mode. The main idea is to supporting all transport (no
25 matches
Mail list logo
