from:"Oleg Kalnichevski"

On Sun, 2013-11-24 at 11:49 -0800, Hiranya Jayathilaka wrote:
> Hi Andreas, Hi Oleg,
> 
> 
> This is some excellent detective work :) Thanks for looking into this.
> I'm glad that we now have a better understanding of the issue and the
> problems are already being fixed in the httpcore trunk. 
> 
> 
> In the mean time, what if we also fix Synapse to not set these buffer
> size values, unless the user has specifically requested them to be
> set? That is, if the following properties are not set, we can just let
> Synapse pick the system defaults instead of initializing them to 8k:
> 
> 
> http.socket.rcv-buffer-size
> http.socket.snd-buffer-size
> 
> 
> WDYT?
> 

Sounds reasonable to me.

Oleg




-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: HTTP Core Performance and Reactor Buffer Size

On Sun, 2013-11-24 at 17:29 +0100, Andreas Veithen wrote:
> Oleg,
> 
> I had a closer look at the second part of the issue. The problem
> actually occurs between Synapse and the back-end server. The situation
> is quite similar to the first part of the issue: in the SYN packet
> sent by Synapse to the back-end, the TCP window size is set to 43690,
> and once the back-end starts sending the response, the window size
> drops to 8192.
> 
> In this case, the problem is that httpcore-nio sets the receive buffer
> size _after_ connecting. With the following patch, the problem
> completely disappears:
> 

Andreas,

I reviewed and committed the patch. While this change may theoretically
break some applications I would consider such possibility pretty
marginal.

Oleg 

> Index: 
> httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/DefaultConnectingIOReactor.java
> ===
> --- 
> httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/DefaultConnectingIOReactor.java
> (revision 1544958)
> +++ 
> httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/DefaultConnectingIOReactor.java
> (working copy)
> @@ -176,21 +176,8 @@
>  }
>  key.cancel();
>  if (channel.isConnected()) {
> -try {
> -try {
> -prepareSocket(channel.socket());
> -} catch (final IOException ex) {
> -if (this.exceptionHandler == null
> -|| !this.exceptionHandler.handle(ex)) {
> -throw new IOReactorException(
> -"Failure initalizing socket", ex);
> -}
> -}
> -final ChannelEntry entry = new
> ChannelEntry(channel, sessionRequest);
> -addChannel(entry);
> -} catch (final IOException ex) {
> -sessionRequest.failed(ex);
> -}
> +final ChannelEntry entry = new
> ChannelEntry(channel, sessionRequest);
> +addChannel(entry);
>  }
>  }
> 
> @@ -269,9 +256,9 @@
>  sock.setReuseAddress(this.config.isSoReuseAddress());
>  sock.bind(request.getLocalAddress());
>  }
> +prepareSocket(socketChannel.socket());
>  final boolean connected =
> socketChannel.connect(request.getRemoteAddress());
>  if (connected) {
> -prepareSocket(socketChannel.socket());
>  final ChannelEntry entry = new
> ChannelEntry(socketChannel, request);
>  addChannel(entry);
>  return;
> 
> Note that this change will require some more thorough review because
> the prepareSocket (in AbstractMultiworkerIOReactor) method is
> protected but not final. Therefore there could be code that overrides
> this method and that assumes that the socket is connected, which is no
> longer the case with may change.
> 
> However, all httpcore unit tests still pass after that change, and
> there are also no failures in the integration tests in Synapse.
> 
> Andreas
> 
> On Sun, Nov 24, 2013 at 1:32 PM, Oleg Kalnichevski  wrote:
> > On Sun, 2013-11-24 at 13:02 +0100, Andreas Veithen wrote:
> >> All,
> >>
> >> While debugging this scenario (on Ubuntu with the default receive
> >> buffer size of 8192 and a payload of 1M), I noticed something else.
> >> Very early in the test execution, there are TCP retransmissions from
> >> the client to Synapse. This is of course weird and should not happen.
> >> While trying to understand why that occurs, I noticed that the TCP
> >> window size advertised by Synapse to the client is initially 43690,
> >> and then drops gradually to 8192. The latter value is expected because
> >> it corresponds to the receive buffer size. The question is why the TCP
> >> window is initially 43690.
> >>
> >> It turns out that this is because httpcore-nio sets the receive buffer
> >> size only on the sockets for new incoming connections (in
> >> AbstractMultiworkerIOReactor#prepareSocket), but not on the server
> >> socket itself [1]. Since the initial TCP window size is advertised in
> >> the SYN/ACK packet before the connection is accepted (and httpcore-nio
> >> gets a chance to set the receive buffer size), it will be the default
> >&

Re: HTTP Core Performance and Reactor Buffer Size

On Sun, 2013-11-24 at 14:15 +0100, Andreas Veithen wrote:
> Instead of taking 40 seconds, the scenario now takes 20 seconds, with the
> request processing completing in less than a second. So there is still a
> problem, but I didn't get the time yet to debug further. I'll keep you
> updated once I have more information.
> 
> Andreas
> 

I see. As said in my previous message messing with OS default settings
for RCV/SND buffer size seems to cause only grief. 8K for RCV buffer
sounds way too small.

Oleg

> On Sunday, November 24, 2013, Oleg Kalnichevski wrote:
> 
> > On Sun, 2013-11-24 at 13:02 +0100, Andreas Veithen wrote:
> > > All,
> > >
> > > While debugging this scenario (on Ubuntu with the default receive
> > > buffer size of 8192 and a payload of 1M), I noticed something else.
> > > Very early in the test execution, there are TCP retransmissions from
> > > the client to Synapse. This is of course weird and should not happen.
> > > While trying to understand why that occurs, I noticed that the TCP
> > > window size advertised by Synapse to the client is initially 43690,
> > > and then drops gradually to 8192. The latter value is expected because
> > > it corresponds to the receive buffer size. The question is why the TCP
> > > window is initially 43690.
> > >
> > > It turns out that this is because httpcore-nio sets the receive buffer
> > > size only on the sockets for new incoming connections (in
> > > AbstractMultiworkerIOReactor#prepareSocket), but not on the server
> > > socket itself [1]. Since the initial TCP window size is advertised in
> > > the SYN/ACK packet before the connection is accepted (and httpcore-nio
> > > gets a chance to set the receive buffer size), it will be the default
> > > receive buffer size, not 8192.
> > >
> > > To fix this, I modified httpcore-nio as follows:
> > >
> > > Index:
> > httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/DefaultListeningIOReactor.java
> > > ===
> > > ---
> > httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/DefaultListeningIOReactor.java
> > > (revision 1544958)
> > > +++
> > httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/DefaultListeningIOReactor.java
> > > (working copy)
> > > @@ -233,6 +233,9 @@
> > >  try {
> > >  final ServerSocket socket = serverChannel.socket();
> > >  socket.setReuseAddress(this.config.isSoReuseAddress());
> > > +if (this.config.getRcvBufSize() > 0) {
> > > +
> >  socket.setReceiveBufferSize(this.config.getRcvBufSize());
> > > +}
> > >  serverChannel.configureBlocking(false);
> > >  socket.bind(address);
> > >  } catch (final IOException ex) {
> > >
> > > This fixes the TCP window and retransmission problem, and it also
> > > appears to fix half of the overall issue: now transmitting the 1M
> > > request payload only takes a few 100 milliseconds instead of 20
> > > seconds. However, the issue still exists in the return path.
> > >
> > > Andreas
> > >
> >
> > Andreas
> >
> > I committed the patch to SVN trunk. Please review.
> >
> > Could you please elaborate what do you mean by 'issue still exists in
> > the return path'. I am not sure I quite understand.
> >
> > Oleg
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org 
> > For additional commands, e-mail: dev-h...@synapse.apache.org
> >
> >



-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: HTTP Core Performance and Reactor Buffer Size

On Sun, 2013-11-24 at 13:02 +0100, Andreas Veithen wrote:
> All,
> 
> While debugging this scenario (on Ubuntu with the default receive
> buffer size of 8192 and a payload of 1M), I noticed something else.
> Very early in the test execution, there are TCP retransmissions from
> the client to Synapse. This is of course weird and should not happen.
> While trying to understand why that occurs, I noticed that the TCP
> window size advertised by Synapse to the client is initially 43690,
> and then drops gradually to 8192. The latter value is expected because
> it corresponds to the receive buffer size. The question is why the TCP
> window is initially 43690.
> 
> It turns out that this is because httpcore-nio sets the receive buffer
> size only on the sockets for new incoming connections (in
> AbstractMultiworkerIOReactor#prepareSocket), but not on the server
> socket itself [1]. Since the initial TCP window size is advertised in
> the SYN/ACK packet before the connection is accepted (and httpcore-nio
> gets a chance to set the receive buffer size), it will be the default
> receive buffer size, not 8192.
> 
> To fix this, I modified httpcore-nio as follows:
> 
> Index: 
> httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/DefaultListeningIOReactor.java
> ===
> --- 
> httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/DefaultListeningIOReactor.java
> (revision 1544958)
> +++ 
> httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/DefaultListeningIOReactor.java
> (working copy)
> @@ -233,6 +233,9 @@
>  try {
>  final ServerSocket socket = serverChannel.socket();
>  socket.setReuseAddress(this.config.isSoReuseAddress());
> +if (this.config.getRcvBufSize() > 0) {
> +socket.setReceiveBufferSize(this.config.getRcvBufSize());
> +}
>  serverChannel.configureBlocking(false);
>  socket.bind(address);
>  } catch (final IOException ex) {
> 
> This fixes the TCP window and retransmission problem, and it also
> appears to fix half of the overall issue: now transmitting the 1M
> request payload only takes a few 100 milliseconds instead of 20
> seconds. However, the issue still exists in the return path.
> 
> Andreas
> 

Andreas

I committed the patch to SVN trunk. Please review.

Could you please elaborate what do you mean by 'issue still exists in
the return path'. I am not sure I quite understand.

Oleg


-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: HTTP Core Performance and Reactor Buffer Size

On Thu, 2013-11-21 at 12:08 -0800, Hiranya Jayathilaka wrote:
> Hi Devs,
> 
> I just found out that the performance of the Synapse Pass Through transport 
> is highly sensitive to the RcvBufferSize of the IO reactors (especially when 
> mediating very large messages). Here are some test results. In this case, I'm 
> simply passing through a 1M message through Synapse to a backend server, 
> which simply echoes it back to the client. Notice how the execution time of 
> the scenario varies with the RcvBufferSize of the IO reactors.
> 
> RcvBufferSize (in bytes)  Scenario Execution Time (in seconds)
> 
> 8192 (Synapse default)25.9
> 16384   0.4
> 32768   0.2
> 

Hiranya

After experimenting extensively with RCV/SND buffer settings (with mixed
results) my personal conclusion was that those settings were better left
alone (set to their system default values). 

I am however not a TCP/IP specialist by any stretch of imagination, so I
may be missing something important.

Oleg 

> Is this behavior normal? If so does it make sense to change the Synapse 
> default buffer size to something larger (e.g. 16k)?
> 
> Interestingly I see this difference in behavior on Linux only. I cannot see a 
> significant change in behavior on Mac. 
> 
> Appreciate your thoughts on this.
> 
> Thanks,
> Hiranya
> 
> --
> Hiranya Jayathilaka
> Mayhem Lab/RACE Lab;
> Dept. of Computer Science, UCSB;  http://cs.ucsb.edu
> E-mail: hira...@cs.ucsb.edu;  Mobile: +1 (805) 895-7443
> Blog: http://techfeast-hiranya.blogspot.com
> 



-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: Why is "java.nio.channels.ClosedChannelException" thrown from Nio Reactor?

2013-08-19 Thread Oleg Kalnichevski

On Mon, 2013-08-19 at 14:18 +0530, Jeewantha Dharmaparakrama wrote:
> Hi All,
> 
> I have an intermittent issue with Synapse where it prints the following
> exception in its Error logs.
> 
> [2013-08-15 16:57:28,710] ERROR - SourceHandler Unexpected I/O error:
> java.nio.channels.ClosedChannelException
> java.nio.channels.ClosedChannelException
> at sun.nio.ch.SocketChannelImpl.ensureWriteOpen(SocketChannelImpl.java:135)
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:326)
> at 
> org.apache.http.impl.nio.reactor.SessionOutputBufferImpl.flush(SessionOutputBufferImpl.java:167)
> at 
> org.apache.http.impl.nio.DefaultNHttpServerConnection.produceOutput(DefaultNHttpServerConnection.java:323)
> at 
> org.apache.synapse.transport.http.conn.LoggingNHttpServerConnection.produceOutput(LoggingNHttpServerConnection.java:112)
> at 
> org.apache.synapse.transport.passthru.ServerIODispatch.onOutputReady(ServerIODispatch.java:87)
> at 
> org.apache.synapse.transport.passthru.ServerIODispatch.onOutputReady(ServerIODispatch.java:39)
> at 
> org.apache.http.impl.nio.reactor.AbstractIODispatch.outputReady(AbstractIODispatch.java:143)
> at 
> org.apache.http.impl.nio.reactor.BaseIOReactor.writable(BaseIOReactor.java:180)
> at 
> org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:342)
> at 
> org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:316)
> at 
> org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:277)
> at 
> org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:105)
> at 
> org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:584)
> at java.lang.Thread.run(Thread.java:662)
> 
> What happens is for some reason, the corresponding SocketChannel is closed
> but still some IO operation is done on it. Once this exception is caught
> from httpcore-nio, it will be passed to *
> org.apache.http.nio.NHttpServerEventHandler* implementation
> (*org.apache.synapse.transport.passthru.SourceHandler
> * ) and will be printed on Synapse Error logs. Since this is an
> intermittent issue,
> I tried to reproduce this programmatically but failed [1]. What can be the
> practical reason for this Error? Can this be deliberately reproduced with
> Synapse?
> 
> [1] http://stackoverflow.com/q/18309283/1411653
> 
> Thanks in advance,
> Jeewantha.

Can be anything, a bug in HttpCore or in Synapse, misbehaving client,
evil Russians. There is no way of telling without more contextual
details and preferrably a wire log.

Oleg


-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: Setting Buffer Sizes in the New API

2013-08-13 Thread Oleg Kalnichevski

On Mon, 2013-08-12 at 12:28 -0700, Hiranya Jayathilaka wrote:
> Hi Oleg,
> 
> Up until now we supported a parameter named "http.socket.buffer-size" in the 
> pass-thru.properties (nhttp.properties) file of Synapse. The value of this 
> parameter was used to set the corresponding parameter on HttpParams. How 
> should this change with the new HTTP Core API?
> 
> The reason I had to ask is that I see 3 different ways to set a buffer size 
> in the new API:
> 
> IOReactorConfig.setSndBufSize()
> IOReactorConfig.setRcvBufSize()
> ConnectionConfig.setBufferSize()
> 
> For the moment I've introduced 2 new parameters to the Synapse properties 
> files and implemented the following mapping:
> 
> http.socket.snd-buffer-size -> IOReactorConfig.setSndBufSize()
> http.socket.rcv-buffer-size -> IOReactorConfig.setRcvBufSize()
> http.socket.buffer-size (old parameter) -> ConnectionConfig.setBufferSize()
> 
> Does this make sense?
> 

Yes, it does. You can safely ignore IOReactorConfig level parameters
though. They have been added more for completeness than anything else.
They only apply when TCP_NODEPLAY is set to false, which rarely should
be the case.

Oleg



-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: Replacement to ExecutionContext

2013-08-12 Thread Oleg Kalnichevski

On Fri, 2013-08-09 at 19:47 -0700, Hiranya Jayathilaka wrote:
> Hi Oleg,
> 
> I'm attempting to migrate Synapse to HTTP Core 4.3. We have code similar to 
> the following fragment in several places in the passthrough and NHTTP 
> transports:
> 
> httpContext.setAttribute(ExecutionContext.HTTP_CONNECTION, conn);
> httpContext.setAttribute(ExecutionContext.HTTP_REQUEST, null);
> httpContext.setAttribute(ExecutionContext.HTTP_RESPONSE, 
> response);
> 
> It looks like ExecutionContext is deprecated in 4.3. What is the alternative 
> to that? Or do we need the above code segment at all with the latest Http 
> Core?
> 
> Thanks,
> Hiranya


Hi Hiranya 

Use HttpCoreContext instead.

http://hc.apache.org/httpcomponents-core-4.3.x/httpcore/apidocs/org/apache/http/protocol/HttpCoreContext.html

Oleg



-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: Alternative to SSLClientIOEventDispatch.createSSLIOSession

2013-07-28 Thread Oleg Kalnichevski

On Thu, 2013-07-25 at 12:28 -0700, Hiranya Jayathilaka wrote:
> Hi Oleg,
> 
> On Jul 25, 2013, at 1:04 AM, Oleg Kalnichevski 
> wrote:
> 
> > On Wed, 2013-07-24 at 12:32 -0700, Hiranya Jayathilaka wrote:
> > > Hi Oleg,
> > > 
> > > We used to override the createSSLIOSession method of the
> > > SSLClientIOEventDispatch class in the Synapse transports. What is
> > > the alternative to this in the new HTTP Core APIs? Basically, we
> > > want to customize how SSLIOSession instances are created by the
> > > transport.
> > > 
> > > Thanks,
> > > Hiranya
> > 
> > You should use SSLNHttp*ConnectionFactory with a custom
> > SSLSetupHandler
> > or create a custom NHttpConnectionFactory.
> 
> 
> It doesn't look like we can override the way SSLIOSession instances
> are created from a custom SSLSetupHandler. Only option is to override
> the createConnection(IOSession) method of
> SSLNHttpClientConnectionFactory. The SSLIOSession objects are created
> within this method as follows:
> 
> 
> SSLIOSession ssliosession = new SSLIOSession(session, SSLMode.SERVER, 
> sslcontext, this.sslHandler);
> 
> 
> Will it be possible to get an extensible hook into this class in a
> future release, so we can easily override how SSLIOSession objects are
> created, without having to override the whole createConnection method?
> 
> 
> Thanks,
> Hiranya
> 

That's already been done in 4.3

Oleg




-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: Alternative to SSLClientIOEventDispatch.createSSLIOSession

2013-07-25 Thread Oleg Kalnichevski

On Wed, 2013-07-24 at 12:32 -0700, Hiranya Jayathilaka wrote:
> Hi Oleg,
> 
> We used to override the createSSLIOSession method of the 
> SSLClientIOEventDispatch class in the Synapse transports. What is the 
> alternative to this in the new HTTP Core APIs? Basically, we want to 
> customize how SSLIOSession instances are created by the transport.
> 
> Thanks,
> Hiranya

You should use SSLNHttp*ConnectionFactory with a custom SSLSetupHandler
or create a custom NHttpConnectionFactory.

Hope this helps

Oleg

