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

[Hubert, Eric]

Asankha, I think found the related issue: 
https://issues.apache.org/jira/browse/SYNAPSE-600

According to your comment the fix has only been applied to the 1.3 branch. Is 
there any reason to not (yet) apply this change to the trunk?

From: Hubert, Eric [mailto:eric.hub...@foxmobile.com]
Sent: Monday, December 07, 2009 7:44 AM
To: dev@synapse.apache.org
Subject: RE: Advice on choosing http core NIO version for Synapse 1.2

Hi Oleg, Eric

Me neither, but from what I've seen, in HttpCoreNIOSender Synapse logs the 
thrown IOReactorException including the cause information as early as it has a 
chance to do so:


Eric - you are looking at a previous version of the code, when we enabled 
auto-restart on unexpected shutdown, we improved this logic. However the real 
cause is the ClosedChannelException issue. We can neatly log fatal causes when 
such a restart is performed, so that we will know in future, what caused such a 
filure
Asankha, I actually was also a bit confused as I expected to find the code 
which attempts the restart. But if I’m not wrong I was really looking at trunk. 
Is it possible, that the change has only been applied to the Synapse 1.3 branch 
and not yet forward ported to the trunk?


Lets work on getting this fix into HttpComponents, probably as you switch to 
the new HttpCore version, since this is a quite common scenario you encounter 
in your deployment
Which fix are you referring to regarding HttpCompoents? Do you mean the one 
regarding the ClosedChannelException? This one has already been fixed for 
beta-3 and will be fine in 4.0.1. What other fix do you see which can be 
applied to HttpComponents directly? Sorry, maybe I’m a bit to tired this 
morning…


Thanks,
   Eric

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

[Hubert, Eric]

Hi Oleg, Eric

Me neither, but from what I've seen, in HttpCoreNIOSender Synapse logs the 
thrown IOReactorException including the cause information as early as it has a 
chance to do so:


Eric - you are looking at a previous version of the code, when we enabled 
auto-restart on unexpected shutdown, we improved this logic. However the real 
cause is the ClosedChannelException issue. We can neatly log fatal causes when 
such a restart is performed, so that we will know in future, what caused such a 
filure

Asankha, I actually was also a bit confused as I expected to find the code 
which attempts the restart. But if I’m not wrong I was really looking at trunk. 
Is it possible, that the change has only been applied to the Synapse 1.3 branch 
and not yet forward ported to the trunk?


Lets work on getting this fix into HttpComponents, probably as you switch to 
the new HttpCore version, since this is a quite common scenario you encounter 
in your deployment

Which fix are you referring to regarding HttpCompoents? Do you mean the one 
regarding the ClosedChannelException? This one has already been fixed for 
beta-3 and will be fine in 4.0.1. What other fix do you see which can be 
applied to HttpComponents directly? Sorry, maybe I’m a bit to tired this 
morning…


Thanks,
   Eric

RE: JMX notifications for Endpoint state changes

[Hubert, Eric]

Eric, the issue in the synapse configuration language is that you do not have a 
section which declares the sequences to do this, sequences, endpoints, proxies 
and all local entries are on the same XML depth and there is no chance to 
specify this configuraiton as you explained. If we had a  tag 
enclosing all the sequence definitions, this would have been the ideal 
approach, but it is not the case :-(

My bad - you are right. Sequences can also be defined in different places, 
including inline in proxies etc. I should have looked at the actual 
configuration - it looked different in my memories. ;-)

Build failed in Hudson: Synapse - 1.3 - SNAPSHOT #96

[Apache Hudson Server]

See 


--
[...truncated 48 lines...]
[INFO] Using default encoding to copy filtered resources.
[INFO] snapshot org.apache.sandesha2:sandesha2-core:SNAPSHOT: checking for 
updates from apache-snapshots
[INFO] snapshot org.apache.sandesha2:sandesha2-core:SNAPSHOT: checking for 
updates from wso2-m2
2K downloaded
[INFO] snapshot org.apache.sandesha2:sandesha2-parent:SNAPSHOT: checking for 
updates from apache-snapshots
[INFO] snapshot org.apache.sandesha2:sandesha2-parent:SNAPSHOT: checking for 
updates from wso2-m2
11K downloaded
[INFO] snapshot org.apache.axis2:addressing:SNAPSHOT: checking for updates from 
apache-snapshots
[INFO] snapshot org.apache.axis2:addressing:SNAPSHOT: checking for updates from 
wso2-m2
Downloading: 
http://repository.apache.org/snapshots/java-cup/java-cup/0.0/java-cup-0.0.pom
Downloading: http://dist.wso2.org/maven2//java-cup/java-cup/0.0/java-cup-0.0.pom
Downloading: 
http://people.apache.org/~asankha/repository/java-cup/java-cup/0.0/java-cup-0.0.pom
Downloading: 
http://repo1.maven.org/maven2/java-cup/java-cup/0.0/java-cup-0.0.pom
Downloading: http://repository.apache.org/snapshots/JLex/JLex/0.0/JLex-0.0.pom
Downloading: http://dist.wso2.org/maven2//JLex/JLex/0.0/JLex-0.0.pom
Downloading: 
http://people.apache.org/~asankha/repository/JLex/JLex/0.0/JLex-0.0.pom
Downloading: http://repo1.maven.org/maven2/JLex/JLex/0.0/JLex-0.0.pom
Downloading: 
http://repository.apache.org/snapshots/net/sf/saxon/saxon/8.9/saxon-8.9.pom
Downloading: http://dist.wso2.org/maven2//net/sf/saxon/saxon/8.9/saxon-8.9.pom
Downloading: 
http://people.apache.org/~asankha/repository/net/sf/saxon/saxon/8.9/saxon-8.9.pom
Downloading: http://repo1.maven.org/maven2/net/sf/saxon/saxon/8.9/saxon-8.9.pom
Downloading: 
http://repository.apache.org/snapshots/net/sf/saxon/saxon-dom/8.9/saxon-dom-8.9.pom
Downloading: 
http://dist.wso2.org/maven2//net/sf/saxon/saxon-dom/8.9/saxon-dom-8.9.pom
Downloading: 
http://people.apache.org/~asankha/repository/net/sf/saxon/saxon-dom/8.9/saxon-dom-8.9.pom
Downloading: 
http://repo1.maven.org/maven2/net/sf/saxon/saxon-dom/8.9/saxon-dom-8.9.pom
Downloading: 
http://repository.apache.org/snapshots/net/sf/saxon/saxon-xqj/8.9/saxon-xqj-8.9.pom
Downloading: 
http://dist.wso2.org/maven2//net/sf/saxon/saxon-xqj/8.9/saxon-xqj-8.9.pom
Downloading: 
http://people.apache.org/~asankha/repository/net/sf/saxon/saxon-xqj/8.9/saxon-xqj-8.9.pom
Downloading: 
http://repo1.maven.org/maven2/net/sf/saxon/saxon-xqj/8.9/saxon-xqj-8.9.pom
365K downloaded
[INFO] [compiler:compile]
Compiling 77 source files to 