> --
> Hiranya Jayathilaka
> Mayhem Lab/RACE Lab;
> Dept. of Computer Science, UCSB;  http://cs.ucsb.edu
> E-mail: hira...@cs.ucsb.edu;  Mobile: +1 (805) 895-7443
> Blog: http://techfeast-hiranya.blogspot.com
> 



-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: Migrating Synapse to Latest HTTP Core

2013-07-25 Thread Oleg Kalnichevski

On Wed, 2013-07-24 at 11:04 -0700, Hiranya Jayathilaka wrote:
> Hi Oleg,
> 
> Thanks for your great insights. Now I'm able to get all the unit tests and 
> integration tests to run successfully.
> 
> BTW do you have any idea as to what changed between 4.1.x and 4.2.x to cause 
> this behavior? Our test suites work fine on current Synapse trunk which is 
> based on HTTP Core 4.1.4.
> 

Hi Hiranya

Prior to 4.2 HttpCore did not explicitly set SO_REUSEADDRESS parameter
on server sockets and relied on platform specific default behavior.

Oleg

> Also do you think it's a good idea to make SoReuseAddress=true the default in 
> Synapse? Do you see any potential issues with that?
> 
> Thanks,
> Hiranya
> 
> On Jul 24, 2013, at 5:49 AM, Oleg Kalnichevski  wrote:
> 
> > On Wed, 2013-07-24 at 13:45 +0200, Oleg Kalnichevski wrote:
> >> On Wed, 2013-07-24 at 01:40 -0700, Hiranya Jayathilaka wrote:
> >>> Hi again,
> >>> 
> >>> On Jul 24, 2013, at 1:36 AM, Hiranya Jayathilaka
> >>>  wrote:
> > 
> > ...
> > 
> >>> 
> >>> I've also noticed that the problem doesn't occur if we do not send any
> >>> messages in the 1st round. I verified this behavior with Synapse too.
> >>> If a test case doesn't send any messages to Synapse, the test case
> >>> that follows will run without any issues.
> >>> 
> >> 
> >> Hiranya
> >> 
> >> (1) The socket is CLOSE_WAIT state is from the client connection. It has
> >> nothing to do with the problem and can be gotten rid of by shutting down
> >> the client connection pool. 
> >> 
> >> client.getConnectionManager().shutdown();
> >> 
> >> (2) The 'Address already in use' problem goes away if the server is
> >> configured to re-use socket address
> >> 
> >> reactorConfig.setSoReuseAddress(true);
> >> 
> >> I think this option should be activated for integration tests running
> >> inside the same JVM anyway, but I'll investigate why the address remains
> >> bound even after the listener has been shut down. I am not yet sure
> >> whether this is a bug or an expected behavior.
> >> 
> >> Oleg 
> >> 
> >> 
> > 
> > Just a quick follow-up. The problem appears to be Linux specific. The
> > same test app works fine for me on Windows XP.
> > 
> > I also modified slightly your code in order to have a finer control over
> > the client side.
> > ---
> > System.out.println("Round 1");
> > initServer();
> > 
> > DefaultHttpClientConnection conn = new DefaultHttpClientConnection();
> > try {
> >Socket socket = new Socket("localhost", 8280);
> >conn.bind(socket, new BasicHttpParams());
> >conn.setSocketTimeout(1000);
> >conn.sendRequestHeader(new BasicHttpRequest("GET", "/"));
> >conn.flush();
> >conn.receiveResponseHeader();
> > } catch (SocketTimeoutException ex) {
> > } finally {
> >conn.close(); 
> >   // this closes the socket the connection is bound to
> > }
> > 
> > System.out.println("Waiting - Shutdown in 5 secs");
> > Thread.sleep(5000);
> > shutdown();
> > 
> > System.out.println("\n\nRound 2");
> > initServer();
> > System.out.println("Waiting - Shutdown in 5 secs");
> > Thread.sleep(5000);
> > shutdown();
> > ---
> > 
> > If you just comment out the conn#receiveResponseHeader() statement the
> > client side socket will never be put into read mode, and (surprise,
> > surprise) the listener address will no longer be stuck in the bound
> > state.
> > 
> > I am neither a Linux nor a TCP/IP specialist. I cannot tell why this is
> > happening. However, by the look of it, one must use 'SO_REUSE_ADDRESS'
> > option on Linux in order to be able to shut down and re-open the
> > listener on the same address if the socket bound to that address had
> > some data passing through it.
> > 
> > Anyone happens to have an idea?
> > 
> > Oleg
> > 
> > 
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
> > For additional commands, e-mail: dev-h...@synapse.apache.org
> > 
> 
> --
> Hiranya Jayathilaka
> Mayhem Lab/RACE Lab;
> Dept. of Computer Science, UCSB;  http://cs.ucsb.edu
> E-mail: hira...@cs.ucsb.edu;  Mobile: +1 (805) 895-7443
> Blog: http://techfeast-hiranya.blogspot.com
> 



-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: Migrating Synapse to Latest HTTP Core

2013-07-24 Thread Oleg Kalnichevski

On Wed, 2013-07-24 at 13:45 +0200, Oleg Kalnichevski wrote:
> On Wed, 2013-07-24 at 01:40 -0700, Hiranya Jayathilaka wrote:
> > Hi again,
> > 
> > On Jul 24, 2013, at 1:36 AM, Hiranya Jayathilaka
> >  wrote:

...

> > 
> > I've also noticed that the problem doesn't occur if we do not send any
> > messages in the 1st round. I verified this behavior with Synapse too.
> > If a test case doesn't send any messages to Synapse, the test case
> > that follows will run without any issues.
> > 
> 
> Hiranya
> 
> (1) The socket is CLOSE_WAIT state is from the client connection. It has
> nothing to do with the problem and can be gotten rid of by shutting down
> the client connection pool. 
> 
> client.getConnectionManager().shutdown();
> 
> (2) The 'Address already in use' problem goes away if the server is
> configured to re-use socket address
> 
> reactorConfig.setSoReuseAddress(true);
> 
> I think this option should be activated for integration tests running
> inside the same JVM anyway, but I'll investigate why the address remains
> bound even after the listener has been shut down. I am not yet sure
> whether this is a bug or an expected behavior.
> 
> Oleg 
> 
> 

Just a quick follow-up. The problem appears to be Linux specific. The
same test app works fine for me on Windows XP.

I also modified slightly your code in order to have a finer control over
the client side.
---
System.out.println("Round 1");
initServer();

DefaultHttpClientConnection conn = new DefaultHttpClientConnection();
try {
Socket socket = new Socket("localhost", 8280);
conn.bind(socket, new BasicHttpParams());
conn.setSocketTimeout(1000);
conn.sendRequestHeader(new BasicHttpRequest("GET", "/"));
conn.flush();
conn.receiveResponseHeader();
} catch (SocketTimeoutException ex) {
} finally {
conn.close(); 
   // this closes the socket the connection is bound to
}

System.out.println("Waiting - Shutdown in 5 secs");
Thread.sleep(5000);
shutdown();

System.out.println("\n\nRound 2");
initServer();
System.out.println("Waiting - Shutdown in 5 secs");
Thread.sleep(5000);
shutdown();
---

If you just comment out the conn#receiveResponseHeader() statement the
client side socket will never be put into read mode, and (surprise,
surprise) the listener address will no longer be stuck in the bound
state.

I am neither a Linux nor a TCP/IP specialist. I cannot tell why this is
happening. However, by the look of it, one must use 'SO_REUSE_ADDRESS'
option on Linux in order to be able to shut down and re-open the
listener on the same address if the socket bound to that address had
some data passing through it.

Anyone happens to have an idea?

Oleg



-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: Migrating Synapse to Latest HTTP Core

2013-07-24 Thread Oleg Kalnichevski

On Wed, 2013-07-24 at 01:40 -0700, Hiranya Jayathilaka wrote:
> Hi again,
> 
> On Jul 24, 2013, at 1:36 AM, Hiranya Jayathilaka
>  wrote:
> 
> > Hi Oleg,
> > 
> > 
> > I can reproduce the problem with the attached JUnit test case. This
> > test case doesn't use any Axis2/Synapse related code. It only
> > requires HTTP Core and HTTP client. I used HTTP Core 4.2.4 for
> > testing.
> > 
> > 
> > The test case starts a ListeningIOReactor, does a simple HTTP
> > request-response exchange and then terminates the reactor. Then
> > after a couple of seconds, it tries to start the IO reactor again
> > and the exception occurs. Here's the full output:
> > 
> > 
> > Round 1
> > Listener started on port: 8280
> > Connected
> > Request received
> > Response submitted
> > Waiting - Shutdown in 5 secs
> > Shutdown
> > 
> > 
> > … wait 2 seconds...
> > 
> > 
> > Round 2
> > Listener started on port: 8280
> > Waiting - Shutdown in 5 secs
> > java.net.BindException: Address already in use
> > at sun.nio.ch.Net.bind(Native Method)
> > at
> > sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:124)
> > at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)
> > at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:52)
> > at
> > org.apache.http.impl.nio.reactor.DefaultListeningIOReactor.processSessionRequests(DefaultListeningIOReactor.java:238)
> > at
> > org.apache.http.impl.nio.reactor.DefaultListeningIOReactor.processEvents(DefaultListeningIOReactor.java:144)
> > at
> > org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor.execute(AbstractMultiworkerIOReactor.java:374)
> > at org.apache.synapse.transport.nhttp.HttpCoreTest
> > $3.run(HttpCoreTest.java:101)
> > Shutdown
> 
> 
> I've also noticed that the problem doesn't occur if we do not send any
> messages in the 1st round. I verified this behavior with Synapse too.
> If a test case doesn't send any messages to Synapse, the test case
> that follows will run without any issues.
> 

Hiranya

(1) The socket is CLOSE_WAIT state is from the client connection. It has
nothing to do with the problem and can be gotten rid of by shutting down
the client connection pool. 

client.getConnectionManager().shutdown();

(2) The 'Address already in use' problem goes away if the server is
configured to re-use socket address

reactorConfig.setSoReuseAddress(true);

I think this option should be activated for integration tests running
inside the same JVM anyway, but I'll investigate why the address remains
bound even after the listener has been shut down. I am not yet sure
whether this is a bug or an expected behavior.

Oleg 


-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: Migrating Synapse to Latest HTTP Core

2013-07-24 Thread Oleg Kalnichevski

On Tue, 2013-07-23 at 20:24 -0700, Hiranya Jayathilaka wrote:
> It looks like the socket goes into the CLOSE_WAIT state after shutting
> down the IO reactor and remains there until the JVM it self is killed.
> Since all automated test cases are executed within a single JVM
> instance, this issue continues to occur. Looks like something is not
> getting cleaned up properly with the latest HTTP Core.
> 
> 
> Thanks,
> Hiranya
> 

Hiranya

I need a more specific evidence of HttpCore doing something wrong. Could
you please reproduce the issue with a test app, preferably not dependent
on Synapse?

Oleg   

> On Jul 23, 2013, at 3:54 PM, Hiranya Jayathilaka
>  wrote:
> 
> > Hi Oleg,
> > 
> > 
> > I've done the necessary code changes locally and it seems to work
> > fine. The HTTPS sender now works as expected. But when running
> > automated tests, I frequently get the following exception:
> > 
> > 
> > 34 [HttpCoreNIOListener] WARN
> > org.apache.synapse.transport.nhttp.HttpCoreNIOListener - System may
> > be unstable: IOReactor encountered a checked exception : Address
> > already in use
> > java.net.BindException: Address already in use
> > at sun.nio.ch.Net.bind(Native Method)
> > at
> > sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:124)
> > at
> > sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)
> > at
> > sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:52)
> > at
> > org.apache.http.impl.nio.reactor.DefaultListeningIOReactor.processSessionRequests(DefaultListeningIOReactor.java:238)
> > at
> > org.apache.http.impl.nio.reactor.DefaultListeningIOReactor.processEvents(DefaultListeningIOReactor.java:144)
> > at
> > org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor.execute(AbstractMultiworkerIOReactor.java:374)
> > at org.apache.synapse.transport.nhttp.HttpCoreNIOListener
> > $2.run(HttpCoreNIOListener.java:254)
> > at java.lang.Thread.run(Thread.java:680)
> > 
> > 
> > This is seen in both NHTTP unit tests and Synapse integration tests.
> > Any idea what is going on here? Synapse cleans up the IO reactor by
> > calling ioReactor.shutdown(). Is there anything else we need to do
> > to clean up the reactor properly?
> > 
> > 
> > Thanks,
> > Hiranya
> > 
> > 
> > On Jul 23, 2013, at 10:54 AM, Hiranya Jayathilaka
> >  wrote:
> > 
> > > HI Oleg,
> > > 
> > > On Jul 23, 2013, at 12:32 AM, Oleg Kalnichevski 
> > > wrote:
> > > 
> > > > On Mon, 2013-07-22 at 20:51 -0700, Hiranya Jayathilaka wrote:
> > > > > On Jul 22, 2013, at 7:53 PM, Rajika Kumarasiri
> > > > >  wrote:
> > > > > 
> > > > > > May be we should enable the SSl debug logs and see what's
> > > > > > going on ? 
> > > > > 
> > > > > I ran some more tests and it looks like the HTTPS sender
> > > > > doesn't work with HTTP Core 4.2. It just sends out the
> > > > > messages without any SSL security. I can even monitor the
> > > > > message in plain text using TCPMon. Looks like some SSL
> > > > > related code in the Synapse HTTPS sender doesn't work properly
> > > > > with the new HTTP Core.
> > > > > 
> > > > > Thanks,
> > > > > Hiranya
> > > > > 
> > > > 
> > > > Hiranya
> > > > 
> > > > Have you migrated off the deprecated APIs to new 4.2 APIs? 
> > > 
> > > 
> > > No not yet. I just tried changing the HTTP Core dependency version
> > > to begin with. I guess migrating off the deprecated APIs is the
> > > next logical step.
> > > 
> > > 
> > > Thanks,
> > > Hiranya
> > > 
> > > > 
> > > > Oleg
> > > > 
> > > > PS: By the way, you should probably consider migrating straight
> > > > to 4.3
> > > > at this point.
> > > > 
> > > > 
> > > > > > 
> > > > > > Rajika
> > > > > > 
> > > > > > 
> > > > > > On Mon, Jul 22, 2013 at 8:23 PM, Hiranya Jayathilaka
> > > > > >  wrote:
> > > > > > Hi Folks,
> > > > > > 
> > > > > > Currently Synapse is based on HTTP Core 4.1.4. I just tried
> > > > >

Re: Migrating Synapse to Latest HTTP Core

2013-07-23 Thread Oleg Kalnichevski

On Mon, 2013-07-22 at 20:51 -0700, Hiranya Jayathilaka wrote:
> On Jul 22, 2013, at 7:53 PM, Rajika Kumarasiri  
> wrote:
> 
> > May be we should enable the SSl debug logs and see what's going on ? 
> 
> I ran some more tests and it looks like the HTTPS sender doesn't work with 
> HTTP Core 4.2. It just sends out the messages without any SSL security. I can 
> even monitor the message in plain text using TCPMon. Looks like some SSL 
> related code in the Synapse HTTPS sender doesn't work properly with the new 
> HTTP Core.
> 
> Thanks,
> Hiranya
> 

Hiranya

Have you migrated off the deprecated APIs to new 4.2 APIs? 

Oleg

PS: By the way, you should probably consider migrating straight to 4.3
at this point.


> > 
> > Rajika
> > 
> > 
> > On Mon, Jul 22, 2013 at 8:23 PM, Hiranya Jayathilaka  
> > wrote:
> > Hi Folks,
> > 
> > Currently Synapse is based on HTTP Core 4.1.4. I just tried using 4.2 
> > instead (just changed the version of the maven dependency). Almost 
> > everything worked fine, except for a couple of integration test failures. 
> > In both these tests Synapse uses HTTPS to contact the backend services, so 
> > I suppose that's where things went wrong. The backend server threw the 
> > following exception in the process:
> > 
> > 2013-07-22 17:06:36,970 [-] [https-Listener I/O dispatcher-1] ERROR 
> > ServerHandler I/O error: Unrecognized SSL message, plaintext connection?
> > javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
> > at 
> > com.sun.net.ssl.internal.ssl.EngineInputRecord.bytesInCompletePacket(EngineInputRecord.java:152)
> > at 
> > com.sun.net.ssl.internal.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:806)
> > at 
> > com.sun.net.ssl.internal.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:721)
> > at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:607)
> > at 
> > org.apache.http.nio.reactor.ssl.SSLIOSession.doUnwrap(SSLIOSession.java:228)
> > at 
> > org.apache.http.nio.reactor.ssl.SSLIOSession.doHandshake(SSLIOSession.java:263)
> > at 
> > org.apache.http.nio.reactor.ssl.SSLIOSession.isAppInputReady(SSLIOSession.java:370)
> > at 
> > org.apache.http.impl.nio.SSLServerIOEventDispatch.inputReady(SSLServerIOEventDispatch.java:229)
> > at 
> > org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:160)
> > at 
> > org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:342)
> > at 
> > org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:320)
> > at 
> > org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:280)
> > at 
> > org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:106)
> > at 
> > org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:604)
> > at java.lang.Thread.run(Thread.java:680)
> > 
> > I also tried upgrading to the latest HTTP Core version (4.2.4). With this 
> > version NHTTP unit tests failed and most of the integration tests failed 
> > too. It turns out only the very first integration test ran successfully. 
> > Everything that followed threw a bind exception. Looks like something isn't 
> > getting cleaned up properly (although the logs indicate that Synapse 
> > transport listeners are shutting down cleanly after each test case).
> > 
> > Does anybody got an idea what's going on? Do we need to do any code changes 
> > to migrate to the latest HTTP Core?
> > 
> > Thanks,
> > Hiranya
> > --
> > Hiranya Jayathilaka
> > Mayhem Lab/RACE Lab;
> > Dept. of Computer Science, UCSB;  http://cs.ucsb.edu
> > E-mail: hira...@cs.ucsb.edu;  Mobile: +1 (805) 895-7443
> > Blog: http://techfeast-hiranya.blogspot.com
> > 
> > 
> 
> --
> Hiranya Jayathilaka
> Mayhem Lab/RACE Lab;
> Dept. of Computer Science, UCSB;  http://cs.ucsb.edu
> E-mail: hira...@cs.ucsb.edu;  Mobile: +1 (805) 895-7443
> Blog: http://techfeast-hiranya.blogspot.com
> 



-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: Possible Race Condition Due to NHTTP Connection Pooling

2012-04-11 Thread Oleg Kalnichevski

On Wed, 2012-04-11 at 14:02 +0530, Hiranya Jayathilaka wrote:
> It looks like calling setSocketTimeout on the NHttpClientConnection would
> reset the last access time attribute of the underlying IOSession. So if we
> do the following before the connection is returned from the pool, will that
> work?
> 
> conn.setSocketTimeout(conn.getSocketTimeout());
> 
> Thanks,
> Hiranya
> 