[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
Compiling 1 source file to 

[INFO] [surefire:test]
[INFO] Surefire report directory: 


---
 T E S T S
---
Running org.apache.synapse.util.TemporaryDataTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.592 sec

Results :

Tests run: 5, Failures: 0, Errors: 0, Skipped: 0

[HUDSON] Recording test results
[INFO] [bundle:bundle]
[INFO] [install:install]
[INFO] Installing 

 to 
/export/home/hudson/.m2/repository/org/apache/synapse/synapse-commons/1.3.0-SNAPSHOT/synapse-commons-1.3.0-SNAPSHOT.jar
[INFO] [bundle:install]
[INFO] Parsing file:/export/home/hudson/.m2/repository/repository.xml
[INFO] Installing 
org/apache/synapse/synapse-commons/1.3.0-SNAPSHOT/synapse-commons-1.3.0-SNAPSHOT.jar
[INFO] Writing OBR metadata
[HUDSON] Archiving 

 to /export/home/hudson/hudson/jobs/Synapse - 1.3 - 
SNAPSHOT/modules/org.apache.synapse$synapse-commons/builds/2009-12-07_06-02-03/archive/org.apache.synapse/synapse-commons/1.3.0-SNAPSHOT/pom.xml
[HUDSON] Archiving 

 to /export/home/hudson/hudson/jobs/Synapse - 1.3 - 
SNAPSHOT/modules/org.apache.synapse$synapse-commons/builds/2009-12-07_06-02-03/archive/org.apache.synapse/synapse-commons/1.3.0-SNAPSHOT/synapse-commons-1.3.0-SNAPSHOT.jar
[INFO] 
[INFO] Building Apache Synapse - Transports
[INFO]task

Build failed in Hudson: Synapse - 1.3 - SNA PSHOT » Apache Synapse - PIPE Transport #96

[Apache Hudson Server]

See 


--
[INFO] 
[INFO] Building Apache Synapse - PIPE Transport
[INFO]task-segment: [clean, install]
[INFO] 
[INFO] [clean:clean]
[INFO] Deleting directory 

[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
Compiling 9 source files to 

[HUDSON] Archiving 

 to /export/home/hudson/hudson/jobs/Synapse - 1.3 - 
SNAPSHOT/modules/org.apache.synapse$synapse-pipe-transport/builds/2009-12-07_06-02-03/archive/org.apache.synapse/synapse-pipe-transport/1.3.0-SNAPSHOT/pom.xml
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure

:[107,28]
 
receive(java.net.SocketAddress,org.apache.axis2.transport.base.datagram.DatagramEndpoint,byte[],int)
 in org.apache.axis2.transport.base.datagram.DatagramDispatcherCallback cannot 
be applied to (org.apache.synapse.transport.pipe.PipeEndpoint,byte[],int)


[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 5 minutes 50 seconds
[INFO] Finished at: Mon Dec 07 06:08:07 UTC 2009
[INFO] Final Memory: 39M/195M
[INFO] 


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

Hudson build is still unstable: Synapse - 1.3 - SNAPSH OT » Apache Synapse - Non-blocking HTTP/s Transport #96

[Apache Hudson Server]

See 




-
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

[Asankha C. Perera]

Hi Oleg, Eric
> Me neither, but from what I've seen, in HttpCoreNIOSender Synapse logs the 
> thrown IOReactorException including the cause information as early as it has 
> a chance to do so:
>   
Eric - you are looking at a previous version of the code, when we
enabled auto-restart on unexpected shutdown, we improved this logic.
However the real cause is the ClosedChannelException issue. We can
neatly log fatal causes when such a restart is performed, so that we
will know in future, what caused such a filure
>>> Was it correct to terminate the Reactor?
>>>   
>> No, it was not. ClosedChannelException should not be considered fatal.
>> 
> This was also my understanding.
>
>   
>> It is a shame the exception is unchecked, though.
>> 
> Agreed.
>   

Lets work on getting this fix into HttpComponents, probably as you
switch to the new HttpCore version, since this is a quite common
scenario you encounter in your deployment

cheers
asankha

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

http://esbmagic.blogspot.com

Re: JMX notifications for Endpoint state changes

[Ruwan Linton]

On Sun, Dec 6, 2009 at 11:35 PM, Hubert, Eric wrote:

>  Please see my comments inline!
>
>
>
> I agree with you, but we can keep that for future, if we are going to have
> complex policies as aspect configurations that you do not want to duplicate
> within the entries.
>
>  Anyway I can’t imagine a useful referenced bundling of individual
> aspects. Maybe I got something wrong with your last idea Ruwan, but wouldn’t
> the user end up with some fancy named aspect configurations like this
> ALL-OFF, ALL-ON, ONLY_STATISTIC, ONLY_TRACING, ONLY_NOTIFICATION,
> STATISTIC_AND_NOTIFICATION and thousands of other potentially useful
> combinations just to reuse the combination of Booleans? This doesn’t sound
> like being of help.
>
>  So here what I meant is not defining a set of named aspect
> configurations Rather the aspect configuration at the root level can be
> used to globally turn on that for all services but not endpoints, or all
> endpoints but not for sequences and so on.
>
>  Ah, OK – now I understand what you meant.
>
>
> Why I think this is important is lets say you have a state in your
> production server where you do not exactly know which sequence is receiving
> the malformed messages (you do not yet know which sequence) but you do not
> want to clutter the trace log with all traces, and this option will allow
> you to turn on tracing for all the sequences without enabling tracing for
> other entries like endpoints and so on... If this feature was not there
> the only option that you had is to put the aspect configuration into each
> and every sequence in your configuration.
>
>
>
> Yes, this is an option although I don’t think it would be the only option.
> Another option would be to allow the aspects block on any level: global
> (under definitions), global for all services or sequences or endpoints
> (wherever it makes sense) and on each individual service, or sequence or
> endpoint. The global default could be overridden wherever you like. So for
> your example globally everything is turned off, but only on the sequences
> level the tracing is activated. This means it is only active for all
> sequences, until you decide to exclude some sequences explicitly on the
> particular sequence.
>
>
>
> Maybe you option is easier to understand, but not that flexible and
> definitely not the only option. If you would like to trace all but 10 out of
> 100 sequences, you would need to activate it on 90 sequences. With the above
> approach you would activate it at the global sequence level and only
> deactivate it on those 10 sequences you want to exclude.
>
Eric, the issue in the synapse configuration language is that you do not
have a section which declares the sequences to do this, sequences,
endpoints, proxies and all local entries are on the same XML depth and there
is no chance to specify this configuraiton as you explained. If we had a
 tag enclosing all the sequence definitions, this would have been
the ideal approach, but it is not the case :-(

Thanks,
Ruwan

>
>
> Lets get started with the existing boolean values and keep the space to
> include policies later on, because we do not have a concrete requirement to
> support policies right now, we might not do it correctly and it is better to
> address that when the need arises. :-)
>
> +1
>



-- 
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

Build failed in Hudson: Synapse - 1.3 - SNAPSHOT #95

[Apache Hudson Server]

See 


--
[...truncated 84 lines...]
[INFO] [compiler:compile]
Compiling 77 source files to 

[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
Compiling 1 source file to 

[INFO] [surefire:test]
[INFO] Surefire report directory: 


---
 T E S T S
---
Running org.apache.synapse.util.TemporaryDataTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.028 sec

Results :

Tests run: 5, Failures: 0, Errors: 0, Skipped: 0

[HUDSON] Recording test results
[INFO] [bundle:bundle]
[INFO] [install:install]
[INFO] Installing 

 to 
/export/home/hudson/.m2/repository/org/apache/synapse/synapse-commons/1.3.0-SNAPSHOT/synapse-commons-1.3.0-SNAPSHOT.jar
[INFO] [bundle:install]
[INFO] Parsing file:/export/home/hudson/.m2/repository/repository.xml
[INFO] Installing 
org/apache/synapse/synapse-commons/1.3.0-SNAPSHOT/synapse-commons-1.3.0-SNAPSHOT.jar
[INFO] Writing OBR metadata
[HUDSON] Archiving 

 to /export/home/hudson/hudson/jobs/Synapse - 1.3 - 
SNAPSHOT/modules/org.apache.synapse$synapse-commons/builds/2009-12-07_00-28-27/archive/org.apache.synapse/synapse-commons/1.3.0-SNAPSHOT/pom.xml
[HUDSON] Archiving 

 to /export/home/hudson/hudson/jobs/Synapse - 1.3 - 
SNAPSHOT/modules/org.apache.synapse$synapse-commons/builds/2009-12-07_00-28-27/archive/org.apache.synapse/synapse-commons/1.3.0-SNAPSHOT/synapse-commons-1.3.0-SNAPSHOT.jar
[INFO] 
[INFO] Building Apache Synapse - Transports
[INFO]task-segment: [clean, install]
[INFO] 
[INFO] [clean:clean]
[INFO] [site:attach-descriptor]
[INFO] [install:install]
[INFO] Installing 

 to 
/export/home/hudson/.m2/repository/org/apache/synapse/synapse-transports/1.3.0-SNAPSHOT/synapse-transports-1.3.0-SNAPSHOT.pom
[HUDSON] Archiving 

 to /export/home/hudson/hudson/jobs/Synapse - 1.3 - 
SNAPSHOT/modules/org.apache.synapse$synapse-transports/builds/2009-12-07_00-28-27/archive/org.apache.synapse/synapse-transports/1.3.0-SNAPSHOT/pom.xml
[INFO] 
[INFO] Building Apache Synapse - Non-blocking HTTP/s Transport
[INFO]task-segment: [clean, install]
[INFO] 
[INFO] [clean:clean]
[INFO] Deleting directory 

[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] snapshot org.apache.axis2:axis2-transport-base:1.0-SNAPSHOT: checking 
for updates from apache-snapshots
[INFO] snapshot org.apache.axis2:axis2-transport-base:1.0-SNAPSHOT: checking 
for updates from wso2-m2
[INFO] snapshot org.apache.axis2:axis2-transport-base:1.0-SNAPSHOT: checking 
for updates from apache.snapshots
6K downloaded
[INFO] snapshot org.apache.axis2:axis2-transport:1.0-SNAPSHOT: checking for 
updates from apache-snapshots
[INFO] snapshot org.apache.axis2:axis2-transport:1.0-SNAPSHOT: checking for 
updates from wso2-m2
[INFO] snapshot org.apache.axis2:axis2-transport:1.0-SNAPSHOT: checking for 
updates from apache.snapshots
15K downloaded
[INFO] snapshot org.apache.axis2:axis2-transport-testkit:1.0-SNAPSHOT: checking 
for updates from apache-snapshots
[INFO] snapshot org.apache.axis2:axis2-transport-testkit:1.0-SNAPSHOT: checking 
for updates from wso2-m2
[INFO] snapshot org.apache.axis2:axis2-transport-testkit:1.0-SNAPSHOT: checking 
for updates from apache.snapshots
8K downloaded
[INFO] snapshot org.apache.synapse:synapse-commons:1.3.0-SNAPSHOT: checking for 
updates from apache-snapshots
[INFO] snapshot org.apache.s

Build failed in Hudson: Synapse - 1.3 - SNA PSHOT » Apache Synapse - PIPE Transport #95

[Apache Hudson Server]

See 


--
[INFO] 
[INFO] Building Apache Synapse - PIPE Transport
[INFO]task-segment: [clean, install]
[INFO] 
[INFO] [clean:clean]
[INFO] Deleting directory 

[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
Compiling 9 source files to 

[HUDSON] Archiving 

 to /export/home/hudson/hudson/jobs/Synapse - 1.3 - 
SNAPSHOT/modules/org.apache.synapse$synapse-pipe-transport/builds/2009-12-07_00-28-27/archive/org.apache.synapse/synapse-pipe-transport/1.3.0-SNAPSHOT/pom.xml
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure

:[107,28]
 
receive(java.net.SocketAddress,org.apache.axis2.transport.base.datagram.DatagramEndpoint,byte[],int)
 in org.apache.axis2.transport.base.datagram.DatagramDispatcherCallback cannot 
be applied to (org.apache.synapse.transport.pipe.PipeEndpoint,byte[],int)


[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 2 minutes 58 seconds
[INFO] Finished at: Mon Dec 07 00:31:33 UTC 2009
[INFO] Final Memory: 38M/193M
[INFO] 


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

Hudson build is still unstable: Synapse - 1.3 - SNAPSH OT » Apache Synapse - Non-blocking HTTP/s Transport #95

[Apache Hudson Server]

See 




-
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

[Hubert, Eric]

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?


> HttpCore does not do logging by itself. 
Ah, I think this perfectly explains it.

> I do not know Synapse that well to answer this question.
Me neither, but from what I've seen, in HttpCoreNIOSender Synapse logs the 
thrown IOReactorException including the cause information as early as it has a 
chance to do so:

Thread t = new Thread(new Runnable() {
public void run() {
try {
ioReactor.execute(ioEventDispatch);
} catch (InterruptedIOException ex) {
log.fatal("Reactor Interrupted");
} catch (IOException e) {
log.fatal("Encountered an I/O error: " + e.getMessage(), e);
}
 }
 }, "HttpCoreNIOSender");

So before this pops up, AbstractMultiworkerIOReactor performs the IOReactor 
shutdown in it's finally block, which obviously may take a while.
This should explain the behaviour I observed.


> > Was in this case the java.nio.channels.ClosedChannelException the cause
> of the IOReactor shutdown?
> Yes, it was.
Thanks for confirming this.


> > Was it correct to terminate the Reactor?
> No, it was not. ClosedChannelException should not be considered fatal.
This was also my understanding.

> It is a shame the exception is unchecked, though.
Agreed.


> > If some code within the core nio library decides to throw an
> IOReactorException could it make sense to log the cause immediately or are
> there cases where the code at higher levels may still consider it
> otherwise.
> 
> IOReactorException is considered fatal and should be propagated to the
> I/O reactor thread unless discarded by the IOReactorExceptionHandler
Ok, I now much better understand the expected flow. I was simply not aware, 
that http core nio is not logging at all and delegates this to the client using 
the library. This has some consequences to the order in which one can expect 
error messages. Good to know.


> > Anyway, if I'm not wrong and all of the above makes at least partially
> sense, than it looks to me that the fix in
> http://issues.apache.org/jira/browse/HTTPCORE-169
> > which went in beta-3 should have prevented the IOReactor restart.
> >
> 
> Correct. This is basically the same bug.
Thanks, Oleg you helped me a lot with your explanations. This is also just 
another proof that it is a good idea for us to update to 4.0.1.

Thanks,
   Eric 

Build failed in Hudson: Synapse - 1.3 - SNAPSHOT #94

[Apache Hudson Server]

See 


Changes:

[asanka] Changes from trunk Revision 887682 (QFJ config files and modified the 
QFJ setup instructions).

--
[...truncated 482 lines...]
at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:152)
at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:213)
at org.apache.log4j.helpers.QuietWriter.flush(QuietWriter.java:57)
at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:315)
at org.apache.log4j.WriterAppender.append(WriterAppender.java:159)
at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:230)
at 
org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:65)
at org.apache.log4j.Category.callAppenders(Category.java:203)
at org.apache.log4j.Category.forcedLog(Category.java:388)
at org.apache.log4j.Category.log(Category.java:853)
at 
org.apache.commons.logging.impl.Log4JLogger.info(Log4JLogger.java:199)
at org.mortbay.util.ThreadedServer$Acceptor.run(ThreadedServer.java:659)
ERROR [HttpServerWorker-1] AxisEngine The service cannot be found for the 
endpoint reference (EPR) 
/services/TestService-098ea871-5d06-4a41-a360-1971e0e13e6f
org.apache.axis2.AxisFault: The service cannot be found for the endpoint 
reference (EPR) /services/TestService-098ea871-5d06-4a41-a360-1971e0e13e6f
at 
org.apache.axis2.engine.DispatchPhase.checkPostConditions(DispatchPhase.java:65)
at org.apache.axis2.engine.Phase.invoke(Phase.java:334)
at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:251)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:160)
at 
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:167)
at 
org.apache.synapse.transport.nhttp.ServerWorker.processEntityEnclosingMethod(ServerWorker.java:349)
at 
org.apache.synapse.transport.nhttp.ServerWorker.run(ServerWorker.java:241)
at 
org.apache.axis2.transport.base.threads.NativeWorkerPool$1.run(NativeWorkerPool.java:58)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
ERROR [HttpServerWorker-1] ServerWorker Error processing POST request 
org.apache.axis2.AxisFault: The service cannot be found for the endpoint 
reference (EPR) /services/TestService-098ea871-5d06-4a41-a360-1971e0e13e6f
at 
org.apache.axis2.engine.DispatchPhase.checkPostConditions(DispatchPhase.java:65)
at org.apache.axis2.engine.Phase.invoke(Phase.java:334)
at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:251)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:160)
at 
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:167)
at 
org.apache.synapse.transport.nhttp.ServerWorker.processEntityEnclosingMethod(ServerWorker.java:349)
at 
org.apache.synapse.transport.nhttp.ServerWorker.run(ServerWorker.java:241)
at 
org.apache.axis2.transport.base.threads.NativeWorkerPool$1.run(NativeWorkerPool.java:58)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
log4j:ERROR Failed to flush writer,
java.io.InterruptedIOException
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(FileOutputStream.java:260)
at sun.nio.cs.StreamEncoder$CharsetSE.writeBytes(StreamEncoder.java:336)
at 
sun.nio.cs.StreamEncoder$CharsetSE.implFlushBuffer(StreamEncoder.java:404)
at sun.nio.cs.StreamEncoder$CharsetSE.implFlush(StreamEncoder.java:408)
at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:152)
at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:213)
at org.apache.log4j.helpers.QuietWriter.flush(QuietWriter.java:57)
at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:315)
at org.apache.log4j.WriterAppender.append(WriterAppender.java:159)
at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:230)
at 
org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:65)
at org.apache.log4j.Category.callAppenders(Category.java:203)
at org.apache.log4j.Category.forcedLog(Category.java:388)
at org.apache.log4j.Category.log(Category.java:853)
at 
org.apache.commons.logging.impl.Log4JLogger.info(Log4JLogger.java:199)
at org.mortbay.util.ThreadedServer$Acceptor.run(Threaded

Hudson build is still unstable: Synapse - 1.3 - SNAPSH OT » Apache Synapse - Non-blocking HTTP/s Transport #94

[Apache Hudson Server]

See 




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

Build failed in Hudson: Synapse - 1.3 - SNA PSHOT » Apache Synapse - PIPE Transport #94

[Apache Hudson Server]

See 


--
[INFO] 
[INFO] Building Apache Synapse - PIPE Transport
[INFO]task-segment: [clean, install]
[INFO] 
[INFO] [clean:clean]
[INFO] Deleting directory 

[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
Compiling 9 source files to 

[HUDSON] Archiving 

 to /export/home/hudson/hudson/jobs/Synapse - 1.3 - 
SNAPSHOT/modules/org.apache.synapse$synapse-pipe-transport/builds/2009-12-06_18-02-05/archive/org.apache.synapse/synapse-pipe-transport/1.3.0-SNAPSHOT/pom.xml
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure

:[107,28]
 
receive(java.net.SocketAddress,org.apache.axis2.transport.base.datagram.DatagramEndpoint,byte[],int)
 in org.apache.axis2.transport.base.datagram.DatagramDispatcherCallback cannot 
be applied to (org.apache.synapse.transport.pipe.PipeEndpoint,byte[],int)


[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 3 minutes 50 seconds
[INFO] Finished at: Sun Dec 06 18:06:09 UTC 2009
[INFO] Final Memory: 40M/194M
[INFO] 


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

RE: JMX notifications for Endpoint state changes

[Hubert, Eric]

Please see my comments inline!

I agree with you, but we can keep that for future, if we are going to have 
complex policies as aspect configurations that you do not want to duplicate 
within the entries.
Anyway I can’t imagine a useful referenced bundling of individual aspects. 
Maybe I got something wrong with your last idea Ruwan, but wouldn’t the user 
end up with some fancy named aspect configurations like this ALL-OFF, ALL-ON, 
ONLY_STATISTIC, ONLY_TRACING, ONLY_NOTIFICATION, STATISTIC_AND_NOTIFICATION and 
thousands of other potentially useful combinations just to reuse the 
combination of Booleans? This doesn’t sound like being of help.
So here what I meant is not defining a set of named aspect configurations 
Rather the aspect configuration at the root level can be used to globally turn 
on that for all services but not endpoints, or all endpoints but not for 
sequences and so on.

Ah, OK – now I understand what you meant.

Why I think this is important is lets say you have a state in your production 
server where you do not exactly know which sequence is receiving the malformed 
messages (you do not yet know which sequence) but you do not want to clutter 
the trace log with all traces, and this option will allow you to turn on 
tracing for all the sequences without enabling tracing for other entries like 
endpoints and so on... If this feature was not there the only option that you 
had is to put the aspect configuration into each and every sequence in your 
configuration.

Yes, this is an option although I don’t think it would be the only option. 
Another option would be to allow the aspects block on any level: global (under 
definitions), global for all services or sequences or endpoints (wherever it 
makes sense) and on each individual service, or sequence or endpoint. The 
global default could be overridden wherever you like. So for your example 
globally everything is turned off, but only on the sequences level the tracing 
is activated. This means it is only active for all sequences, until you decide 
to exclude some sequences explicitly on the particular sequence.

Maybe you option is easier to understand, but not that flexible and definitely 
not the only option. If you would like to trace all but 10 out of 100 
sequences, you would need to activate it on 90 sequences. With the above 
approach you would activate it at the global sequence level and only deactivate 
it on those 10 sequences you want to exclude.

Lets get started with the existing boolean values and keep the space to include 
policies later on, because we do not have a concrete requirement to support 
policies right now, we might not do it correctly and it is better to address 
that when the need arises. :-)

+1

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

[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: JMX notifications for Endpoint state changes

[Ruwan Linton]

+1 for integrating the ideas that came up on this thread and do the
implementation.

See my comments in-line as well;

On Sun, Dec 6, 2009 at 5:40 PM, Hubert, Eric wrote:

>  Hi,
>
>
>
> I 100% agree with Ruwan, that a global configuration shall not address
> individual services, endpoints or sequences. This would make the
> configuration extremely hard to read and understand. I think of this more in
> an object oriented fashion as properties of the elements inheriting defaults
> from their parents. Anyway I think I already stated my idea.
>
>
>
> I’m not against the idea of defining named policies/aspects and reference
> them on any level, but at the moment, I do not see the big value. It would
> make perfectly sense, if such a configuration would consist of many sub
> configuration elements we would like to share across multiple configuration
> elements. For a single boolean or even a set of booleans, this might not
> make it easier to understand without adding any extra value.
>
I agree with you, but we can keep that for future, if we are going to have
complex policies as aspect configurations that you do not want to duplicate
within the entries.

> Anyway I can’t imagine a useful referenced bundling of individual aspects.
> Maybe I got something wrong with your last idea Ruwan, but wouldn’t the user
> end up with some fancy named aspect configurations like this ALL-OFF,
> ALL-ON, ONLY_STATISTIC, ONLY_TRACING, ONLY_NOTIFICATION,
> STATISTIC_AND_NOTIFICATION and thousands of other potentially useful
> combinations just to reuse the combination of Booleans? This doesn’t sound
> like being of help.
>
So here what I meant is not defining a set of named aspect
configurations Rather the aspect configuration at the root level can be
used to globally turn on that for all services but not endpoints, or all
endpoints but not for sequences and so on.

Why I think this is important is lets say you have a state in your
production server where you do not exactly know which sequence is receiving
the malformed messages (you do not yet know which sequence) but you do not
want to clutter the trace log with all traces, and this option will allow
you to turn on tracing for all the sequences without enabling tracing for
other entries like endpoints and so on... If this feature was not there the
only option that you had is to put the aspect configuration into each and
every sequence in your configuration.

I didn't think of a good configuration option for this, whether we use
string literals to refer to entries or a symbolic type. Any way I am open to
not to include this as well, since it is sort of a corner case.

> Indika proposed a policy definitions per aspect type to externalize, if I
> got it right. This would make sense for me at the moment a policy could
> contain more elements than just the Boolean, e.g. a certain further
> filtering – on, but only for some defined events. In order to not have to
> redefine those filters all over the place, one could reference a policy
> definition. Could make perfectly sense and would be very open for more
> complex aspect configurations.
>
Lets get started with the existing boolean values and keep the space to
include policies later on, because we do not have a concrete requirement to
support policies right now, we might not do it correctly and it is better to
address that when the need arises. :-)

Thanks,
Ruwan

> Too me the concept of inheritance from global definitions across the
> different levels would help most to reduce the configuration amount. And
> this is independent from using simple attributes with on/off or complex
> referenced policies. So maybe all ideas can be integrated into a good
> solution?
>
>
>
> Regards,
>
>Eric
>
>
>   --
>
> *From:* Ruwan Linton [mailto:ruwan.lin...@gmail.com]
> *Sent:* Saturday, December 05, 2009 3:44 AM
>
> *To:* dev@synapse.apache.org
> *Subje*
> *ct:* Re: JMX notifications for Endpoint state changes
>
>
>
> Hhhmmm, not sure whether it is good to keep a one global aspect
> configuration which configures all the child nodes even when you need to
> turn on statistics (for example) for a given sequence, that will make the
> configuration readability harder. I would think of the implementation when
> deciding the configuration design, so that it is not affecting the
> performance as well.
>
> I would like to keep a global configuration of aspects, yes as Supun
> explined that can define whether all services, all endpoints or
> sequences but not a named entity. The default behaviour will be at
> global level all these will be turned off for all types of entities.
>
> Then at each and every element level you can define there aspects using the
> same configuraiton.
>
> Alternately, we could let the aspect configurations to be refered from from
> all the elements, inorder to make this work we need to be able to define a
> named set of aspects and from services and sequences they can refer to its
> aspec

Build failed in Hudson: Synapse - 1.3 - SNAPSHOT #93

[Apache Hudson Server]

See 


Changes:

[asanka] Revision 887647 of trunk (configuration info for eventing)

--
[...truncated 69 lines...]
Downloading: 
http://people.apache.org/~asankha/repository/net/sf/saxon/saxon/8.9/saxon-8.9.pom
Downloading: http://repo1.maven.org/maven2/net/sf/saxon/saxon/8.9/saxon-8.9.pom
Downloading: 
http://repository.apache.org/snapshots/net/sf/saxon/saxon-dom/8.9/saxon-dom-8.9.pom
Downloading: 
http://dist.wso2.org/maven2//net/sf/saxon/saxon-dom/8.9/saxon-dom-8.9.pom
Downloading: 
http://people.apache.org/~asankha/repository/net/sf/saxon/saxon-dom/8.9/saxon-dom-8.9.pom
Downloading: 
http://repo1.maven.org/maven2/net/sf/saxon/saxon-dom/8.9/saxon-dom-8.9.pom
Downloading: 
http://repository.apache.org/snapshots/net/sf/saxon/saxon-xqj/8.9/saxon-xqj-8.9.pom
Downloading: 
http://dist.wso2.org/maven2//net/sf/saxon/saxon-xqj/8.9/saxon-xqj-8.9.pom
Downloading: 
http://people.apache.org/~asankha/repository/net/sf/saxon/saxon-xqj/8.9/saxon-xqj-8.9.pom
Downloading: 
http://repo1.maven.org/maven2/net/sf/saxon/saxon-xqj/8.9/saxon-xqj-8.9.pom
365K downloaded
[INFO] [compiler:compile]
Compiling 77 source files to 

[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
Compiling 1 source file to 

[INFO] [surefire:test]
[INFO] Surefire report directory: 


---
 T E S T S
---
Running org.apache.synapse.util.TemporaryDataTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.106 sec

Results :

Tests run: 5, Failures: 0, Errors: 0, Skipped: 0

[HUDSON] Recording test results
[INFO] [bundle:bundle]
[INFO] [install:install]
[INFO] Installing 

 to 
/export/home/hudson/.m2/repository/org/apache/synapse/synapse-commons/1.3.0-SNAPSHOT/synapse-commons-1.3.0-SNAPSHOT.jar
[INFO] [bundle:install]
[INFO] Parsing file:/export/home/hudson/.m2/repository/repository.xml
[INFO] Installing 
org/apache/synapse/synapse-commons/1.3.0-SNAPSHOT/synapse-commons-1.3.0-SNAPSHOT.jar
[INFO] Writing OBR metadata
[HUDSON] Archiving 

 to /export/home/hudson/hudson/jobs/Synapse - 1.3 - 
SNAPSHOT/modules/org.apache.synapse$synapse-commons/builds/2009-12-06_12-08-20/archive/org.apache.synapse/synapse-commons/1.3.0-SNAPSHOT/pom.xml
[HUDSON] Archiving 

 to /export/home/hudson/hudson/jobs/Synapse - 1.3 - 
SNAPSHOT/modules/org.apache.synapse$synapse-commons/builds/2009-12-06_12-08-20/archive/org.apache.synapse/synapse-commons/1.3.0-SNAPSHOT/synapse-commons-1.3.0-SNAPSHOT.jar
[INFO] 
[INFO] Building Apache Synapse - Transports
[INFO]task-segment: [clean, install]
[INFO] 
[INFO] [clean:clean]
[INFO] [site:attach-descriptor]
[INFO] [install:install]
[INFO] Installing 

 to 
/export/home/hudson/.m2/repository/org/apache/synapse/synapse-transports/1.3.0-SNAPSHOT/synapse-transports-1.3.0-SNAPSHOT.pom
[HUDSON] Archiving 

 to /export/home/hudson/hudson/jobs/Synapse - 1.3 - 
SNAPSHOT/modules/org.apache.synapse$synapse-transports/builds/2009-12-06_12-08-20/archive/org.apache.synapse/synapse-transports/1.3.0-SNAPSHOT/pom.xml
[INFO] 
[INFO] Building Apache Synapse - Non-blocking HTTP/s Transport
[INFO]task-segment: [clean, install]
[INFO] 
[INFO] [clean:clean]
[INFO] Deleting directory 

[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] snapshot org.apache.axis2:axis2-transport-base:1.0-SNAPSHOT: checking 
for updates from apache-snapshots
[INFO] sn

Build failed in Hudson: Synapse - 1.3 - SNA PSHOT » Apache Synapse - PIPE Transport #93

[Apache Hudson Server]

See 


--
[INFO] 
[INFO] Building Apache Synapse - PIPE Transport
[INFO]task-segment: [clean, install]
[INFO] 
[INFO] [clean:clean]
[INFO] Deleting directory 

[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
Compiling 9 source files to 

[HUDSON] Archiving 

 to /export/home/hudson/hudson/jobs/Synapse - 1.3 - 
SNAPSHOT/modules/org.apache.synapse$synapse-pipe-transport/builds/2009-12-06_12-08-20/archive/org.apache.synapse/synapse-pipe-transport/1.3.0-SNAPSHOT/pom.xml
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure

:[107,28]
 
receive(java.net.SocketAddress,org.apache.axis2.transport.base.datagram.DatagramEndpoint,byte[],int)
 in org.apache.axis2.transport.base.datagram.DatagramDispatcherCallback cannot 
be applied to (org.apache.synapse.transport.pipe.PipeEndpoint,byte[],int)


[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 6 minutes 16 seconds
[INFO] Finished at: Sun Dec 06 12:14:49 UTC 2009
[INFO] Final Memory: 40M/196M
[INFO] 
Waiting for Hudson to finish collecting data


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

Hudson build is still unstable: Synapse - 1.3 - SNAPSH OT » Apache Synapse - Non-blocking HTTP/s Transport #93

[Apache Hudson Server]

See 




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

RE: JMX notifications for Endpoint state changes

[Hubert, Eric]

Hi,

I 100% agree with Ruwan, that a global configuration shall not address 
individual services, endpoints or sequences. This would make the configuration 
extremely hard to read and understand. I think of this more in an object 
oriented fashion as properties of the elements inheriting defaults from their 
parents. Anyway I think I already stated my idea.

I’m not against the idea of defining named policies/aspects and reference them 
on any level, but at the moment, I do not see the big value. It would make 
perfectly sense, if such a configuration would consist of many sub 
configuration elements we would like to share across multiple configuration 
elements. For a single boolean or even a set of booleans, this might not make 
it easier to understand without adding any extra value.

Anyway I can’t imagine a useful referenced bundling of individual aspects. 
Maybe I got something wrong with your last idea Ruwan, but wouldn’t the user 
end up with some fancy named aspect configurations like this ALL-OFF, ALL-ON, 
ONLY_STATISTIC, ONLY_TRACING, ONLY_NOTIFICATION, STATISTIC_AND_NOTIFICATION and 
thousands of other potentially useful combinations just to reuse the 
combination of Booleans? This doesn’t sound like being of help.

Indika proposed a policy definitions per aspect type to externalize, if I got 
it right. This would make sense for me at the moment a policy could contain 
more elements than just the Boolean, e.g. a certain further filtering – on, but 
only for some defined events. In order to not have to redefine those filters 
all over the place, one could reference a policy definition. Could make 
perfectly sense and would be very open for more complex aspect configurations.

Too me the concept of inheritance from global definitions across the different 
levels would help most to reduce the configuration amount. And this is 
independent from using simple attributes with on/off or complex referenced 
policies. So maybe all ideas can be integrated into a good solution?

Regards,
   Eric


From: Ruwan Linton [mailto:ruwan.lin...@gmail.com]
Sent: Saturday, December 05, 2009 3:44 AM
To: dev@synapse.apache.org
Subject: Re: JMX notifications for Endpoint state changes

Hhhmmm, not sure whether it is good to keep a one global aspect configuration 
which configures all the child nodes even when you need to turn on statistics 
(for example) for a given sequence, that will make the configuration 
readability harder. I would think of the implementation when deciding the 
configuration design, so that it is not affecting the performance as well.

I would like to keep a global configuration of aspects, yes as Supun explined 
that can define whether all services, all endpoints or sequences but not a 
named entity. The default behaviour will be at global level all these will be 
turned off for all types of entities.

Then at each and every element level you can define there aspects using the 
same configuraiton.

Alternately, we could let the aspect configurations to be refered from from all 
the elements, inorder to make this work we need to be able to define a named 
set of aspects and from services and sequences they can refer to its aspect. It 
will enable us to reuse the aspect configuraitons of the same type within 
different elements without redefining.

Being said all that I would like to do the initial implementation of this, 
considering the amount of change that this idea is going to take us.

Thanks,
Ruwan
On Sat, Dec 5, 2009 at 2:04 AM, Supun Kamburugamuva 
mailto:supu...@gmail.com>> wrote:
Hi,

If we can define the statistics enabled endpoints or mediators at the top level 
aspect configuration we can leave the aspect configuration element only to the 
top level. This reduce the clutter from the specific component configurations. 
Specific component configurations can focus only on what they are mean to do. 
Things like statistics collection can be separated from the mediator 
configurations.

Thanks,
Supun..

On Sat, Dec 5, 2009 at 1:56 AM, Hubert, Eric 
mailto:eric.hub...@foxmobile.com>> wrote:
I would vote for both, on global and on those child elements where it is 
applicable with the simple rule, that at runtime the most specific one wins.

This would allow for the following scenarios.

Turn it off for all (globally)
Turn it off globally, but only activate it on demand for specific endpoints, 
services etc.
Turn it on globally
Turn it on globally, but disable it for some specific services, endpoints 
(exclusions)

Of cause you could also add a configuration right in the middle on the level of 
the services or endpoints etc., if someone also wants to turn an aspect only on 
for ALL services, but not for all endpoints, but just some of them.

Regards,
  Eric




From: Supun Kamburugamuva [mailto:supu...@gmail.com]
Sent: Friday, December 04, 2009 8:15 PM

To: dev@synapse.apache.org

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

[Hubert, Eric]

> 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.

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.

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

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

Was in this case the java.nio.channels.ClosedChannelException the cause of the 
IOReactor shutdown? Was it correct to terminate the Reactor? If some code 
within the core nio library decides to throw an IOReactorException could it 
make sense to log the cause immediately or are there cases where the code at 
higher levels may still consider it otherwise.

Anyway, if I'm not wrong and all of the above makes at least partially sense, 
than it looks to me that the fix in 
http://issues.apache.org/jira/browse/HTTPCORE-169
which went in beta-3 should have prevented the IOReactor restart.

Oleg, please correct me if my understanding is wrong. I'm not very familiar 
with the code.

Regards,
   Eric