Yes, this should work. It is actually quite reasonable to disable
timeouts prior to releasing the connection back to the pool and reseting
after leasing it again.

Oleg

> On Wed, Apr 11, 2012 at 1:36 PM, Hiranya Jayathilaka
> wrote:
> 
> > Hi Devs,
> >
> > I have identified a possible race condition in the Synapse NHTTP
> > transport. This happens because Synapse pools NHttpClientConnection
> > instances for easy reuse. Imagine the following scenario:
> >
> > 1. Synapse receives a message which should be forwarded to X
> > 2. Synapse detects that a previously established connection to X already
> > exists in the NHTTP connection pool
> > 3. Synapse attempts to forward the message over the above connection
> >
> > Now if the connection has stayed in the connection pool for a fairly long
> > time in idle state, then the ClientHandler#timeout event may get fired on
> > it as Synapse attempts to send the new request over it. In this case the
> > Synapse ClientHandler simply closes the connection which causes the request
> > invocation to fail. I'm able to reproduce this issue consistently with a
> > simple mutation test:
> >
> > [2012-04-11 13:10:34,927] DEBUG - ConnectionPool A connection to host :
> > localhost on port : 9000 is available in the pool, and will be reused
> > [2012-04-11 13:10:34,929] DEBUG - ClientHandler Connection timeout For :
> > 127.0.0.1:9000
> > [2012-04-11 13:10:34,930] DEBUG - headers >> POST
> > /services/SimpleStockQuoteService HTTP/1.1
> > [2012-04-11 13:10:34,931] DEBUG - headers >> Content-Type: text/xml;
> > charset=UTF-8
> > [2012-04-11 13:10:34,931] DEBUG - headers >> SOAPAction: "urn:getQuote"
> > [2012-04-11 13:10:34,931] DEBUG - headers >> Transfer-Encoding: chunked
> > [2012-04-11 13:10:34,931] DEBUG - headers >> Host: localhost:9000
> > [2012-04-11 13:10:34,931] DEBUG - headers >> Connection: Keep-Alive
> > [2012-04-11 13:10:34,932] DEBUG - headers >> User-Agent:
> > Synapse-HttpComponents-NIO
> > [2012-04-11 13:10:34,932] DEBUG - ClientHandler Connection to remote
> > address : localhost/127.0.0.1:9000 from local address : /127.0.0.1:35208is 
> > closed!
> > [2012-04-11 13:10:34,933] DEBUG - HttpCoreNIOSender An existing connection
> > reused to : localhost:9000
> > [2012-04-11 13:10:34,933] DEBUG - ClientHandler HTTP connection
> > 127.0.0.1:35208->127.0.0.1:9000: Closed
> > [2012-04-11 13:10:34,933] DEBUG - Axis2HttpRequest Start streaming
> > outgoing http request : [Message ID :
> > urn:uuid:ec5957cc-73a6-4877-b76f-a26b72b2edd3]
> > [2012-04-11 13:10:34,934] DEBUG - ClientHandler Keep-alive connection
> > closed For : 127.0.0.1:9000 For Request : Axis2Request [Message ID :
> > urn:uuid:ec5957cc-73a6-4877-b76f-a26b72b2edd3] [Status Completed : true]
> > [Status SendingCompleted : false]
> > [2012-04-11 13:10:34,934] DEBUG - ClientHandler Connection to remote
> > address : localhost/127.0.0.1:9000 from local address : /127.0.0.1:35208is 
> > closed!
> > [2012-04-11 13:10:34,952] DEBUG - ClientHandler Sending Fault for Request
> > with Message ID : urn:uuid:ec5957cc-73a6-4877-b76f-a26b72b2edd3
> >
> >
> > I believe that ideally we should "reset the clock" for connections
> > returned from the ConnectionPool. That way they would behave as newly
> > established connections regardless of how much time they have spent in the
> > connection pool. Is there a way to achieve this?
> >
> > Thanks
> > --
> > Hiranya Jayathilaka
> > Associate Technical Lead;
> > WSO2 Inc.;  http://wso2.org
> > E-mail: hira...@wso2.com;  Mobile: +94 77 633 3491
> > Blog: http://techfeast-hiranya.blogspot.com
> >
> 
> 
> 



-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: Support for DiffServ with Http transport

2012-02-10 Thread Oleg Kalnichevski

On Fri, 2012-02-10 at 11:24 +0100, Jørgen Nordmoen wrote:
> Thank you for your reply.
> 
> Setting the traffic class is exactly what we need. We have to do that
> to every client connection, but also need to have control over what is
> set for each connection as the clients will get different priority
> based on our parameters. 
> 
> We have looked into the classes you suggested, but we can't find any
> 'bind' method or anything related to the sending socket.
> 
> Best regards.

Jørgen

The #bind method Indika is referring to is available in the 4.2 (DEV)
branch of HttpCore. So, you need to make sure you are using the latest
HttpCore release (4.2-beta1)

Alternatively, you could use the #prepareSocket method of the I/O
reactor class to modify properties of newly created sockets.

Hope this helps

Oleg

> Jørgen Nordmoen , 
> On fr., 2012-02-10 at 14:22 +1100, indika kumara wrote:
> > Hi,
> > 
> > 
> > Would setTrafficClass(int tc) of java Socket API work for you?
> > 
> > 
> > You can access the connecting Socket by overrideing 'bind' of
> > DefaultNHttpClientConnection (httpcore) in
> > LoggingNHttpClientConnection (synapse) and set tranffic class
> > 
> > 
> > Also, you can modify 'bind' method of DefaultNHttpClientConnection
> > (httpcore) to set traficclass using provided http parameters of
> > 'bind' method.
> > 
> > 
> > Note: I do not have a good knowledge abut httpcore. So, I may wrong.
> > Please check with them.
> > 
> > 
> > Thanks,
> > 
> > 
> > Indika
> > 
> > 2012/2/9 Jørgen Nordmoen 
> > Hello.
> > 
> > Long explenation: We are a group of students tasked with
> > creating a
> > system which is able to prioritize messages in a network,
> > our customer
> > has asked us to use WSO2 ESB which is, as you most likely
> > know, just
> > Apache Synapse. We have one strict demand from the customer
> > and that is
> > that our system must be able to set the DiffServ field in
> > the IP
> > header. The system must be able to accept SOAP messages and
> > forward
> > them to a GlassFish server with the final endpoints. And
> > here is our
> > problem, since Synapse does not directly support DiffServ or
> > TOS we
> > need to implement it, but after much research we are still
> > not quite
> > sure how to do this and that is why this emails is sent. We
> > have some
> > leads on where we could alter,
> > org/apache/http/impl/nio/reactor/DefaultConnectingIOReactor
> > could be
> > extended in order to obtain the DiffServ value from the
> > MessageContext
> > and then alter the Socket connection, but we are not quite
> > sure as we
> > don't have the overview needed.
> > 
> > Question: 
> > Is there a way we could alter Synapse, Axis 2 and/or
> > HTTPCommons in order for us to support setting different
> > DiffServ
> > values to different clients? Hopefully we could alter
> > something which
> > we could either reach or interact with from a mediator which
> > we have to
> > write a cuple of anyway.
> > 
> > Best regards.
> > Jørgen Nordmoen ,
> > 
> > 
> > 
> > 
> > 
> 



-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

HttpCore 4.2 nearing API freeze

2012-01-17 Thread Oleg Kalnichevski

Folks

There has been a number of substantial changes to HttpCore in the trunk
(4.2 branch), especially in the protocol handling code. Synapse has its
own set of protocol handlers and is not affected by these changes, but I
think you might still want to get a feel of the new API and see if it
can be useful for Synapse. 

This also may be the last chance to make major changes to the new
interfaces and classes. If no one comes forth with new ideas and
feedback on the new API the next release is likely to be 4.2-BETA1.

Updated tutorial and javadocs can be found here:  

http://people.apache.org/~olegk/apidocs/
http://people.apache.org/~olegk/tutorial-4.2-draft/html/
http://people.apache.org/~olegk/tutorial-4.2-draft/pdf/httpcore-tutorial.pdf

Cheers

Oleg


-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

HttpCore dependency for Synapse 2.1.0; was Re: [VOTE] Release Synapse 2.1.0

2011-12-27 Thread Oleg Kalnichevski

On Tue, 2011-12-27 at 12:53 +0530, Ruwan Linton wrote:
> Kasun, also make sure to run the generated site through a link checker
> too.
> 

Assuming there will eventually be another RC, could you also please
consider upgrading HttpCore dependency to the latest GA release (4.1.4)?

Cheers

Oleg

> Thanks,
> Ruwan
> 
> On Tue, Dec 27, 2011 at 12:49 PM, Ruwan Linton
>  wrote:
> 
> 
> On Tue, Dec 27, 2011 at 12:09 PM, Hiranya Jayathilaka
>  wrote:
> 
> 
> On Tue, Dec 27, 2011 at 10:32 AM, Hiranya Jayathilaka
>  wrote:
> 
> 
> On Tue, Dec 27, 2011 at 4:58 AM, Andreas
> Veithen  wrote:
> -1
> 
> The Maven artifacts don't meet the
> requirements for publication to
> Maven Central (see [1] and in
> particular the link to [2]). In
> particular each artifact must be
> signed. Each artifact must also have
> an MD5 checksum (that is not
> explicitly mentioned in [2] because
> the
> maven-deploy-plugin normally takes
> care of this).
> 
> I'm not even sure if releasing
> artifacts using the old
> m2-ibiblio-rsync-repository thing is
> still supported. What is sure is
> that the only documented way is via
> Nexus.
> 
> 
> Can you please explain how that's done? Should
> we follow the instructions
> on 
> http://www.apache.org/dev/publishing-maven-artifacts.html?
> 
> 
> I believe this is the right set of instructions. 
> 
> Yes, these are the instructions from Apache, and you will
> probably have to meddle a bit with the Nexus documentation on
> release staging [1] too.
> 
> Thanks,
> Ruwan
> 
> [1] -
> http://www.sonatype.com/books/nexus-book/reference/staging.html
>  
> Kasun, shall we look into staging this release on
> Nexus? Out POMs already inherit from the root Apache
> POM (may be except for the xar plugin which we can
> fix). It also looks like Synapse project is already
> setup on Nexus. Like Ruwan said it seems the ground
> work is already done.
> 
> 
> Thanks,
> Hiranya
>  
>  
> 
> There is also a regression with
> respect to the project branding
> requirements. Apparently the change in
> r1051752 was never applied to
> the trunk and is missing in 2.1.0.
>  
> No it is available in 2.1. Take a look at the
> links available on the Main Menu of the site.
> It's not yet committed to the trunk. But we
> still haven't merged the new documentation
> into the trunk. That will be done pretty soon.
> 
> 
> Thanks,
> Hiranya
>  
> That seems to be a general problem
> in the Synapse project, namely that
> there is no effective strategy to
> manage the release branch and to
> ensure that all relevant changes are
> in the trunk. In
> Axis2/Rampart/Sandesha2 we have
> eradicated that
> problem by using a consistent (yet
> simple) strategy to manage the
> release/maintenance branches.
> 
> Andreas
> 
> [1]
> 
>

[jira] [Commented] (SYNAPSE-806) Incorporate the improvements in HTTPCORE-278 into Synapse when the 4.2 release of hc is available

2011-12-19 Thread Oleg Kalnichevski (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/SYNAPSE-806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13172170#comment-13172170
 ] 

Oleg Kalnichevski commented on SYNAPSE-806:
---

No, it does not. This improvement will be included in the next release off the 
4.2 branch.

Oleg

> Incorporate the improvements in HTTPCORE-278 into Synapse when the 4.2 
> release of hc is available 
> --
>
> Key: SYNAPSE-806
> URL: https://issues.apache.org/jira/browse/SYNAPSE-806
> Project: Synapse
>  Issue Type: Improvement
>Reporter: Rajika Kumarasiri
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: httpcore and httpcore-nio jars not available when building synapse online

2010-11-21 Thread Oleg Kalnichevski

On Sun, 2010-11-21 at 19:29 +0530, Amila Maha Arachchi wrote:
> Hi,
> 
> When building the nhttp module of synapse transports/core, there are
> two dependencies for httpcore-4.1-beta3-SNAPSHOT.jar and
> httpcore-nio-4.1-beta3-SNAPSHOT.jar. But these two are not available
> when buildinng online. I have checked in the two apache snapshot
> repositories, but there is no 4.1-beta3-SNAPSHOT available. Instead
> there is 4.0-beta3-SNAPSHOT. 
> 
> So, should the dependency be changed to 4.0-beta3-SNAPSHOT?
> 
> Thanks,
> Amila.

Amila et al

Please consider upgrading to the release version 4.1 instead.

Oleg



-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: Continuum as the Continuous Integration Solution

2010-11-12 Thread Oleg Kalnichevski

On Fri, 2010-11-12 at 07:31 +0530, Hiranya Jayathilaka wrote:
> Thanks for your input. My concern is that Hudson reports/notifications
> sometimes are completely useless. Also recently there have been so
> many false negatives reported on the list. I was hoping that may be
> Continuum doesn't suffer these limitations.
> 
> Thanks,
> Hiranya
> 
> 

We at HttpComponents use both Continuum and Hudson, though, I personally
find Hudson to be easier to manager and generally better. Both systems
tend to produce false positives when running low on resources or are
under heavy load. However in most cases the failures manifested
themselves as various timeouts (connect / response timeouts) rather any
particular flaw in the CI system.

The main source of trouble with Hudson for me were frequent failures
with deploying snapshots to the repository.apache.org, which, as Andreas
pointed out, has nothing to do with Hudson as such.

Cheers

Oleg

-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: Retiring from Synapse with the release of the UltraESB 1.0 GA

2010-05-19 Thread Oleg Kalnichevski

On Tue, 2010-05-18 at 21:37 +0530, Asankha C. Perera wrote:
> Hi All
> 
> Its been over 4 years since I started contributing to Synapse. I've 
> written loads of the code [1], fixed lots of issues [2] and helped many 
> users [3] and written many emails [4], documents, samples etc in this time..
> 
> With the 1.0 GA release of the UltraESB (which I am involved with now), 
> the time has now come for me to officially retire from active 
> participation on Synapse :)
> 
> Do follow me on my blog http://esbmagic.blogspot.com and read about what 
> I am upto at http://adroitlogic.org
> 
> cheers!
> asankha
> 

Best of luck, Asankha. I hope I will still be seeing you on the HC list.

Cheers

Oleg


-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: Advice on choosing http core NIO version for Synapse 1.2

2009-12-07 Thread Oleg Kalnichevski


Hubert, Eric wrote:

Oleg, thanks for your clarifications!


If the reactor shutdown was requested in an orderly fashion there is a
pretty good chance it will shut down cleanly and there will be nothing
to look at the audit log. The audit log usually comes handy when the
reactor shuts down due to an unexpected fatal error.

Hmmm, how can one know the difference?




An orderly I/O reactor shutdown must be explicitly initiated from 
application code. It is reasonable to assume it should be possible to 
tell whether a shutdown was unexpected or not based on the application 
internal state.


Oleg

-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: Advice on choosing http core NIO version for Synapse 1.2

2009-12-06 Thread Oleg Kalnichevski

Hubert, Eric wrote:

I cannot think of any good reason to continue using HttpCore older than
4.0.1. Upgrade would be quite recommended.

Oleg, thanks a lot for your quick response and suggestion. I think we will
update our integration system to 4.0.1 first, and see how it runs there.

The process of an I/O reactor shutdown is quite complex and therefore
lots of things can go sideways if a particular I/O worker terminates
abnormally due to a runtime or a fatal I/O error. To help deal with
postmortem analysis I/O reactors maintain so called exception log that
contains all exceptions thrown in the process of reactor shutdown
including the one that triggered it.

http://hc.apache.org/httpcomponents-core/tutorial/html/nio.html#d0e1287
Whenever an I/O reactor terminates it is advisable to examine the audit
log and if it contains any entries print them out to the application log.

Maybe I have to have a closer look at the code level for both Synapse and http
Core to get a better understanding... So please excuse, if my following
thoughts are incorrect and rather correct them.

Don't we generally have to differentiate between
1) situations the code using the http nio library initiates/requests a IOReactor shutdown and
2) those, where the http nio library does this on its own based on an IOReactorException?

For the first case I now understand, that one should always check the audit log
in order to also find out if there have been exceptions during the shutdown
process. AFAIK Synapse currently does not follow this suggestion.

If the reactor shutdown was requested in an orderly fashion there is a
pretty good chance it will shut down cleanly and there will be nothing
to look at the audit log. The audit log usually comes handy when the
reactor shuts down due to an unexpected fatal error.

For the second case I understood that the client code has a chance to intercept the
exception handling by providing an IOReactorExceptionHandler which can attempt to decide
which exceptions shall be considered recoverable and which not. This is the place where
the client can/should also log the cause of both IOExceptions and RuntimeExceptions. For
Synapse this is the case. Anyway it looks like there are situations where
IOReactorExceptions are thrown at other places without a chance for the client to
"intercept". In this cases the client code finds out that the IOReactor has
been shutdown or is in the process of being shutdown (IllegalStateException while calling
connect()) and can just attempt to restart it.

This is one possibility. Alternatively the reactor thread can intercept
the fatal exception that caused the shutdown, optionally examine the
audit log for additional information, and based on the result of the
analysis choose to restart the reactor. HttpCoreNIOListener and
HttpCoreNIOSender classes would be the ones to look at

http://svn.apache.org/repos/asf/synapse/trunk/java/modules/transports/core/nhttp/src/main/java/org/apache/synapse/transport/nhttp/HttpCoreNIOListener.java
http://svn.apache.org/repos/asf/synapse/trunk/java/modules/transports/core/nhttp/src/main/java/org/apache/synapse/transport/nhttp/HttpCoreNIOSender.java

Is it possible, that the actual cause of an IOReactor shutdown will be logged a
couple of time after it actually occurred?

HttpCore does not do logging by itself. I do not know Synapse that well
to answer this question.

Or to be more concrete, first error output:
ERROR 2009-12-02 10:50:34,802 [HttpClientWorker-97][][]
org.apache.synapse.core.axis2.Axis2Sender 'Unexpected error during sending
message out'
java.lang.IllegalStateException: I/O reactor has been shut down
at
org.apache.http.impl.nio.reactor.DefaultConnectingIOReactor.connect(DefaultConnectingIOReactor.java:176)
at
org.apache.synapse.transport.nhttp.HttpCoreNIOSender.sendAsyncRequest(HttpCoreNIOSender.java:392)

[... a few 100 log lines later ...]

FATAL 2009-12-02 10:50:35,031 [HttpCoreNIOSender][][]
org.apache.synapse.transport.nhttp.HttpCoreNIOSender 'Encountered an I/O error:
Failure registering channel with the selector'
org.apache.http.nio.reactor.IOReactorException: Failure registering channel
with the selector
at
org.apache.http.impl.nio.reactor.AbstractIOReactor.processNewChannels(AbstractIOReactor.java:220)
at
org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:153)
at
org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:70)
at
org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:324)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.nio.channels.ClosedChannelException
at
java.nio.channels.spi.AbstractSelectableChannel.configureBlocking(AbstractSelectableChannel.java:252)
at
org.apache.http.impl.nio.reactor.AbstractIOReactor.processNewChannels(AbstractIOReactor.java:217)
... 4 more

Re: Advice on choosing http core NIO version for Synapse 1.2

2009-12-05 Thread Oleg Kalnichevski

Hubert, Eric wrote:

Hi all,

we are currently using Synapse 1.2 with http-core-nio 4.0 beta2. From time to time and unfortunately not reproducible we encounter IOReactor shutdowns in our production environment. I would like to track down the actual cause of these shutdowns, but the logs reveal no detail.

I quickly went through the release notes of http core 4.0-beta3, 4.0 and 4.0.1.
HTTPCORE-169 looked quite interesting. I remember that some time back we tried
out 4.0 but stumbled across an issue related to chunked encoding. Unfortunately
my memory has flashed. It could be that it was related to HTTPCORE-175.

Would it be advisable to check out updating to 4.0.1? Is there any chance to
get some information about the actual cause in case of IOReactor terminations?

Thanks,
Eric

Hi Eric

I cannot think of any good reason to continue using HttpCore older than
4.0.1. Upgrade would be quite recommended.

http://hc.apache.org/httpcomponents-core/tutorial/html/nio.html#d0e1287

Whenever an I/O reactor terminates it is advisable to examine the audit
log and if it contains any entries print them out to the application log.

Hope this helps

Oleg

-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: Unit test failures

2009-11-18 Thread Oleg Kalnichevski


Andreas Veithen wrote:

I don't know what happened on the Hudson server during the last day,
but I've seen very strange test failures which are probably caused by
an issue with the machine. Probably we should just ignore them.

Andreas



Andreas,

Quite often Hudson server runs under quite a bit of a load and that 
helps shake out very nasty synchronization bugs that are otherwise not 
reproducible under lighter load.


Feel free to ignore me as I have not a slightest idea about the failing 
test case.


cheers

Oleg




On Mon, Nov 16, 2009 at 07:24, Asankha C. Perera  wrote:

Hi Andreas

See 



Could you take a look at this failure - is this the difference between
reported and actual bytes sent issue or something else?

cheers
asankha

--
Asankha C. Perera
AdroitLogic, http://adroitlogic.org

http://esbmagic.blogspot.com





-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: Binding nhttp transport to multiple network interfaces

2009-11-10 Thread Oleg Kalnichevski


Hubert, Eric wrote:

Hi Supun,

 

I think your understanding is correct and there is currently no way to 
address this requirement (if it is one).


 

The ListeningIORector of HTTP Core NIO is used with one 
ListenerEndpoint. I guess one would need to extend HttpCoreNIOListener 
to support multiple ListenerEndpoints. Actually Oleg and Asankha should 
know much better. I have never thought about this… I think the Http Core 
NIO Lib, should be able to cope with this.




One can actually open multiple listener endpoints on a single 
ListeningIORector and bind them to different physical interfaces. One 
thing I am not sure, though, if all of them can listen on the same port.


Oleg


 


Regards,

   Eric

 

 




If I understood the configuration correctly it can bind to one 
interface/network address or all of them. Is there a way to bind to 
something like to 2 out of 4 interfaces?





-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: Synapse build failure???

2009-10-11 Thread Oleg Kalnichevski


Ruwan Linton wrote:

Folks,

Does anybody seeing synapse nhttp transport test failures locally??

Thanks,
Ruwan



I am seeing several ERROR priority logs but tests are marked as passed 
nonetheless. It is quite possible my latest patch broke stuff, but I was 
seeing the same error logs before making my changes.


Oleg



--
Ruwan Linton
Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ru...@wso2.com ; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com



-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: [PATCH] Improved HTTP header and wire logging

2009-10-11 Thread Oleg Kalnichevski


Asankha C. Perera wrote:

Hi Oleg

I made some improvements to the logging facility of the NHTTP
transport.  Those include a more reliable HTTP header logging and
additional option for a full wire logging (everything that gets
written to and read from the underlying socket).

I also made all logging classes package private as they should have
never been a part of public API anyways.

Please review and let me know if the patch is okay to be committed.

Many thanks for this very useful feature.. the wire logging will be very
useful to debug issues.

Only addition I could recommend is that commented lines to enable this
be included into the default log4j.properties. Please do commit this patch

thanks
asankha




Patch committed. Please feel free to take over from here.

Cheers

Oleg

-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

[PATCH] Improved HTTP header and wire logging

2009-10-10 Thread Oleg Kalnichevski


Folks,

I made some improvements to the logging facility of the NHTTP transport. 
 Those include a more reliable HTTP header logging and additional 
option for a full wire logging (everything that gets written to and read 
from the underlying socket).


I also made all logging classes package private as they should have 
never been a part of public API anyways.


Please review and let me know if the patch is okay to be committed.

Cheers

Oleg
Index: 
modules/transports/core/nhttp/src/main/java/org/apache/synapse/transport/nhttp/LoggingNHttpClientHandler.java
===
--- 
modules/transports/core/nhttp/src/main/java/org/apache/synapse/transport/nhttp/LoggingNHttpClientHandler.java
   (revision 823846)
+++ 
modules/transports/core/nhttp/src/main/java/org/apache/synapse/transport/nhttp/LoggingNHttpClientHandler.java
   (working copy)
@@ -22,7 +22,6 @@
 
 import org.apache.commons.logging.Log;
 import org.apache.commons.logging.LogFactory;
-import org.apache.http.Header;
 import org.apache.http.HttpException;
 import org.apache.http.HttpResponse;
 import org.apache.http.nio.ContentDecoder;
@@ -34,31 +33,20 @@
  * Decorator class intended to transparently extend an {...@link 
NHttpClientHandler}
  * with basic event logging capabilities using Commons Logging. 
  */
-public class LoggingNHttpClientHandler implements NHttpClientHandler {
+class LoggingNHttpClientHandler implements NHttpClientHandler {
 
 private final Log log;
-private final Log headerlog;
 private final NHttpClientHandler handler;
 
 public LoggingNHttpClientHandler(
 final Log log, 
-final Log headerlog, 
 final NHttpClientHandler handler) {
 super();
 if (handler == null) {
 throw new IllegalArgumentException("HTTP client handler may not be 
null");
 }
 this.handler = handler;
-if (log != null) {
-this.log = log;
-} else {
-this.log = LogFactory.getLog(handler.getClass());
-}
-if (log != null) {
-this.headerlog = headerlog;
-} else {
-this.headerlog = LogFactory.getLog(LoggingUtils.HEADER_LOG_ID);
-}
+this.log = LogFactory.getLog(handler.getClass());
 }
 
 public void connected(final NHttpClientConnection conn, final Object 
attachment) {
@@ -109,13 +97,6 @@
 + response.getStatusLine() + getRequestMessageID(conn));
 }
 this.handler.responseReceived(conn);
-if (this.headerlog.isDebugEnabled()) {
-this.headerlog.debug("<< " + response.getStatusLine().toString());
-Header[] headers = response.getAllHeaders();
-for (int i = 0; i < headers.length; i++) {
-this.headerlog.debug("<< " + headers[i].toString());
-}
-}
 }
 
 public void inputReady(final NHttpClientConnection conn, final 
ContentDecoder decoder) {
Index: 
modules/transports/core/nhttp/src/main/java/org/apache/synapse/transport/nhttp/LoggingNHttpClientIOTarget.java
===
--- 
modules/transports/core/nhttp/src/main/java/org/apache/synapse/transport/nhttp/LoggingNHttpClientIOTarget.java
  (revision 823846)
+++ 
modules/transports/core/nhttp/src/main/java/org/apache/synapse/transport/nhttp/LoggingNHttpClientIOTarget.java
  (working copy)
@@ -1,200 +0,0 @@
-/*
- *  Licensed to the Apache Software Foundation (ASF) under one
- *  or more contributor license agreements.  See the NOTICE file
- *  distributed with this work for additional information
- *  regarding copyright ownership.  The ASF licenses this file
- *  to you under the Apache License, Version 2.0 (the
- *  "License"); you may not use this file except in compliance
- *  with the License.  You may obtain a copy of the License at
- *
- *   http://www.apache.org/licenses/LICENSE-2.0
- *
- *  Unless required by applicable law or agreed to in writing,
- *  software distributed under the License is distributed on an
- *   * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- *  KIND, either express or implied.  See the License for the
- *  specific language governing permissions and limitations
- *  under the License.
- */
-
-package org.apache.synapse.transport.nhttp;
-
-import java.io.IOException;
-import java.net.InetAddress;
-
-import org.apache.commons.logging.Log;
-import org.apache.commons.logging.LogFactory;
-import org.apache.http.Header;
-import org.apache.http.HttpConnectionMetrics;
-import org.apache.http.HttpException;
-import org.apache.http.HttpInetConnection;
-import org.apache.http.HttpRequest;
-import org.apache.http.HttpResponse;
-import org.apache.http.nio.NHttpClientHandler;
-import org.apache.http.nio.NHttpClientIOTarget;
-import org.apache.http.protocol.HttpContext;
-
-public class LoggingNHttpClientIOTarget 
-implements NHttpClientIOTarg

Re: Synapse with IBM JDK 1.5 over httpcore-nio

2009-09-25 Thread Oleg Kalnichevski

Ruwan Linton wrote:

Hi Oleg,

Thanks, Yes this does solve most part of the problem, may be we can make 
it a configuration as well apart from the automatic tuning that you are 
planing to do, so in case if the autodetection fails for enabling that 
users can do it manually using the nhttp.properties file.

But, it still brings IOReactor down on high loads, where SUN JDK has no 
issue at all in serving. I will dig more into the issue and share any 
information if I could find the issue.

How exactly does that happen? Are you seeing any exceptions?

Oleg

Thanks,
Ruwan

On Fri, Sep 25, 2009 at 1:29 PM, Oleg Kalnichevski <mailto:ol...@apache.org>> wrote:

On Fri, Sep 25, 2009 at 01:07:00PM +0530, Ruwan Linton wrote:
 > Has any one tried to run synapse on IBM JDK 1.5?? I have tried
this but
 > having some issue with the HTTP NIO transport :-(
 >
 > Oleg, I had a look at the issue [1] and tried synapse with the
4.1-alpha1
 > release of the httpcore, but still the issue persists. It seems
it is taking
 > a long time to send the request out from synapse to the actual
service. Any
 > clue on this?? Was not being able to capture the thread dump as well,
 > because when I tried to kill -3 synapse IO reactor sent on to a loop.
 >
 > Please note that this is IBM JDK 1.5.
 >
 > Thanks,
 > Ruwan
 >
 > [1] - https://issues.apache.org/jira/browse/HTTPCORE-155
 >
 > --
 > Ruwan Linton
 > Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
 > WSO2 Inc.; http://wso2.org
 > email: ru...@wso2.com <mailto:ru...@wso2.com>; cell: +94 77 341 3097
 > blog: http://ruwansblog.blogspot.com

Ruwan,

The IBM JRE compatibility mode needs to be activated using this
parameter:

http://hc.apache.org/httpcomponents-core/httpcore-nio/apidocs/org/apache/http/nio/params/NIOReactorPNames.html#INTEREST_OPS_QUEUEING

Per default HttpCore assumes the underlying JRE has a sane
implementation of
SelectionKey.

I will be out of contract as of next week and will have lots of
spare time on
my hands. I am planning to contribute a piece of code to Synapse
that turns on
interest op queueing depending on the JRE and as well as some other
minor
imrovements.

Cheers

Oleg

-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
<mailto:dev-unsubscr...@synapse.apache.org>
For additional commands, e-mail: dev-h...@synapse.apache.org
<mailto:dev-h...@synapse.apache.org>

--
Ruwan Linton
Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ru...@wso2.com <mailto:ru...@wso2.com>; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com

-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: Synapse with IBM JDK 1.5 over httpcore-nio

2009-09-25 Thread Oleg Kalnichevski

On Fri, Sep 25, 2009 at 01:07:00PM +0530, Ruwan Linton wrote:
> Has any one tried to run synapse on IBM JDK 1.5?? I have tried this but
> having some issue with the HTTP NIO transport :-(
> 
> Oleg, I had a look at the issue [1] and tried synapse with the 4.1-alpha1
> release of the httpcore, but still the issue persists. It seems it is taking
> a long time to send the request out from synapse to the actual service. Any
> clue on this?? Was not being able to capture the thread dump as well,
> because when I tried to kill -3 synapse IO reactor sent on to a loop.
> 
> Please note that this is IBM JDK 1.5.
> 
> Thanks,
> Ruwan
> 
> [1] - https://issues.apache.org/jira/browse/HTTPCORE-155
> 
> -- 
> Ruwan Linton
> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
> WSO2 Inc.; http://wso2.org
> email: ru...@wso2.com; cell: +94 77 341 3097
> blog: http://ruwansblog.blogspot.com

Ruwan,

The IBM JRE compatibility mode needs to be activated using this parameter:

http://hc.apache.org/httpcomponents-core/httpcore-nio/apidocs/org/apache/http/nio/params/NIOReactorPNames.html#INTEREST_OPS_QUEUEING

Per default HttpCore assumes the underlying JRE has a sane implementation of
SelectionKey.

I will be out of contract as of next week and will have lots of spare time on
my hands. I am planning to contribute a piece of code to Synapse that turns on
interest op queueing depending on the JRE and as well as some other minor
imrovements.

Cheers

Oleg

-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: Synapse 1.3 - Ruwan Linton as the Release Manager

2009-09-05 Thread Oleg Kalnichevski


Asankha C. Perera wrote:

Hi All

We have been waiting to make the 1.3 release for sometime now.. but
mainly due to the dependency project releases it is still pending. As I
think Ruwan is in a better position to get these releases out in time, I
am requesting him to take over the role of Release Manager for 1.3.

Here is my +1 for him to get things rolling

thanks
asankha



+1

-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: Build hangs during unit test

2009-07-24 Thread Oleg Kalnichevski

On Thu, Jul 23, 2009 at 04:59:19PM +0200, Andreas Veithen wrote:
> Runs fine here on Sun JDK 1.5, but hangs on IBM JDK 1.6 (both on Windows).
> 
> Andreas
> 

Andreas,

Incompatibility with IBM JREs is a known issue. It will be addressed in the 4.1
release of HttpCore.

Oleg



> On Thu, Jul 23, 2009 at 16:44, Asankha C. Perera wrote:
> > Andreas - I am seeing the test kit tests hang, during the
> > HttpCoreNIOSender testing.. Does the tests pass for you?
> >
> > Does any others see this issue?
> >
> > Attached is a thread dump
> >
> > cheers
> > asankha
> >
> > --
> > Asankha C. Perera
> > AdroitLogic, http://adroitlogic.org
> >
> > http://esbmagic.blogspot.com
> >
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
> > For additional commands, e-mail: dev-h...@synapse.apache.org
> >
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
> For additional commands, e-mail: dev-h...@synapse.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: Supporting Multiple SSL Configurations at Sender

2009-07-22 Thread Oleg Kalnichevski

>>> may be
> >>>>>>>> only feasible one.
> >>>>>>>
> >>>>>>>
> >>>>>>> The X509ExtendedKeyManager abstract class comes from the
> >>>>>>> javax.net.ssl package. It's implementations are JDK specific. But
> >>>>>>> technically that shouldn't prevent us from wrapping it. Need to dig 
> >>>>>>> deeper
> >>>>>>> into the API to get a clear idea on this.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Hiranya
> >>>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Indika
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Tue, Jul 21, 2009 at 5:23 PM, Ruwan Linton <
> >>>>>>>> ruwan.lin...@gmail.com> wrote:
> >>>>>>>>
> >>>>>>>>> Do we have the required control of figuring out the right identity
> >>>>>>>>> certificates over the endpoint in this approach?
> >>>>>>>>>
> >>>>>>>>> For example can we provide the certificate to be used for a
> >>>>>>>>> particular endpoint (may be as an alias) in the endpoint 
> >>>>>>>>> configuration? I
> >>>>>>>>> guess that is the initial requirement.
> >>>>>>>>>
> >>>>>>>>> Ruwan
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Tue, Jul 21, 2009 at 4:31 PM, indika kumara <
> >>>>>>>>> indika.k...@gmail.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> +1 for this approach if possible. It seems possible (cannot tell
> >>>>>>>>>> exactly). Within SSLIOSessionHandler (httpcore), in the following 
> >>>>>>>>>> method
> >>>>>>>>>>
> >>>>>>>>>> *public void initialize(SSLEngine sslengine, HttpParams params) ,
> >>>>>>>>>> *
> >>>>>>>>>>
> >>>>>>>>>> we can put application specific thing into SSLSession, then access
> >>>>>>>>>> within KeyManager implementation to pick the correct alias .
> >>>>>>>>>>
> >>>>>>>>>> BTW, the actual implementation of the X509ExtendedKeyManager is in
> >>>>>>>>>> *com.sun.net.ssl.internal.ssl*.
> >>>>>>>>>>
> >>>>>>>>>> Indika
> >>>>>>>>>>
> >>>>>>>>>> On Tue, Jul 21, 2009 at 4:11 PM, Andreas Veithen<
> >>>>>>>>>> andreas.veit...@gmail.com> wrote:
> >>>>>>>>>> > A quick look at the Javadoc shows that X509ExtendedKeyManager
> >>>>>>>>>> has
> >>>>>>>>>> > access to the SSLEngine from which the SSLSession can be
> >>>>>>>>>> retrieved. On
> >>>>>>>>>> > the other hand, SSLSession has methods
> >>>>>>>>>> getValue/putValue/removeValue
> >>>>>>>>>> > to store "application layer data". This could be a proper
> >>>>>>>>>> solution. To
> >>>>>>>>>> > be investigated.
> >>>>>>>>>> >
> >>>>>>>>>> > Andreas
> >>>>>>>>>> >
> >>>>>>>>>> > On Tue, Jul 21, 2009 at 12:32, Paul Fremantle
> >>>>>>>>>> wrote:
> >>>>>>>>>> >> I agree. Maybe we could wrap the key manager and then be able
> >>>>>>>>>> to
> >>>>>>>>>> >> implement any kind of complexity (e..g multiple key stores,
> >>>>>>>>>> etc)
> >>>>>>>>>> >> behind that. The only question I have is whether you can pass
> >>>>>>>>>> context
&g

Re: Supporting Multiple SSL Configurations at Sender

2009-07-21 Thread Oleg Kalnichevski

On Tue, Jul 21, 2009 at 11:22:58AM +0200, Andreas Veithen wrote:
> > Well, if not through different stores, how can we let the KeyManager know
> > what cert to use for this particular endpoint?
> 
> If I remember well, this is how it works: during the handshake, the
> server presents a list of trusted CAs to the client. The client than
> selects the certificate that is signed (directly or indirectly) by
> that CA and uses that to authenticate. I'm pretty sure this is what
> happens when you create a java.net.URL with the https scheme and call
> openConnection on it. Since behind the scene this uses an SSLContext,
> chances are high that it also works with our HTTPS transport (or that
> it would be pretty easy to make it work).
> 
> Of course this only satisfies the requirement if the two endpoints use
> different CAs, which should be the usual case.
> 
> Andreas
> 

Hi Andreas

I may be wrong about it but I believe the client can present whatever client
cert it pleases. That cert does not _have_ to be signed by one of the trusted
CA certs sent to client by the server. For instance, common browsers simply pop
up a UI dialog and let you pick any client certificate available in the
certificate store, if the server requests client authentication in the course
of SSL context negotiation. 

Oleg



> -
> To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
> For additional commands, e-mail: dev-h...@synapse.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: Supporting Multiple SSL Configurations at Sender

2009-07-21 Thread Oleg Kalnichevski

On Tue, Jul 21, 2009 at 09:42:00AM +0530, Hiranya Jayathilaka wrote:
> Hi Indika,
> 
> On Mon, Jul 20, 2009 at 10:19 PM, indika kumara wrote:
> 
> > I am agree with asankha ,
> >
> > Requirement is to enable to represent multiple identities by synapse itself
> > and also call to  external services whose  identities are different. For
> > first requirement it may need to expose identities at proxy services level.
> > For second requirement, it may need ability to specify and use multiple
> > client certificates at endpoint level when calling different external
> > services.
> >
> > Giving Multiple SSLContexts is the scalable solution. Specially, for the
> > requirement one, using reactor will not be scalable.  Even for second
> > requirement.
> >
> > But, it seems in the current IOreactor implementation it is only possible
> > to be given one SSLContext (with IOEventDispatch).
> >
> > Seems like we need a new IOEventDispatch implementation that take Map of
> > SSLContexts (or composite IOEventDispatch) and then within method,
> 
> 
> +1 to this approach. I think this is the best possible solution if it's
> doable.
> 
> Thanks,
> Hiranya
> 
> 

Custom IOEventDispatch is the way to go. Essentially all you want is ability to
create a specific SSL context for each newly IOSession based on a particular
set of criteria such as remote peer's IP or DNS name.

Cheers

Oleg


> >
> >
> > *public void connected (final IOSession session)*
> >
> > Based on information on IOSession session, pick the correct SSLContext.   I
> > am not sure possibility of this, but Asankha or Oleg sure knows this.
> >
> > Thanks
> > Indika
> >
> >
> > >
> > > I guess the real use case is the ability to use multiple identity
> > > certificates when communicating out. A usual use case is that one
> > > organization would need to use an identity certificate A when talking to
> > an
> > > endpoint of Company A, and another identity certificate B when talking to
> > an
> > > endpoint of Company B etc, when using 2-way SSL. This does not
> > necessarily
> > > require the support for multiple keystores, unless I have missed
> > something.
> > >
> > > I have not yet looked into details.. but I do not directly see the need
> > for
> > > multiple IO reactors to support this.. but just multiple SSLContexts.
> > >
> > > cheers
> > > asankha
> > >
> > > --
> > > Asankha C. Perera
> > > AdroitLogic, http://adroitlogic.org
> > >
> > > http://esbmagic.blogspot.com
> > >
> > >
> > >
> > >
> >
> >
> 
> 
> -- 
> Hiranya Jayathilaka
> Software Engineer;
> WSO2 Inc.;  http://wso2.org
> E-mail: hira...@wso2.com;  Mobile: +94 77 633 3491
> Blog: http://techfeast-hiranya.blogspot.com

-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

HttpCore 4.0.1 release preview

2009-06-13 Thread Oleg Kalnichevski


Asankha

Could you please test Synapse for compatibility with the upcoming 
HttpCore 4.0.1 release?


Release notes can be found here:
http://people.apache.org/~olegk/httpcore-4.0.1-preview/RELEASE_NOTES.txt

Packages:
http://people.apache.org/~olegk/httpcore-4.0.1-preview/

Oleg

-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: Follow-up to HTTPCORE-193

2009-05-05 Thread Oleg Kalnichevski

On Tue, May 05, 2009 at 08:49:27AM +0530, Asankha C. Perera wrote:
> Hi Oleg
>
> I think the fixes looks fine, and can be confirmed by visually as I  
> cannot think of a test w.r.t Synapse to confirm this. Do you plan to  
> open a new JIRA for this in HttpCore, or include as an enhancement of  
> #193? I will update the current binary patch for HTTPCORE-193 included  
> in Synapse  accordingly to either way
>

Hi Asankha

I think this is pretty much the same defect reported as HTTPCORE-193. I also
added an additional entry to th release notes about the application event mask
issue. I did not raise a separate JIRA for it. I can do it if necessary.

Oleg

> thanks
> asankha
>
> Asankha C. Perera wrote:
>> Hi Oleg
>>> Asankha and all,
>>>
>>> I found two more issues in the SSLIOSession class of HttpCore, one of 
>>> which is related to HTTPCORE-193 and therefore directly impacts  
>>> SYNAPSE-523.
>>>
>>> http://svn.apache.org/viewvc?view=rev&revision=771126
>>>
>>> Could you please test those changes for compatibility with Synapse?
>> Sure, I will check these with Synapse. Many thanks for the follow up  
>> on this.
>>
>> cheers
>> asankha
>>
>
>
> -- 
> Asankha C. Perera
> AdroitLogic, http://adroitlogic.org
>
> http://esbmagic.blogspot.com
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
> For additional commands, e-mail: dev-h...@synapse.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Follow-up to HTTPCORE-193

2009-05-03 Thread Oleg Kalnichevski


Asankha and all,

I found two more issues in the SSLIOSession class of HttpCore, one of 
which is related to HTTPCORE-193 and therefore directly impacts SYNAPSE-523.


http://svn.apache.org/viewvc?view=rev&revision=771126

Could you please test those changes for compatibility with Synapse?

Cheers

Oleg

-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: [VOTE] Release plan for Synapse 1.3

2009-03-31 Thread Oleg Kalnichevski

On Tue, 2009-03-31 at 16:48 +0530, Asankha C. Perera wrote:
> Hi Oleg
> > What are your plans for SYNAPSE-186? I always thought the implementation
> > of this feature would entail a pretty significant overhaul of the NIO
> > HTTP transport. I am not sure it is doable within the given time frame. 
> >   
> This is in my TODO list, and I have been following up on some REST code 
> offered by Mike [1] to work on this one. First I will only support the 
> most common of REST, ie full support for GET as per Axis2 support.
> 
> Next, PUT/DELETE (SYNAPSE-477), HEAD and OPTIONS etc. Following 
> redirects would actually be handled last - and yes, its going to require 
> significant effort. We should also plan to handle 386, HTTPS tunnelling, 
> non-preemptive authentication support etc.. but most probably all after 1.3
> 
> thanks
> asankha
> 
> [1] http://markmail.org/message/b44pfwsgrxggt32p
> 

OK. I see. If more complex stuff is out of scope for 1.3, this should be
doable.

+1 to the release plan.

Oleg 


-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: [VOTE] Release plan for Synapse 1.3

2009-03-31 Thread Oleg Kalnichevski

 Improvement
> SYNAPSE-384 
> Archived
> Repository
> and
> Read-Only
> Registry
> Unassigned
> Tanmay
> saha
> Major
> 
> 
> Improvement
> SYNAPSE-377 
> Improve
> MediatorDeployer to support Startups and embedded JARs
> Andreas
> Veithen
> Andreas
> Veithen
> Major
> 
> 
> Improvement
> SYNAPSE-375 
> Make
> statistics
> collection
> fine
> grained
> indika
> priyantha
> kumara
> indika
> priyantha
> kumara
> Major
> 
> 
> Improvement
> SYNAPSE-502 
> improve
> the vfs
> transport
> to use
> temporary
> file
> Unassigned
> Otto Frost
> Major
> Good to
> fix
> Improvement
> SYNAPSE-487 
> Provide a
> mechanism
> to get
> access to
> client
> provided
> X509
> Certificate within mediators
> Asankha C.
> Perera
> Lucas
> Moten
> Major
> 
> 
> Improvement
> SYNAPSE-507 
> Improve
> vfs sftp
> transport
> to handle
> login with
> IdentityFile (public/private keys)
> Unassigned
> Otto Frost
> Major
> 
> 
> Improvement
> SYNAPSE-333 
> Proposal
> to
> improve/consolidate session-affine load balancing options
> Unassigned
> Eric
> Hubert
> Major
> 
> 
> Improvement
> SYNAPSE-421 
> Allow
> Class
> mediator
> properties
> to be
> loaded
> from the
> Registry
> Unassigned
> Senaka
> Fernando
> Minor
> 
> 
> Improvement
> SYNAPSE-497 
> Synapse
> Spring
> Mediator
> Sample
> Ruwan
> Linton
> Charith
> Dhanushka
> Wickramarachchi
> Minor
> Must fix
> Improvement
> SYNAPSE-495 
> Spring
> version
> update
> Unassigned
> Charith
> Dhanushka
> Wickramarachchi
> Minor
> Must fix
> Improvement
> SYNAPSE-473 
> Synapse
> Clustering
> Documentation
> Unassigned
> Eric
> Hubert
> Minor
> 
> 
> Improvement
> SYNAPSE-343 
> Propose a
> way to
> handle
> messages
> that are
> received
> after the
> first
> message is
> processed
> through
> the
> onComplete
> method of
> the
> Aggregate
> mediator
> Ruwan
> Linton
> Evanthika
> Amarasiri
> Minor
> Good to
> fix
> Improvement
> SYNAPSE-522 
> Enhance
> the Send
> mediator
> AND/OR
> Endpoints,
> to accept
> properties
> Unassigned
> Asankha C.
> Perera
> Minor
> 
> 
> Improvement
> SYNAPSE-306 
> Merge
> Hessian
> and binary
> message
> builders/formatters
> Unassigned
> Andreas
> Veithen
> Minor
> 
> 
> Improvement
> SYNAPSE-526 
> Add server
> connector
> to make
> use of
> existing
> MBeans
> Unassigned
> Eric
> Hubert
> Minor
> 
> 
> New
> Feature
> SYNAPSE-346 
> Support
> dynamic
> deployment
> of proxy
> services
> Ruwan
> Linton
> Sumeet Vij
> Major
> 
> 
> New
> Feature
> SYNAPSE-329 
> Proxy
> Service
> should
> support
> engaging
> only
> addressing
> over it
> Ruwan
> Linton
> Ruwan
> Linton
> Major
> 
> 
> New
> Feature
> SYNAPSE-283 
> Create
> Debian
> packages
> for
> Synapse
> Andreas
> Veithen
> Andreas
> Veithen
> Major
> 
> 
> New
> Feature
> SYNAPSE-383 
> AJP 1.3
> Transport
> Listener/Sender
> Unassigned
> Jonathan
> Holmes
> Major
> 
> 
> New
> Feature
> SYNAPSE-385 
> Externalize environment specific variables from xml definition files
> Unassigned
> Tanmay
> saha
> Major
> 
> 
> New
> Feature
> SYNAPSE-474 
> Clover
> Code
> coverage
> for
> Synapse
> Unassigned
> Ilanthirayan Paramanathan
> Major
> Check
> New
> Feature
> SYNAPSE-180 
> Require
> the
> ability to
> throttle
> by
> concurrency within a cluster
> indika
> priyantha
> kumara
> Asankha C.
> Perera
> Major
> 
> 
> New
> Feature
> SYNAPSE-347 
> Support
> Dynamic
> Deployment
> of Tasks
> Unassigned
> Scott
> Hoggarth
> Major
> 
> 
> New
> Feature
> SYNAPSE-263 
> Implementing a message store/ message redelivery
> Unassigned
> Jens
> Goldhammer
> Major
> 
> 
> New
> Feature
> SYNAPSE-282 
> Allow
> Synapse to
> consume
> syslog
> events
> Andreas
> Veithen
> Andreas
> Veithen
> Minor
> 
> 
> New
> Feature
> SYNAPSE-229 
> Provide
> ability to
> collect
> and expose
> statistics
> and
> performance information at better granularity
> Asankha C.
> Perera
> Asankha C.
> Perera
> Minor
> 
> 
> New
> Feature
> SYNAPSE-411 
> Expanded
> hessian
> support
> with
> SOAP/hessian transformation
> Unassigned
> Ralph
> Henze
> Minor
> 
> 
> Test
> SYNAPSE-350 
> Improve
> unit tests
> for VFS
> transport
> Andreas
> Veithen
> Andreas
> Veithen
> Minor
> 
> 
> Wish
> SYNAPSE-396 
> Consider
> reducing
> requisite
> dependencies of Synapse Core
> Andreas
> Veithen
> Oleg
> Kalnichevski
> Major
> 
> The Priority column should be read as follows:
> Must fix - is most definitely a blocker for 1.3
> Good to fix - if the developers have time to work on these issues, we
> should do our best to fix them
> Check - these may be fixed already, and needs verification
> Minor - are trivial issues to fix, so we should try to fix as much of
> these as we can, but these are not high in priority
> Later - we will fix these after 1.3
> 
> 
> -- 
> Asankha C. Perera
> AdroitLogic, http://adroitlogic.org
> 
> http://esbmagic.blogspot.com
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
> For additional commands, e-mail: dev-h...@synapse.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

[jira] Commented: (SYNAPSE-481) Outbound proxy server settings do not appear to be working

2009-03-12 Thread Oleg Kalnichevski (JIRA)


[ 
https://issues.apache.org/jira/browse/SYNAPSE-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12681318#action_12681318
 ] 

Oleg Kalnichevski commented on SYNAPSE-481:
---

Asankha, 

Basically there are two potentially difficult aspects:
(1) ability to upgrade a plain connection to a SSL/TLS secured one. Can be done 
using core components only, but some custom code will still be required 
(2) ability to authenticate with the proxy. This automatically entails bringing 
it almost half of HttpClient functionality.

Oleg

> Outbound proxy server settings do not appear to be working
> --
>
> Key: SYNAPSE-481
> URL: https://issues.apache.org/jira/browse/SYNAPSE-481
> Project: Synapse
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 1.2
> Environment: Testing on Ubuntu Linux, Java 1.5 and 6.0
>Reporter: Jeff Davis
>Assignee: Asankha C. Perera
>
> The outbound proxy server settings, outline in this document - 
> http://wso2.org/library/3346, do not appear to be working. For example, I 
> tried this setting in the axis2.xml file:
> 
>  
>  
>   localhost
>   
>   
> 
> other stuff
>  
> My local outbound proxy that I was testing with, TinyProxy (available with 
> most Linux distro's) doesn't show any activity (but I've confirmed it's 
> working properly via some other programs) when I attempt to call a remote 
> endpoint service. I also attempted using the Java system properties option, 
> but that similarly didn't appear to be work.
> Unfortunately, a lot of companies are now restricting all outbound traffic 
> except through a proxy, so this can be a significant problem. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

[jira] Commented: (SYNAPSE-481) Outbound proxy server settings do not appear to be working

2009-03-12 Thread Oleg Kalnichevski (JIRA)


[ 
https://issues.apache.org/jira/browse/SYNAPSE-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12681289#action_12681289
 ] 

Oleg Kalnichevski commented on SYNAPSE-481:
---

Asankha,

While simple (plain) HTTP request proxying should be absolutely trivial ti 
implement, HTTPS connection tunneling could be a _major_ undertaking. If you 
intend to support HTTPS tunneling at some point as well, we should probably 
consider starting a project to build an async version of HttpClient out of HC, 
so other people could potentially contribute to that effort. It will not be an 
easy task.

Oleg

> Outbound proxy server settings do not appear to be working
> --
>
> Key: SYNAPSE-481
> URL: https://issues.apache.org/jira/browse/SYNAPSE-481
> Project: Synapse
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 1.2
> Environment: Testing on Ubuntu Linux, Java 1.5 and 6.0
>Reporter: Jeff Davis
>Assignee: Asankha C. Perera
>
> The outbound proxy server settings, outline in this document - 
> http://wso2.org/library/3346, do not appear to be working. For example, I 
> tried this setting in the axis2.xml file:
> 
>  
>  
>   localhost
>   
>   
> 
> other stuff
>  
> My local outbound proxy that I was testing with, TinyProxy (available with 
> most Linux distro's) doesn't show any activity (but I've confirmed it's 
> working properly via some other programs) when I attempt to call a remote 
> endpoint service. I also attempted using the Java system properties option, 
> but that similarly didn't appear to be work.
> Unfortunately, a lot of companies are now restricting all outbound traffic 
> except through a proxy, so this can be a significant problem. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: [VOTE] Asankha Perera as the Synapse 1.3 Release Manager

2009-02-28 Thread Oleg Kalnichevski


Ruwan Linton wrote:

Hi devs,

I think we should now officially start with the 1.3 release process.

I'd like to propose Asankha Perera as release manager of the 1.3 
release. You all know Asankha and the fine job he has done on Synapse, 
and I think he is the best person to handle this release.


Here is my +1.



+1

Oleg


-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: LoggingNHttpServerIOTarget target delegate

2008-12-24 Thread Oleg Kalnichevski

On Wed, 2008-12-24 at 08:55 -0700, Michael Clark wrote:
> Hi all,
> 
> In org.apache.synapse.transport.nhttp.LoggingNHttpServerIOTarget, most 
> methods are delegated verbatim to the 'target' member variable. 
> However, both 'LoggingNHttpServerIOTarget#resetInput' and 
> 'LoggingNHttpServerIOTarget#resetOutput' are not delegated verbatim. 
> Rather, these two calls result in 'this.target.requestInput()' and 
> 'this.target.requestOutput()' being invoked, respectively.  I apologize 
> if this is newbie question, but I am new to Synapse.  Can you help me 
> understand why these two methods not delegated verbatim?
> 

Because I am getting old, forgetful and stupid (most likely already am).
Of course, those methods are utterly wrong. 

I'll put some more work into logging decorators in the coming days and
fix those broken methods.

Oleg  


> thanks,
> 
> Mike
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
> For additional commands, e-mail: dev-h...@synapse.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: Synapse & HttpCore NIO

2008-12-24 Thread Oleg Kalnichevski

On Tue, 2008-12-23 at 23:26 +0100, Andreas Veithen wrote:
> All,
> 
> I've upgraded Synapse to the latest version (4.0-beta3) of the
> HttpCore NIO library. There was one existing known issue [1] that
> prevented us from upgrading, and I believe this issue is now solved.
> All nightly builds [2] are now shipped with (and require!) httpcore
> 4.0-beta3. If you notice any issues related to the NIO HTTP transport
> with snapshot versions of Synapse, please check that you are using the
> right version of HttpCore and let us know if the problem persists.
> 
> Regards,
> 
> Andreas
> 

Hi Andreas

I took a (cursory) look at the latest changes to the HTTP transport and
they looked fine to me.

Cheers

Oleg


> [1] https://issues.apache.org/jira/browse/SYNAPSE-479
> [2] 
> http://hudson.zones.apache.org/hudson/job/Synapse%20-%20Trunk/org.apache.synapse$synapse-distribution/lastBuild/
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
> For additional commands, e-mail: dev-h...@synapse.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Re: Committing patch contributed for MIME message parser and serializer based on Apache mime4j [WSCOMMONS-387]

2008-12-01 Thread Oleg Kalnichevski


Thilina Gunarathne wrote:

Hi All.
Wonder why Oleg removed the patch, without even committing it to a 
branch.. I did not even get a chance to look in to the new patch with 
deferred building :(...


Current API and impl's were designed in a desperate manner to get MTOM & 
SWA working, when we found that java mail does not work well for us. So 
I'm sure there are many places where we can improve the architecture and 
the API. I would like to volunteer and team up with Oleg to fix the 
inflexibility and the API that people were reporting in this thread. 
Hopefully we can eventually come up with an abstract API to support 
different implementations and to plug in MIME4J.


For this I would like to understand the inflexibility and the concrete 
use cases in a more detailed manner, so that we'll not just think of 
MTOM & SWA when reorganising these things. I need support from all of 
you guys for this matter.




Thilina,

Just put the existing implementation behind an abstract API and I will 
see if the same API can be implemented based on mime4j.


Cheers

Oleg



thanks,
Thilina


--Thilina Gunarathne  - http://thilinag.blogspot.com



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Committing patch contributed for MIME message parser and serializer based on Apache mime4j [WSCOMMONS-387]

2008-11-22 Thread Oleg Kalnichevski


Davanum Srinivas wrote:

You know what. Am tired of this game of control. Just do whatever you
want. I withdraw my -1.

thanks,
dims

  
I removed the patch and closed the issue. If ever find time, I'll try to 
put together another patch based on the exisitng MIME code.


Oleg

On Sat, Nov 22, 2008 at 10:18 AM, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
  

Asankha,

- Existing Axis2 test harness should work out of the box
- There should be no extra dependency jar (MIME4J) in the default
implementation.

Any patch that covers both will get my +1

thanks,
dims

On Sat, Nov 22, 2008 at 9:09 AM, Asankha C. Perera <[EMAIL PROTECTED]> wrote:


Dims

The package org.apache.axiom.mime defines the interfaces, and the package
org.apache.axiom.mime.impl which implements these using Mime4J. I don't see
why anyone else cannot implement these interfaces with any other
implementation..

Is your view on this still based on the following?
/"One problem from my personal point of view is that for JAXWS support we
need javamail :( to be compliant to the spec/" [1]

asankha

[1] http://markmail.org/message/kfs3mpfkkwvwbdb2

  

without using MIME4J.

thanks,
dims

On Sat, Nov 22, 2008 at 7:27 AM, Oleg Kalnichevski <[EMAIL PROTECTED]>
wrote:



On Thu, 2008-11-20 at 11:34 -0500, Davanum Srinivas wrote:

  

Oleg,

I totally agreed with you if you scroll back a few emails. Yes, we
need to fix *that*. Any patch to do that will be *very* welcome.




Ironically enough, this is precisely what the patch does.

Oleg

  

--
Asankha C. Perera
http://adroitlogic.org

http://esbmagic.blogspot.com


  


--
Davanum Srinivas :: http://davanum.wordpress.com






  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Committing patch contributed for MIME message parser and serializer based on Apache mime4j [WSCOMMONS-387]

2008-11-22 Thread Oleg Kalnichevski

On Thu, 2008-11-20 at 11:34 -0500, Davanum Srinivas wrote:
> Oleg,
> 
> I totally agreed with you if you scroll back a few emails. Yes, we
> need to fix *that*. Any patch to do that will be *very* welcome.
> 

Ironically enough, this is precisely what the patch does.

Oleg



> thanks,
> -- dims
> 
> On Thu, Nov 20, 2008 at 11:31 AM, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:
> > On Thu, 2008-11-20 at 10:08 -0600, Thilina Gunarathne wrote:
> >> Hi,
> >>
> >>
> >> Thilina, while I agree with "don't fix if it ain't broke",
> >> this is an *improvement* .. not a fix for the sake of a fix. I
> >> think we should do it.
> >>
> >> As even Oleg mentioned the MIME4J is around 15% slower than the
> >> current impl..  IMHO the issue which this patch tries to address (in
> >> memory buffering of SOAP part) is not much of an issue when used with
> >> attachments, cause most of the time people use small soap envelopes
> >> when they use attachments. Also I'm not sure whether MIME4J is as
> >> battle tested as the Axis2's current implementation.
> >>
> >
> > The real issue here has nothing to do with performance or even
> > unnecessary in-memory buffering. It is rather about inflexibility of the
> > existing MIME processing API and the hard coupling of what is meant to
> > be an abstract API with Attachment impl classes. Mime4j is merely an
> > implementation detail.
> >
> > Oleg
> >
> >>
> >> I totally agree that we should support MIME4J and we should do
> >> "improvements".. But since this does not come with any urgent fixes
> >> for something that's badly broken, I would prefer to do it in a little
> >> bit of a controlled fashion.. May be support both the impl's or do
> >> this in a branch first.
> >>
> >>
> >> Also I'm sorry, but I don't really like the approach people are taking
> >> in this issue.. Why is it that the decision is between commit the
> >> patch directly to trunk  or throw away... Why cant' we come to a
> >> middle ground..
> >>
> >>
> >> thanks,
> >> Thilina
> >>
> >>
> >>
> >>
> >> If it breaks something (like interop) we can always revert ..
> >>
> >> Sanjiva.
> >> --
> >> Sanjiva Weerawarana, Ph.D.
> >> Founder & Director; Lanka Software Foundation;
> >> http://www.opensource.lk/
> >> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> >> Member; Apache Software Foundation; http://www.apache.org/
> >> Visiting Lecturer; University of Moratuwa;
> >> http://www.cse.mrt.ac.lk/
> >>
> >> Blog: http://sanjiva.weerawarana.org/
> >>
> >>
> >>
> >> --
> >> Thilina Gunarathne  - http://thilinag.blogspot.com
> >
> >
> 
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Committing patch contributed for MIME message parser and serializer based on Apache mime4j [WSCOMMONS-387]

2008-11-20 Thread Oleg Kalnichevski

On Thu, 2008-11-20 at 10:08 -0600, Thilina Gunarathne wrote:
> Hi,
> 
> 
> Thilina, while I agree with "don't fix if it ain't broke",
> this is an *improvement* .. not a fix for the sake of a fix. I
> think we should do it.
>  
> As even Oleg mentioned the MIME4J is around 15% slower than the
> current impl..  IMHO the issue which this patch tries to address (in
> memory buffering of SOAP part) is not much of an issue when used with
> attachments, cause most of the time people use small soap envelopes
> when they use attachments. Also I'm not sure whether MIME4J is as
> battle tested as the Axis2's current implementation. 
> 

The real issue here has nothing to do with performance or even
unnecessary in-memory buffering. It is rather about inflexibility of the
existing MIME processing API and the hard coupling of what is meant to
be an abstract API with Attachment impl classes. Mime4j is merely an
implementation detail. 

Oleg

> 
> I totally agree that we should support MIME4J and we should do
> "improvements".. But since this does not come with any urgent fixes
> for something that's badly broken, I would prefer to do it in a little
> bit of a controlled fashion.. May be support both the impl's or do
> this in a branch first. 
> 
> 
> Also I'm sorry, but I don't really like the approach people are taking
> in this issue.. Why is it that the decision is between commit the
> patch directly to trunk  or throw away... Why cant' we come to a
> middle ground..
> 
> 
> thanks,
> Thilina
> 
> 
> 
> 
> If it breaks something (like interop) we can always revert ..
> 
> Sanjiva.
> -- 
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation;
> http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa;
> http://www.cse.mrt.ac.lk/
> 
> Blog: http://sanjiva.weerawarana.org/
> 
> 
> 
> -- 
> Thilina Gunarathne  - http://thilinag.blogspot.com


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Committing patch contributed for MIME message parser and serializer based on Apache mime4j [WSCOMMONS-387]

2008-11-20 Thread Oleg Kalnichevski

On Wed, 2008-11-19 at 21:58 -0600, Thilina Gunarathne wrote:
> Hi Asanka,
> Hope you've seen  the following thread before posting this..
> http://markmail.org/message/ayjxurjz2fow7hit
> 
> 
> 
> 
> Quoting one of Oleg's mail,
> "Presently the patch I submitted (WSCOMMONS-387) does not provide
> support for the deferred parsing, but it should be relatively trivial
> to add it."
> I'm against committing the patch unless *at least* the above is
> implemented. 
> 

Thilina,

There was no feedback on the patch so I felt it was pointless to put
more work into it. 

Anyways, I updated the patch with support for deferred parsing of MIME
streams. Folks, feel free to use this patch whichever way you please.

> 
> IIRC the consensus of that thread are as follows,
> 1. Create a new branch and complete the patch to perform what Axiom is
> capable of doing at the moment.
> 2. Put this behind an interface so that we can switch the
> implementations. 
> 
> 
> IIRC Oleg has commit rights in WS. 

I have commit rights for Synapse, but I do not recall ever being granted
WS commit rights.

Oleg


>  Hence I assume he can go ahead and start developing in a branch on
> Axiom (which at that time I thought will happen after the above mail
> thread).
> 
> 
> To be honest, I'm not fan of doing drastic changes to a working code
> base without having extensive proof (in this case a branch that works)
> that it'll work. Especially if it involves throwing away some existing
> code. 
> 
> 
> thanks,
> Thilina
> 
> On Wed, Nov 19, 2008 at 12:52 PM, Davanum Srinivas <[EMAIL PROTECTED]>
> wrote:
> Let's do #2 and everyone will be happy...
> 
> -- dims
> 
> 
> On Wed, Nov 19, 2008 at 1:48 PM, Oleg Kalnichevski
> <[EMAIL PROTECTED]> wrote:
> > On Wed, 2008-11-19 at 10:32 -0500, Davanum Srinivas wrote:
> >> Oleg,
> >>
> >> Yes, we need to do exactly what you mention first.
> >>
> >> "The whole trouble is that Axiom currently does not allow
> for multiple
> >> implementations of MIME processing as it does not have an
> abstract API
> >> for that to start with."
> >>
> >> -- dims
> >>
> >
> > Davanum,
> >
> > Frankly, I could not care less about the underlying
> implementation, as
> > long as the Axiom API enabled me (1) parse and build MIME
> messages
> > without buffering various parts in memory (2) replace
> certain bits If
> > the default implementation did not quite meet the specific
> application
> > requirements. Currently neither 1 nor 2 is the case. Hence
> my attempt at
> > fixing both issues. I chose mime4j because I thought Axiom
> project might
> > want to depend on a generic library rather than maintaining
> its own
> > implementation.
> >
> > Oleg
> >
> >
> >
> >> On Wed, Nov 19, 2008 at 10:16 AM, Oleg Kalnichevski
> <[EMAIL PROTECTED]> wrote:
> >> > On Wed, 2008-11-19 at 08:39 -0500, Davanum Srinivas
> wrote:
> >> >> Let's please keep it as a parallel optional
> implementation. just like
> >> >> we have so many components with specific interfaces and
> multiple
> >> >> implementations.
> >> >
> >> > Davanum
> >> >
> >> > The whole trouble is that Axiom currently does not allow
> for multiple
> >> > implementations of MIME processing as it does not have an
> abstract API
> >> > for that to start with.
> >> >
> >> >
> >> >>  If/when we finally see the promised results, all we
> >> >> need to do is switch the default to the other
> implementation.
> >> >>
> >> >
> >> > I am not sure I understand exactly what kind of results
> you are
> >> > referring to. The patch (1) provides an abstract API for
> MIME processing
> >> > and (2) eliminates in memory buffering of SOAP envelops.
> The Mime4j
> >> > based parser is currently ~15% slower th

Re: Committing patch contributed for MIME message parser and serializer based on Apache mime4j [WSCOMMONS-387]

2008-11-19 Thread Oleg Kalnichevski

On Wed, 2008-11-19 at 10:32 -0500, Davanum Srinivas wrote:
> Oleg,
> 
> Yes, we need to do exactly what you mention first.
> 
> "The whole trouble is that Axiom currently does not allow for multiple
> implementations of MIME processing as it does not have an abstract API
> for that to start with."
> 
> -- dims
> 

Davanum,

Frankly, I could not care less about the underlying implementation, as
long as the Axiom API enabled me (1) parse and build MIME messages
without buffering various parts in memory (2) replace certain bits If
the default implementation did not quite meet the specific application
requirements. Currently neither 1 nor 2 is the case. Hence my attempt at
fixing both issues. I chose mime4j because I thought Axiom project might
want to depend on a generic library rather than maintaining its own
implementation.

Oleg 



> On Wed, Nov 19, 2008 at 10:16 AM, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:
> > On Wed, 2008-11-19 at 08:39 -0500, Davanum Srinivas wrote:
> >> Let's please keep it as a parallel optional implementation. just like
> >> we have so many components with specific interfaces and multiple
> >> implementations.
> >
> > Davanum
> >
> > The whole trouble is that Axiom currently does not allow for multiple
> > implementations of MIME processing as it does not have an abstract API
> > for that to start with.
> >
> >
> >>  If/when we finally see the promised results, all we
> >> need to do is switch the default to the other implementation.
> >>
> >
> > I am not sure I understand exactly what kind of results you are
> > referring to. The patch (1) provides an abstract API for MIME processing
> > and (2) eliminates in memory buffering of SOAP envelops. The Mime4j
> > based parser is currently ~15% slower than the existing implementation,
> > but I _personally_ see this a reasonable trade-off for a smaller memory
> > footprint and a better API. So, I do not think I made any promises I am
> > still to deliver upon.
> >
> > Anyways, this patch is just not worth the trouble. Scrap it
> >
> > Oleg
> >
> >> thanks,
> >> dims
> >>
> >> On Wed, Nov 19, 2008 at 8:15 AM, Davanum Srinivas <[EMAIL PROTECTED]> 
> >> wrote:
> >> > I am asking for the MIME4J implementation to be an option. Not the
> >> > default. Default should be what is in right now.
> >> >
> >> > thanks,
> >> > dims
> >> >
> >> > On Wed, Nov 19, 2008 at 5:41 AM, Paul Fremantle <[EMAIL PROTECTED]> 
> >> > wrote:
> >> >>> Asankha et al
> >> >>>
> >> >>> The patch was meant as a replacement for the existing implementation. 
> >> >>> It
> >> >>> is pointless to have two MIME frameworks in Axiom. Just forget about 
> >> >>> the
> >> >>> patch.
> >> >>>
> >> >>> Oleg
> >> >>
> >> >> -1! I think we should evaluate this patch just like any other. I'm not
> >> >> clear what Dims is asking I'm afraid, but I certainly don't want to
> >> >> forget about the patch.
> >> >>
> >> >> Paul
> >> >>
> >> >> -
> >> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Davanum Srinivas :: http://davanum.wordpress.com
> >> >
> >>
> >>
> >>
> >
> >
> 
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Committing patch contributed for MIME message parser and serializer based on Apache mime4j [WSCOMMONS-387]

2008-11-19 Thread Oleg Kalnichevski

On Wed, 2008-11-19 at 08:39 -0500, Davanum Srinivas wrote:
> Let's please keep it as a parallel optional implementation. just like
> we have so many components with specific interfaces and multiple
> implementations.

Davanum

The whole trouble is that Axiom currently does not allow for multiple
implementations of MIME processing as it does not have an abstract API
for that to start with. 

>  If/when we finally see the promised results, all we
> need to do is switch the default to the other implementation.
> 

I am not sure I understand exactly what kind of results you are
referring to. The patch (1) provides an abstract API for MIME processing
and (2) eliminates in memory buffering of SOAP envelops. The Mime4j
based parser is currently ~15% slower than the existing implementation,
but I _personally_ see this a reasonable trade-off for a smaller memory
footprint and a better API. So, I do not think I made any promises I am
still to deliver upon.

Anyways, this patch is just not worth the trouble. Scrap it

Oleg

> thanks,
> dims
> 
> On Wed, Nov 19, 2008 at 8:15 AM, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
> > I am asking for the MIME4J implementation to be an option. Not the
> > default. Default should be what is in right now.
> >
> > thanks,
> > dims
> >
> > On Wed, Nov 19, 2008 at 5:41 AM, Paul Fremantle <[EMAIL PROTECTED]> wrote:
> >>> Asankha et al
> >>>
> >>> The patch was meant as a replacement for the existing implementation. It
> >>> is pointless to have two MIME frameworks in Axiom. Just forget about the
> >>> patch.
> >>>
> >>> Oleg
> >>
> >> -1! I think we should evaluate this patch just like any other. I'm not
> >> clear what Dims is asking I'm afraid, but I certainly don't want to
> >> forget about the patch.
> >>
> >> Paul
> >>
> >> -
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> >
> >
> > --
> > Davanum Srinivas :: http://davanum.wordpress.com
> >
> 
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Committing patch contributed for MIME message parser and serializer based on Apache mime4j [WSCOMMONS-387]

2008-11-19 Thread Oleg Kalnichevski

On Tue, 2008-11-18 at 22:50 -0500, Davanum Srinivas wrote:
> Asankha,
> 
> Please check in ONLY if the new MIME4J dependent code is in another
> maven module.
> 
> thanks,
> dims
> 

Asankha et al

The patch was meant as a replacement for the existing implementation. It
is pointless to have two MIME frameworks in Axiom. Just forget about the
patch.

Oleg


> On Tue, Nov 18, 2008 at 9:46 PM, Asankha C. Perera <[EMAIL PROTECTED]> wrote:
> > Hi all
> >
> > Last night I noticed that the patch contributed by Oleg for better MIME
> > parsing [1] has not yet been committed after 2 months
> >
> > The patch is still valid against the trunk, but I am not in the best
> > position to analyze it at an Axiom level, but I am very confident of its
> > benefits, and thus would like to request someone more capable to review it
> > ASAP, failing which I will commit it shortly
> >
> > thanks
> > asankha
> >
> > [1] https://issues.apache.org/jira/browse/WSCOMMONS-387
> >
> > "Mime4j can handle very complex MIME messages, is reasonably fast, and, most
> > importantly, can stream complex MIME messages in and out with a predictable
> > memory footprint (using just a small internal buffer of a constant length).
> > This patch expects to allow Axiom to provide an alternative API based on a
> > fully streamable model."
> >
> 
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Mime4j parser? was Re: svn commit: r694732

2008-09-19 Thread Oleg Kalnichevski

On Tue, 2008-09-16 at 18:33 +0530, Sanjiva Weerawarana wrote:
> Oleg, I just replied to it - please go ahead with it.
> 
> In addition, this particular fix has a better solution that allows
> general support for any media type. Keith will send a note to axis-dev
> about it and maybe we can write the new MessageBuilder using mime4j
> and see.
> 

Hi Sanjiva,

I just submitted the first patch for review

https://issues.apache.org/jira/browse/WSCOMMONS-387

Oleg

> Sanjiva.
> 
> Oleg Kalnichevski wrote: 
> > On Fri, 2008-09-12 at 19:35 +0100, Paul Fremantle wrote:
> >   
> > > Thanks for the information. I will take a look. Can you point me at
> > > the WS-Commons discussion?
> > > 
> > > Paul
> > > 
> > > 
> > 
> > Actually, there was no discussion. No one responded.  
> > 
> > http://mail-archives.apache.org/mod_mbox/ws-commons-dev/200809.mbox/%
> > [EMAIL PROTECTED]
> > 
> > Oleg
> > 
> >   
> > > On Fri, Sep 12, 2008 at 7:28 PM, Oleg Kalnichevski <[EMAIL PROTECTED]> 
> > > wrote:
> > > 
> > > > On Fri, 2008-09-12 at 16:22 +, [EMAIL PROTECTED] wrote:
> > > >   
> > > > > Author: asankha
> > > > > Date: Fri Sep 12 09:22:45 2008
> > > > > New Revision: 694732
> > > > > 
> > > > > URL: http://svn.apache.org/viewvc?rev=694732&view=rev
> > > > > Log:
> > > > > support multipart/mixed and multipart/alternative mail messages
> > > > > 
> > > > Asankha,
> > > > 
> > > > For what it is worth to you, Apache mime4j [1] can parse very complex
> > > > multipart messages very efficiently without buffering the entire content
> > > > in memory.
> > > > 
> > > > I offered the WS-Commons project to contribute SwA implementation based
> > > > on mime4j. No one seems interested, which is a shame, given the fact
> > > > Axiom could do a better at providing an efficient multipart message
> > > > parsing.
> > > > 
> > > > Oleg
> > > > 
> > > > [1] http://james.apache.org/mime4j/index.html
> > > > 
> > > > 
> > > > -
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > 
> > > > 
> > > >   
> > > 
> > > 
> > 
> > 
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> > 
> >   
> 
> -- 
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
> 
> Blog: http://sanjiva.weerawarana.org/
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED] For
> additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Mime4j parser? was Re: svn commit: r694732

2008-09-12 Thread Oleg Kalnichevski

On Fri, 2008-09-12 at 19:35 +0100, Paul Fremantle wrote:
> Thanks for the information. I will take a look. Can you point me at
> the WS-Commons discussion?
> 
> Paul
> 

Actually, there was no discussion. No one responded.  

http://mail-archives.apache.org/mod_mbox/ws-commons-dev/200809.mbox/%
[EMAIL PROTECTED]

Oleg

> On Fri, Sep 12, 2008 at 7:28 PM, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:
> > On Fri, 2008-09-12 at 16:22 +, [EMAIL PROTECTED] wrote:
> >> Author: asankha
> >> Date: Fri Sep 12 09:22:45 2008
> >> New Revision: 694732
> >>
> >> URL: http://svn.apache.org/viewvc?rev=694732&view=rev
> >> Log:
> >> support multipart/mixed and multipart/alternative mail messages
> >
> > Asankha,
> >
> > For what it is worth to you, Apache mime4j [1] can parse very complex
> > multipart messages very efficiently without buffering the entire content
> > in memory.
> >
> > I offered the WS-Commons project to contribute SwA implementation based
> > on mime4j. No one seems interested, which is a shame, given the fact
> > Axiom could do a better at providing an efficient multipart message
> > parsing.
> >
> > Oleg
> >
> > [1] http://james.apache.org/mime4j/index.html
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Mime4j parser? was Re: svn commit: r694732

2008-09-12 Thread Oleg Kalnichevski

On Fri, 2008-09-12 at 16:22 +, [EMAIL PROTECTED] wrote:
> Author: asankha
> Date: Fri Sep 12 09:22:45 2008
> New Revision: 694732
> 
> URL: http://svn.apache.org/viewvc?rev=694732&view=rev
> Log:
> support multipart/mixed and multipart/alternative mail messages

Asankha,

For what it is worth to you, Apache mime4j [1] can parse very complex
multipart messages very efficiently without buffering the entire content
in memory.

I offered the WS-Commons project to contribute SwA implementation based
on mime4j. No one seems interested, which is a shame, given the fact
Axiom could do a better at providing an efficient multipart message
parsing.

Oleg

[1] http://james.apache.org/mime4j/index.html

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Connection closes and SharedInputBuffer shutdown

2008-08-29 Thread Oleg Kalnichevski

On Fri, 2008-08-29 at 18:14 +0530, Asankha C. Perera wrote:
> Hi Oleg
> 
> I am looking at the SharedInputBuffer, for which Jason has proposed some 
> fixes (https://issues.apache.org/jira/browse/HTTPCORE-172), with which I 
> agree.
> 
> Sometime back my original fix for it, was to not shutdown the buffer, 
> while it had data which was not yet read as:
> 
> public void shutdown() {
> if (this.shutdown) {
> return;
> }
> if (!hasData() && this.endOfStream) {
> this.shutdown = true;
> synchronized (this.mutex) {
> this.mutex.notifyAll();
> }
> }
> }
> 
> However, I think Jasons version of the fix as described in the above 
> JIRA is better. Do you have any comments on these approaches?
> 

Hi Asankha,

Yes, I posted my comments to the issue report. Generally, I am fine with
the proposed changes as long as synchronization of the threading unsafe
#hasData() method is taken care of. However, I have an alternative
solution to propose which preserves the existing semantics of the
#shutdown() method and solves the problem by adding new #close() method.
Please take a look. Ideally I would like to be able to differentiate
between an abnormal shutdown and an orderly closure cases.  

> However, even after the above version of the fix, Eric reported that he 
> saw the same resultant error usually caused by this bug in his 
> production environment.
> 
> I was looking at the following code:
> 
> public int consumeContent(final ContentDecoder decoder) throws IOException {
> if (this.shutdown) {
> return -1;
> }
> 
> and wondering why you have the above if condition.. is it even remotely 
> possible for a consumeContent() call (triggered by an inputReady() to 
> come after a closed() call? If so, we may need another fix here..
> 

The initial idea was that buffers get shut down only in case of a
non-recoverable problem such as I/O failure, so their internal state
were no longer consistent / valid. If we change the semantics of the
#shutdown() method we may also need to change the above behavior.  

Cheers

Oleg

> thanks
> asankha
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Comet support on our NIO HTTP?

2008-07-21 Thread Oleg Kalnichevski

On Mon, 2008-07-21 at 13:35 +0100, Paul Fremantle wrote:
> Maybe it isn't different. I'm not an expert on the HTTP transport.
> 
> In general, a keep-alive is transparent to the Synapse message flow -
> it is effectively managed by the client and each request-response pair
> is logically separate. A comet connection logically supports both in
> and out messages in any order and something needs to indicate to the
> transport which existing connection this message is going to. For
> example, suppose you have 50 incoming connections, each of which is
> looking for different stock quotes based on a filter, something needs
> to decide which connections to send the MSFT quote down when it comes
> in. I guess logically speaking, we need a unique to-address for each
> open connection so that it can be addressed by a message.
> 
> Paul
> 

Paul et al

I have not studied Comet in details but it seems all it takes a stateful
connection manager. We already have one for HttpClient 4.0 but it is
based on classic (blocking) I/O. There are plans to start working on a
NIO connection manager at some point of time.

Oleg


> On Mon, Jul 21, 2008 at 1:24 PM, Sanjiva Weerawarana
> <[EMAIL PROTECTED]> wrote:
> > On the server-side, why is Comet different from a keep-alive connection
> > where we have to process multiple independent requests on the same socket
> > connection?
> >
> > Sanjiva.
> >
> > Paul Fremantle wrote:
> >>
> >> Folks
> >>
> >> One of the things I am increasingly interested in is events and EDA,
> >> and while Synapse already supports Atom, JMS, XMPP (tho not XMPP
> >> pub/sub AFAIK), I think it might be interesting to think how you would
> >> implement a Comet model
> >> http://en.wikipedia.org/wiki/Comet_(programming) with Synapse.
> >>
> >> It seems to me that our NIO HTTP model is very suited in one way
> >> (async), but I guess we'd probably need to do a lot of work to support
> >> handling more than one message per connection because its not clear to
> >> me how you would associate the messages with the connection.
> >>
> >> Thoughts?
> >>
> >> Paul
> >>
> >>
> >
> > --
> > Sanjiva Weerawarana, Ph.D.
> > Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> > Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> > Member; Apache Software Foundation; http://www.apache.org/
> > Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
> >
> > Blog: http://sanjiva.weerawarana.org/
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Understanding asynchrounous request processing in Apache Synapse/Axis2/Http Core NIO

2008-07-20 Thread Oleg Kalnichevski

On Sun, 2008-07-20 at 16:39 +0200, Hubert, Eric wrote:
> Hi devs,
> 
> we are facing an issue in Apache Synapse where HttpClientWorkers are in
> the process of writing a response back to the client using
> HttpCoreNIOSender.sendAsyncResponse(), but are then waiting at
> org.apache.http.nio.util.SharedOutputBuffer.flushContent() to get
> notified by someone...
> 
> I'd like to take this issue as a start to gather more knowledge about
> the internal working of Apache Synapse and http core nio in general.
> Could someone please point me to some documentation, which describes,
> how the request/response processing is working. 

Eric,

I am very sorry but we currently have almost nothing in terms of
documentation for HttpCore. I am planning to start working on an
HttpCore tutorial in August. 

Asankha knows best about the Synapse NIO transport. I'll happily chip
in information about HttpCore internal stuff

...

> The response is processed by the ClientWorker who delegates the response
> processing to Axis2 (again the blackbox of AxisEngine.receive,
> AxisEngine.send) and then the response shall be send back to the client
> over the MessageFormatter which again uses some NIO buffer. Here we have
> the trouble that the code in
> org.apache.http.nio.util.SharedOutputBuffer.flushContent() is waiting
> for some notification. Who is responsible for that notification? 

It expects a notification from the I/O reactor it is ready to accept
more output.  


> The
> HttpCoreNIOSender.reactor? I couldn't find any useful API-doc on this.
> I'm also looking for some httpcore-nio-4.0-beta1-sources.jar from any
> Maven Repo to attach to my synapse-IDE project.
> 
> Does anybody know something about possible causes for not getting such a
> notification?
> 

The most likely explanation the output notifications have been suspended
by the protocol handler (Synapse it this case). Apparently Synapse
thinks it is not meant to be producing any output at this point)

> I would be very helpful for any help and pointers to more documentation
> to understand more about the nio stuff.
> 
> Ah, and who creates the I/O Dispatcher? 

Listening or connection I/O reactors

> Are this the IOReactors?

Yes, it is

>  And are
> the I/O Dispatcher again IOReactors?
> 

Yes, they are

Can you reproduce the problem with a test case?

Oleg


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (SYNAPSE-396) Consider reducing requisite dependencies of Synapse Core

2008-07-14 Thread Oleg Kalnichevski (JIRA)


[ 
https://issues.apache.org/jira/browse/SYNAPSE-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12613267#action_12613267
 ] 

Oleg Kalnichevski commented on SYNAPSE-396:
---

Ruwan,

The OSGi model does help alleviate the issue but it does not solve it 
completely. Besides there will still be cases when Synapse core may need to be 
embedded into runtime environments that are not OSGi enabled.

Anyways, decoupling transports from the core would improve the situation 
greatly.

Oleg

> Consider reducing requisite dependencies of Synapse Core
> 
>
> Key: SYNAPSE-396
> URL: https://issues.apache.org/jira/browse/SYNAPSE-396
> Project: Synapse
>  Issue Type: Wish
>  Components: Core
>Affects Versions: 1.3
>    Reporter: Oleg Kalnichevski
>
> Folks
> I understand that the greatest majority of Synapse users use it as a 
> standalone application and are unlikely  to care much about external 
> dependencies of individual modules. However, as the Synapse user base grows 
> it will become more diverse as well. There will be users who may want to (or 
> have to) use parts of Synapse embedded into a larger runtime either as OSGi 
> bundles, GBeans or a set of plain old jars. They are also likely to concerned 
> about total number of external dependencies in order to minimize possibility 
> of versioning conflicts. 
> The present situation with external dependencies can only be described as 
> depressing. Synapse Core is currently dependent either directly or 
> transitively on several dozens of libraries, which makes it very difficult to 
> embed. 
> More details to follow

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (SYNAPSE-396) Consider reducing requisite dependencies of Synapse Core

2008-07-11 Thread Oleg Kalnichevski (JIRA)


[ 
https://issues.apache.org/jira/browse/SYNAPSE-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612868#action_12612868
 ] 

Oleg Kalnichevski commented on SYNAPSE-396:
---

Below is the present list of dependencies for Synapse Core.

(1) Why on earth does Synapse Core need to be directly dependent Spring? I am a 
major fan of Spring framework, but does it make any sense to have a hard 
dependency on a complex DI framework because of just two utility classes?

(2) Does Synapse Core really need to be directly dependent on Log4j? Yes, it is 
a great toolkit, but many managed runtimes come with different logging 
toolkits. Having Log4j on the classpath, for instance, will certainly impact 
the default behaviour of Commons Logging. It is really desired?

(3) Most importantly, does Core really need to be dependent on ALL transports 
including fairly exotic ones? Should Core be dependent on specific transport 
implementation(s) at all. I personally think not.

Please do consider reducing requisite dependencies of Synapse Core in order to 
facilitate its re-usability and embeddability.

Besides, there are enough companies paranoid to such an extent that they impose 
a policy of requiring an explicit approval of each individual external 
dependency for mission critical systems. Coincidentally, those companies are 
usually quite good to have as paying customers.

Oleg



[INFO] [dependency:resolve]
[INFO]
[INFO] The following files have been resolved:
[INFO]JLex:JLex:jar:0.0
[INFO]annogen:annogen:jar:0.1.0
[INFO]axis:axis-ant:jar:1.4
[INFO]backport-util-concurrent:backport-util-concurrent:jar:3.1
[INFO]bouncycastle:bcprov-jdk15:jar:132
[INFO]com.jcraft:jsch:jar:0.1.31
[INFO]commons-cli:commons-cli:jar:1.0
[INFO]commons-codec:commons-codec:jar:1.3
[INFO]commons-collections:commons-collections:jar:3.1
[INFO]commons-dbcp:commons-dbcp:jar:1.2.2
[INFO]commons-discovery:commons-discovery:jar:0.2
[INFO]commons-fileupload:commons-fileupload:jar:1.2
[INFO]commons-httpclient:commons-httpclient:jar:3.1
[INFO]commons-io:commons-io:jar:1.4
[INFO]commons-lang:commons-lang:jar:2.3
[INFO]commons-logging:commons-logging:jar:1.1
[INFO]commons-net:commons-net:jar:1.4.1
[INFO]commons-pool:commons-pool:jar:1.3
[INFO]de.schlichtherle.io:truezip:jar:6.6
[INFO]groovy:groovy-all:jar:1.0
[INFO]jakarta-regexp:jakarta-regexp:jar:1.4
[INFO]java-cup:java-cup:jar:0.0
[INFO]javax.activation:activation:jar:1.1
[INFO]javax.mail:mail:jar:1.4
[INFO]javax.servlet:servlet-api:jar:2.3
[INFO]jaxen:jaxen:jar:1.1.1
[INFO]junit:junit:jar:3.8.2
[INFO]log4j:log4j:jar:1.2.13
[INFO]net.sf.saxon:saxon:jar:8.9
[INFO]net.sf.saxon:saxon-dom:jar:8.9
[INFO]net.sf.saxon:saxon-xqj:jar:8.9
[INFO]opensaml:opensaml:jar:1.1
[INFO]org.apache.ant:ant:jar:1.7.0
[INFO]org.apache.ant:ant-launcher:jar:1.7.0
[INFO]org.apache.ant:ant-nodeps:jar:1.7.0
[INFO]org.apache.axis2:addressing:mar:20080625.173656-377
[INFO]org.apache.axis2:axis2-adb:jar:20080625.173656-380
[INFO]org.apache.axis2:axis2-adb-codegen:jar:20080625.173656-380
[INFO]org.apache.axis2:axis2-clustering:jar:20080612.231257-317
[INFO]org.apache.axis2:axis2-codegen:jar:20080625.173656-380
[INFO]org.apache.axis2:axis2-java2wsdl:jar:20080625.173656-378
[INFO]org.apache.axis2:axis2-kernel:jar:20080625.173656-381
[INFO]org.apache.axis2:axis2-mtompolicy:jar:20080612.231257-318
[INFO]org.apache.axis2:axis2-saaj:jar:20080625.173656-374
[INFO]org.apache.axis2:axis2-transports:jar:20080625.173656-5
[INFO]org.apache.axis2:axis2-xmlbeans:jar:20080612.231257-317
[INFO]org.apache.axis2:mex:jar:impl:20080612.231257-253
[INFO]org.apache.bcel:bcel:jar:5.2
[INFO]org.apache.bsf:bsf-all:jar:3.0-beta2
[INFO]org.apache.commons:commons-vfs:jar:1.1-587797
[INFO]org.apache.derby:derby:jar:10.1.1.0
[INFO]org.apache.geronimo.specs:geronimo-jms_1.1_spec:jar:1.1
[INFO]org.apache.geronimo.specs:geronimo-saaj_1.3_spec:jar:1.0.0
[INFO]org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1
[INFO]org.apache.geronimo.specs:geronimo-ws-metadata_2.0_spec:jar:1.1.2
[INFO]org.apache.httpcomponents:httpcore:jar:4.0-beta1
[INFO]org.apache.httpcomponents:httpcore-nio:jar:4.0-beta1
[INFO]org.apache.mina:mina-core:jar:1.1.0
[INFO]org.apache.mina:mina-filter-ssl:jar:1.0.0
[INFO]org.apache.neethi:neethi:jar:2.0.4
[INFO]org.apache.qpid:qpid-client:jar:1.0-incubating-M3-615355
[INFO]org.apache.qpid:qpid-common:jar:1.0-incubating-M3-615355
[INFO]org.apache.rampart:rampart:mar:20080424.184741-413
[INFO]org.apache.rampart:rampart-core:jar:20080424.184741-457
[INFO]org.apache.rampart:rampart-policy:jar:20080424.184741-467
[INFO]org.apache.rampart:rampart-trust:jar:20080424.184741-460
[

[jira] Created: (SYNAPSE-396) Consider reducing requisite dependencies of Synapse Core

2008-07-11 Thread Oleg Kalnichevski (JIRA)

Consider reducing requisite dependencies of Synapse Core


 Key: SYNAPSE-396
 URL: https://issues.apache.org/jira/browse/SYNAPSE-396
 Project: Synapse
  Issue Type: Wish
  Components: Core
Affects Versions: 1.3
Reporter: Oleg Kalnichevski


Folks

I understand that the greatest majority of Synapse users use it as a standalone 
application and are unlikely  to care much about external dependencies of 
individual modules. However, as the Synapse user base grows it will become more 
diverse as well. There will be users who may want to (or have to) use parts of 
Synapse embedded into a larger runtime either as OSGi bundles, GBeans or a set 
of plain old jars. They are also likely to concerned about total number of 
external dependencies in order to minimize possibility of versioning conflicts. 

The present situation with external dependencies can only be described as 
depressing. Synapse Core is currently dependent either directly or transitively 
on several dozens of libraries, which makes it very difficult to embed. 

More details to follow

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Possible Causes for "Connection reset by peer" when using NIO

2008-06-25 Thread Oleg Kalnichevski

On Wed, 2008-06-25 at 18:13 +0200, Hubert, Eric wrote:
> Hi devs!
> 
> first of all I'd like to apologize for posting a "user-problem" to two 
> dev-lists. I only did this as have not much background knowledge of the NIO 
> implementation and think a solid understanding of NIO is necessary to help 
> tackling our problem.
> 
> We are using the WSO2 ESB which is based on Apache Synapse, Apache Axis2 and 
> the HTTP Core NIO module. As the stacktrace only contains http-nio details, I 
> cc'ed the http components dev list. Hopefully someone can help out.
> 
> When sending about 3000 Hessian-requests per hour from clients (Tomcat) over 
> the ESB (Synapse 1.2 running on JDK 1.5.15, Linux 2.6.23.1-amd64-75) to a Bea 
> Weblogic 8.1 we see about 1 to 10 exceptions of type "java.io.IOException: 
> Connection reset by peer" in the ESB-log. 
> 
> If I understand it right the ESB then executes a failover to the next service 
> node as we are using a load balancing group. So the client is not affected, 
> but the endpoint with the failure will be marked as inactive.
> 
> The problem is I don't understand the cause of this exception. It occurs 
> during the read on a Socket-Channel. So I think the server might close the 
> connection while the ESB is reading. But maybe internally some kind of pool 
> is used and a connection can change to some abnormal state?

Unlikely. This kind of I/O exception occurs when the connection is
closed by the _remote_ side.   

> 
> We have seen such Exceptions before when we were using HTTP 1.1 in 
> combination with the Bea Weblogic server. Very likely an issue with HTTP 
> keepalive (persistent connections). So for any connection to a Bea service we 
> use the property mediator of Synapse to change the connection ESB <-> Bea to 
> use HTTP 1.0:
> 
> 

Connection reset by peer I/O exceptions are perfectly normal with
persistent HTTP connections. The most likely cause of it is that the
connection was closed on the server side due to the timeout (maximum
period of inactivity) about the same moment the client started sending
data to the server. Situations like that can happen.

> Since then we hadn't seen this exception again. But now switching to another 
> environment we see this exception again, but only for Hessian services.
> I have no clue what else could cause this exception. How can we detect the 
> cause? How to narrow down possible causes, if there are different 
> possibilities. I don't expect any network outages to be the reason, as other 
> services (SOAP)-based are working pretty well.
> 

I do not know Hessian well enough protocol to comment on it .

Hope this helps

Oleg

> The exact exception we are getting is:
> 
> java.io.IOException: Connection reset by peer
> at sun.nio.ch.FileDispatcher.read0(Native Method)
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:21)
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:233)
> at sun.nio.ch.IOUtil.read(IOUtil.java:206)
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:207)
> at 
> org.apache.http.impl.nio.reactor.SessionInputBufferImpl.fill(SessionInputBufferImpl.java:85)
> at 
> org.apache.http.impl.nio.codecs.AbstractMessageParser.fillBuffer(AbstractMessageParser.java:97)
> at 
> org.apache.http.impl.nio.DefaultNHttpClientConnection.consumeInput(DefaultNHttpClientConnection.java:113)
> at 
> org.apache.http.impl.nio.DefaultClientIOEventDispatch.inputReady(DefaultClientIOEventDispatch.java:99)
> at 
> org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:98)
> at 
> org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:195)
> at 
> org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:180)
> at 
> org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:142)
> at 
> org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:70)
> at 
> org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:318)
>  
> 
> 
> This exception occurs consistently a few time per hour on every possible 
> combination of client node, esb node and service endpoint node.
> 
> Any pointer or idea is greatly appreciated. Thanks a lot in advance!
> 
> 
> Regards,
>Eric
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (SYNAPSE-349) Transport base package is dependent on transport specific (VFS and Mail) classes

2008-06-10 Thread Oleg Kalnichevski (JIRA)


[ 
https://issues.apache.org/jira/browse/SYNAPSE-349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603964#action_12603964
 ] 

Oleg Kalnichevski commented on SYNAPSE-349:
---

Patch checked in.

Oleg

> Transport base package is dependent on transport specific (VFS and Mail) 
> classes
> 
>
> Key: SYNAPSE-349
> URL: https://issues.apache.org/jira/browse/SYNAPSE-349
> Project: Synapse
>  Issue Type: Improvement
>  Components: Transports
>Affects Versions: 1.2
>    Reporter: Oleg Kalnichevski
>Priority: Minor
> Fix For: 1.3
>
> Attachments: basetransport.patch
>
>
> The base transport package of Synapse is dependent on VFS and Mail specific 
> classes, which seems wrong to me. Ideally the base transport classes should 
> not depend on any transport specific aspects. 
> Patch to follow shortly.
> Oleg

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (SYNAPSE-353) Is dependency on Commons Lang justified?

2008-06-10 Thread Oleg Kalnichevski (JIRA)


 [ 
https://issues.apache.org/jira/browse/SYNAPSE-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski resolved SYNAPSE-353.
---

   Resolution: Fixed
Fix Version/s: 1.3

Fixed in SVN trunk.

Oleg

> Is dependency on Commons Lang justified?
> 
>
> Key: SYNAPSE-353
> URL: https://issues.apache.org/jira/browse/SYNAPSE-353
> Project: Synapse
>  Issue Type: Wish
>  Components: Transports
>Affects Versions: 1.2
>    Reporter: Oleg Kalnichevski
>Priority: Minor
> Fix For: 1.3
>
>
> Currently Synapse Transport uses only two methods from Commons Lang: 
> StringUtils#leftPad and StringUtils#isNotBlank. I am not sure the benefits of 
> reusing those two methods really justifies having an extra external 
> dependency. Please consider decoupling Synapse Transports from Commons Lang.
> Oleg

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (SYNAPSE-349) Transport base package is dependent on transport specific (VFS and Mail) classes


[ 
https://issues.apache.org/jira/browse/SYNAPSE-349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603629#action_12603629
 ] 

Oleg Kalnichevski commented on SYNAPSE-349:
---

Andreas,

It is not about particular methods but rather about recursive dependencies 
between base transport package and individual transport packages. The proposed 
patch decouples the base package from VFS specific dependencies as the first 
step. We can deal with the dependency on javax.mail.internet later on .

Oleg

> Transport base package is dependent on transport specific (VFS and Mail) 
> classes
> 
>
> Key: SYNAPSE-349
> URL: https://issues.apache.org/jira/browse/SYNAPSE-349
> Project: Synapse
>  Issue Type: Improvement
>  Components: Transports
>Affects Versions: 1.2
>    Reporter: Oleg Kalnichevski
>Priority: Minor
> Fix For: 1.3
>
> Attachments: basetransport.patch
>
>
> The base transport package of Synapse is dependent on VFS and Mail specific 
> classes, which seems wrong to me. Ideally the base transport classes should 
> not depend on any transport specific aspects. 
> Patch to follow shortly.
> Oleg

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: QPid libraries

On Mon, 2008-06-09 at 22:24 +0530, Ruwan Linton wrote:
> Hi Oleg,
> 
> They should be available on the WSO2 repository
> [http://dist.wso2.org/maven2]. This is not a released version and
> Rajith did these changes depending on a svn revision build, which has
> been uploaded to the WSO2 repository to overcome the issue that you
> have faced.
> 
> BTW: I guess Synapse contains the WSO2 repository? Have you removed it
> from the pom.xml?
> 

No, absolutely not. 

The thing is it looks like those snapshots are not in the WSO2
repository. See the snippet below:

GroupId: org.apache.qpid
ArtifactId: qpid
Version: 1.0-incubating-M3-SNAPSHOT

Reason: Unable to download the artifact from any repository

  org.apache.qpid:qpid:pom:1.0-incubating-M3-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  wso2-m2 (http://dist.wso2.org/maven2/),
  apache.snapshots
(http://people.apache.org/repo/m2-snapshot-repository),
  apache-snapshots
(http://people.apache.org/repo/m2-snapshot-repository/)

Oleg


> Thanks,
> Ruwan
> 
> On Mon, Jun 9, 2008 at 10:19 PM, Oleg Kalnichevski <[EMAIL PROTECTED]>
> wrote:
> I am currently unable to build Synapse due to the missing Qpid
> libraries
> 
> GroupId: org.apache.qpid
> ArtifactId: qpid
> Version: 1.0-incubating-M3-SNAPSHOT
> 
> Reason: Unable to download the artifact from any repository
> 
>  org.apache.qpid:qpid:pom:1.0-incubating-M3-SNAPSHOT
> 
> from the specified remote repositories:
>  central (http://repo1.maven.org/maven2),
>  wso2-m2 (http://dist.wso2.org/maven2/),
>  apache.snapshots
> (http://people.apache.org/repo/m2-snapshot-repository),
>  apache-snapshots
> (http://people.apache.org/repo/m2-snapshot-repository/)
> 
> Which repository are they supposed to get picked from?
> 
> Oleg
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 
> 
> -- 
> Ruwan Linton
> http://www.wso2.org - "Oxygenating the Web Services Platform"


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

QPid libraries

I am currently unable to build Synapse due to the missing Qpid
libraries 

GroupId: org.apache.qpid
ArtifactId: qpid
Version: 1.0-incubating-M3-SNAPSHOT

Reason: Unable to download the artifact from any repository

  org.apache.qpid:qpid:pom:1.0-incubating-M3-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  wso2-m2 (http://dist.wso2.org/maven2/),
  apache.snapshots
(http://people.apache.org/repo/m2-snapshot-repository),
  apache-snapshots
(http://people.apache.org/repo/m2-snapshot-repository/)

Which repository are they supposed to get picked from?

Oleg


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Direct dependency on backport-util-concurrent

Folks,

Is there any particular reason Synapse Transports still have a direct
dependency on backport-util-concurrent? This strikes me as odd.

Oleg 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Tabs or spaces?

Folks,

What are the code formatting preferences for Synapse? At least are we
meant to use tabs or spaces for indentation?

Oleg



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (SYNAPSE-353) Is dependency on Commons Lang justified?


[ 
https://issues.apache.org/jira/browse/SYNAPSE-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603596#action_12603596
 ] 

Oleg Kalnichevski commented on SYNAPSE-353:
---

Moreover, I do not even see Commons Lang declared as one of the Synapse 
dependencies

Oleg

> Is dependency on Commons Lang justified?
> 
>
> Key: SYNAPSE-353
> URL: https://issues.apache.org/jira/browse/SYNAPSE-353
> Project: Synapse
>  Issue Type: Wish
>  Components: Transports
>Affects Versions: 1.2
>    Reporter: Oleg Kalnichevski
>Priority: Minor
>
> Currently Synapse Transport uses only two methods from Commons Lang: 
> StringUtils#leftPad and StringUtils#isNotBlank. I am not sure the benefits of 
> reusing those two methods really justifies having an extra external 
> dependency. Please consider decoupling Synapse Transports from Commons Lang.
> Oleg

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (SYNAPSE-353) Is dependency on Commons Lang justified?


 [ 
https://issues.apache.org/jira/browse/SYNAPSE-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated SYNAPSE-353:
--

Summary: Is dependency on Commons Lang justified?  (was: Is dependency on 
Commons Lang is justified?)

> Is dependency on Commons Lang justified?
> 
>
> Key: SYNAPSE-353
> URL: https://issues.apache.org/jira/browse/SYNAPSE-353
> Project: Synapse
>  Issue Type: Wish
>  Components: Transports
>Affects Versions: 1.2
>    Reporter: Oleg Kalnichevski
>Priority: Minor
>
> Currently Synapse Transport uses only two methods from Commons Lang: 
> StringUtils#leftPad and StringUtils#isNotBlank. I am not sure the benefits of 
> reusing those two methods really justifies having an extra external 
> dependency. Please consider decoupling Synapse Transports from Commons Lang.
> Oleg

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (SYNAPSE-353) Is dependency on Commons Lang is justified?

Is dependency on Commons Lang is justified?
---

 Key: SYNAPSE-353
 URL: https://issues.apache.org/jira/browse/SYNAPSE-353
 Project: Synapse
  Issue Type: Wish
  Components: Transports
Affects Versions: 1.2
Reporter: Oleg Kalnichevski
Priority: Minor


Currently Synapse Transport uses only two methods from Commons Lang: 
StringUtils#leftPad and StringUtils#isNotBlank. I am not sure the benefits of 
reusing those two methods really justifies having an extra external dependency. 
Please consider decoupling Synapse Transports from Commons Lang.

Oleg

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (SYNAPSE-349) Transport base package is dependent on transport specific (VFS and Mail) classes


 [ 
https://issues.apache.org/jira/browse/SYNAPSE-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated SYNAPSE-349:
--

Attachment: (was: basetransport.patch)

> Transport base package is dependent on transport specific (VFS and Mail) 
> classes
> 
>
> Key: SYNAPSE-349
> URL: https://issues.apache.org/jira/browse/SYNAPSE-349
> Project: Synapse
>  Issue Type: Improvement
>  Components: Transports
>Affects Versions: 1.2
>    Reporter: Oleg Kalnichevski
>Priority: Minor
> Fix For: 1.3
>
> Attachments: basetransport.patch
>
>
> The base transport package of Synapse is dependent on VFS and Mail specific 
> classes, which seems wrong to me. Ideally the base transport classes should 
> not depend on any transport specific aspects. 
> Patch to follow shortly.
> Oleg

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (SYNAPSE-349) Transport base package is dependent on transport specific (VFS and Mail) classes


 [ 
https://issues.apache.org/jira/browse/SYNAPSE-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated SYNAPSE-349:
--

Attachment: basetransport.patch

All right. Can we tackle this issue with a series of small, incremental changes 
then? Can we decouple base transport package from VFS for  a start?

Oleg

> Transport base package is dependent on transport specific (VFS and Mail) 
> classes
> 
>
> Key: SYNAPSE-349
> URL: https://issues.apache.org/jira/browse/SYNAPSE-349
> Project: Synapse
>  Issue Type: Improvement
>  Components: Transports
>Affects Versions: 1.2
>    Reporter: Oleg Kalnichevski
>Priority: Minor
> Fix For: 1.3
>
> Attachments: basetransport.patch
>
>
> The base transport package of Synapse is dependent on VFS and Mail specific 
> classes, which seems wrong to me. Ideally the base transport classes should 
> not depend on any transport specific aspects. 
> Patch to follow shortly.
> Oleg

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (SYNAPSE-349) Transport base package is dependent on transport specific (VFS and Mail) classes


[ 
https://issues.apache.org/jira/browse/SYNAPSE-349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603183#action_12603183
 ] 

Oleg Kalnichevski commented on SYNAPSE-349:
---

> It is the fact that it introduces a dependency on javax.mail.internet, right? 

Yes, it is. Ideally base transport package should not have dependencies on any 
specific transport interfaces or classes

Oleg

> Transport base package is dependent on transport specific (VFS and Mail) 
> classes
> 
>
> Key: SYNAPSE-349
> URL: https://issues.apache.org/jira/browse/SYNAPSE-349
> Project: Synapse
>  Issue Type: Improvement
>  Components: Transports
>Affects Versions: 1.2
>Reporter: Oleg Kalnichevski
>Priority: Minor
> Fix For: 1.3
>
> Attachments: basetransport.patch
>
>
> The base transport package of Synapse is dependent on VFS and Mail specific 
> classes, which seems wrong to me. Ideally the base transport classes should 
> not depend on any transport specific aspects. 
> Patch to follow shortly.
> Oleg

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (SYNAPSE-349) Transport base package is dependent on transport specific (VFS and Mail) classes


[ 
https://issues.apache.org/jira/browse/SYNAPSE-349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603137#action_12603137
 ] 

Oleg Kalnichevski commented on SYNAPSE-349:
---

Andreas,

Is there a test case for that issue? All tests seem to pass for me. Anyways, 
recursive dependencies between base package and concrete protocol 
implementations strike me as odd.

Oleg   

> Transport base package is dependent on transport specific (VFS and Mail) 
> classes
> 
>
> Key: SYNAPSE-349
> URL: https://issues.apache.org/jira/browse/SYNAPSE-349
> Project: Synapse
>  Issue Type: Improvement
>  Components: Transports
>Affects Versions: 1.2
>    Reporter: Oleg Kalnichevski
>Priority: Minor
> Fix For: 1.3
>
> Attachments: basetransport.patch
>
>
> The base transport package of Synapse is dependent on VFS and Mail specific 
> classes, which seems wrong to me. Ideally the base transport classes should 
> not depend on any transport specific aspects. 
> Patch to follow shortly.
> Oleg

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (SYNAPSE-349) Transport base package is dependent on transport specific (VFS and Mail) classes


 [ 
https://issues.apache.org/jira/browse/SYNAPSE-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated SYNAPSE-349:
--

Attachment: basetransport.patch

Please review.

Oleg

> Transport base package is dependent on transport specific (VFS and Mail) 
> classes
> 
>
> Key: SYNAPSE-349
> URL: https://issues.apache.org/jira/browse/SYNAPSE-349
> Project: Synapse
>  Issue Type: Improvement
>  Components: Transports
>Affects Versions: 1.2
>    Reporter: Oleg Kalnichevski
>Priority: Minor
> Fix For: 1.3
>
> Attachments: basetransport.patch
>
>
> The base transport package of Synapse is dependent on VFS and Mail specific 
> classes, which seems wrong to me. Ideally the base transport classes should 
> not depend on any transport specific aspects. 
> Patch to follow shortly.
> Oleg

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (SYNAPSE-349) Transport base package is dependent on transport specific (VFS and Mail) classes