[jira] Created: (SYNAPSE-345) SOAP headers MUST be namespace-qualified

[Glen Daniels (JIRA)]

SOAP headers MUST be namespace-qualified


 Key: SYNAPSE-345
 URL: https://issues.apache.org/jira/browse/SYNAPSE-345
 Project: Synapse
  Issue Type: Bug
  Components: Extension Mediators
Reporter: Glen Daniels
Priority: Minor


(I'm not sure if this is "core" or "extension mediators" - maybe you should 
change the component name to just "mediators"?)

Line 103 of HeaderMediator.java is the problem here.  I was originally going to 
write an issue about the fact that using "To", "From", etc as aliases for 
"wsa:To", "wsa:From", etc meant that users couldn't actually insert headers 
called  or ... but then I remembered that both SOAP 1.1 and SOAP 1.2 
explicitly call out the fact that ALL header blocks must be 
namespace-qualified.  So it's totally fine to map "To" -> "wsa:To"...

BUT it's not fine to put in headers with no namespace... so please change line 
103 to either log a problem or throw a fault, whatever you feel is appropriate?

Thanks!
--Glen


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

Improving the loadbalancing support

[Hubert, Eric]

Hi all,

today I would like to discuss some options to improve the load balancing
support of Apache Synapse. As not all of my ideas have settled, I may
miss some pieces of the current implementation and would like to get
some feedback about my ideas, I decided to not create a JIRA for that
immediately. Though, after our discussion I would like to summarize the
results in a JIRA.

1)
Where can I review the status of the endpoints of a loadbalance group?
It should be possible to query the status of each endpoint via JMX. It
should also be possible to get the number of configured as well as
active endpoints of a load balance group via JMX. This way it will be
possible to use some meaningful external monitoring. For example the
user could define an alert if only 2 nodes are left or the ratio of
available nodes is less then 20% or something like this.

2)
Another very useful feature would be the possibility to manually
deactivate an endpoint of a load balancing group. If I understand it
correctly right now you have to remove the endpoint from the group and
restart your server (or cluster gracefully). Not very nice. To implement
this, it might make sense to differ between three states: "active",
"deactivated" and "manually deactivated". A manually deactivated
endpoint can only be manually reactivated. Automatic retry will not be
used for endpoints in that state.

3)
Why did you choose the interpretation of a missing
suspendDurationOnFailure that it will never be recovered after a
failure? At least from my point of view this does not match my intuition
and expectations. Is this really a good default value? When does a user
ever want to have this effect? Do I understand this wrong, or does the
user have to restart the ESB to change the status back to "active"?

4)
A static, configurable value for suspendDurationOnFailure is better than
having a hardcoded value, but is also not optimal. The user has always
the problem that he tries to balance between different side effects
depending on the cause of the service outage. When you think about short
network instabilities and you have a small cluster (think of two nodes)
you are somehow forced to keep that check interval rather short. If then
suddenly a service fails for some other reason and a long period of
time, this has a negative impact on the performance, as the retries
happen to often.
It would be much better to use a dynamic approach with a changing check
interval. Start frequently (short interval of a few seconds) and
increase this up to a maximum value based on the number of tries. Maybe
one could come up with a general purpose function, where the user can
specify the arguments. This should allow preserving the existing
behaviour while also supporting better suited algorithms.

5)
When *all* nodes are inactive, the ESB currently creates a fault
immediately. I'm thinking whether this makes sense or not. Maybe it
would be best, if the user could decide between two options:
a) current behaviour
b) first try all inactive endpoints until either one endpoint works, or
all endpoints have been tried out once and only then issue a fault
I'm not sure about this one. But the following happened during a test of
a minimal service cluster with two nodes. The suspendDurationOnFailure
had been set to 60 seconds. The first node had been passive due to some
maintenance. So all requests have been served via the second node.
Suddently a short network outage happened. The second node was marked as
deactivated. It was reachable in the next second but the ESB marked it
as passive. Actually the whole system was down for one minute. So you
have to think about a shorter period of time for the check interval,
which again would be bad for the server which has been down for
maintenance. If the ESB would have done one additional round of retries,
it would have detected that the endpoint in fact is already up again.


Now I hope to receive a lot of comments and feedback. Maybe we can work
together to make improvements in this area.

Please point me to some existing functionality I may have missed!


Regards,
   Eric

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

[jira] Commented: (SYNAPSE-341) System unstable when HTTP response returned before request fully written

[Oleg Kalnichevski (JIRA)]

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

Oleg Kalnichevski commented on SYNAPSE-341:
---

Asankha,

This is a bit of a grey area in the HTTP spec. It is not quite clear if the 
origin server really MUST read the entire request body before sending a 
response. 

Anyways, lots of HTTP servers out there in the wild do send a response and 
immediately drop the connection before the request body is fully read. 
HttpClient, for instance, can't handle such cases gracefully, but Synapse due 
to the asynchronous nature of its HTTP transport implementation should be able 
to.

Oleg

> System unstable when HTTP response returned before request fully written
> 
>
> Key: SYNAPSE-341
> URL: https://issues.apache.org/jira/browse/SYNAPSE-341
> Project: Synapse
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 1.2-beta1
> Environment: All environments
>Reporter: Jake Lambert
>Assignee: Asankha C. Perera
>Priority: Critical
> Fix For: 1.3
>
> Attachments: ClientSideReqResp.txt
>
>
> When using a proxy service and HTTP-NIO the following error is repeatedly 
> generated when a remote WS returns its response before the request is fully 
> written (i.e. when AXIOM is being used by the target service to parse the 
> request XML and the request includes unprocessed attachment(s) or a fault 
> occurs before fully reading the request):
> I/O dispatcher 12: System may be unstable: IOReactor encountered a runtime 
> exception : null
> java.lang.NullPointerException
>   at 
> org.apache.synapse.transport.nhttp.ClientHandler.outputReady(ClientHandler.java:353)
>   at 
> org.apache.http.impl.nio.DefaultNHttpClientConnection.produceOutput(DefaultNHttpClientConnection.java:170)
>   at 
> org.apache.http.impl.nio.DefaultClientIOEventDispatch.outputReady(DefaultClientIOEventDispatch.java:105)
>   at 
> org.apache.http.impl.nio.reactor.BaseIOReactor.writable(BaseIOReactor.java:114)
>   at 
> org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:198)
>   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)
>   at java.lang.Thread.run(Unknown Source)
> The actual cause is the ConnectionPool 'cleanConnectionReferences()' method, 
> which clears the REQUEST_SOURCE_BUFFER upon completion of the response HTTP 
> decoding, rather than on completion of both the request AND response 
> processing.

-- 
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-288) AbstractPollingTransportListener fails to cancel timer on destroy

[Asankha C. Perera (JIRA)]

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

Asankha C. Perera resolved SYNAPSE-288.
---

   Resolution: Fixed
Fix Version/s: (was: 1.3)
   1.2
 Assignee: Asankha C. Perera  (was: Andreas Veithen)

should be resolved as SYNAPSE-331 which duplicated this was fixed for 1.2

> AbstractPollingTransportListener fails to cancel timer on destroy
> -
>
> Key: SYNAPSE-288
> URL: https://issues.apache.org/jira/browse/SYNAPSE-288
> Project: Synapse
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: NIGHTLY
>Reporter: Andreas Veithen
>Assignee: Asankha C. Perera
>Priority: Minor
> Fix For: 1.2
>
>
> After AbstractPollingTransportListener#destroy is called, the following 
> exception is triggered:
> Exception in thread "PollTimer" 
> java.util.concurrent.RejectedExecutionException
>   at 
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1477)
>   at 
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:384)
>   at 
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:856)
>   at 
> org.apache.synapse.transport.base.threads.NativeWorkerPool.execute(NativeWorkerPool.java:55)
>   at 
> org.apache.synapse.transport.base.AbstractPollingTransportListener$1.run(AbstractPollingTransportListener.java:81)
>   at java.util.TimerThread.mainLoop(Timer.java:512)
>   at java.util.TimerThread.run(Timer.java:462)
> Obviously the timer still tries to schedule a new task after the worker pool 
> has been shut down. I suspect that the reason is that 
> AbstractTransportListener#stop doesn't call stopListeningForService, given 
> that AbstractPollingTransportListener cancels the timers there.

-- 
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-341) System unstable when HTTP response returned before request fully written

[Asankha C. Perera (JIRA)]

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

Asankha C. Perera commented on SYNAPSE-341:
---

Maybe Oleg can comment on whether an origin server can prematurely respond to 
an http request, before the full request was read. 

I found the following from the RFC 2616 Section 8.2.3

  - If an origin server receives a request that does not include an
Expect request-header field with the "100-continue" expectation,
the request includes a request body, and the server responds
with a final status code before reading the entire request body
from the transport connection, then the server SHOULD NOT close
the transport connection until it has read the entire request,
or until the client closes the connection. Otherwise, the client
might not reliably receive the response message. However, this
requirement is not be construed as preventing a server from
defending itself against denial-of-service attacks, or from
badly broken client implementations.

Same section also mentions:
 - Upon receiving a request which includes an Expect request-header
field with the "100-continue" expectation, an origin server MUST
either respond with 100 (Continue) status and continue to read
from the input stream, or respond with a final status code. The
origin server MUST NOT wait for the request body before sending
the 100 (Continue) response. If it responds with a final status
code, it MAY close the transport connection or it MAY continue
to read and discard the rest of the request.  It MUST NOT
perform the requested method if it returns a final status code.

> System unstable when HTTP response returned before request fully written
> 
>
> Key: SYNAPSE-341
> URL: https://issues.apache.org/jira/browse/SYNAPSE-341
> Project: Synapse
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 1.2-beta1
> Environment: All environments
>Reporter: Jake Lambert
>Assignee: Asankha C. Perera
>Priority: Critical
> Fix For: 1.3
>
> Attachments: ClientSideReqResp.txt
>
>
> When using a proxy service and HTTP-NIO the following error is repeatedly 
> generated when a remote WS returns its response before the request is fully 
> written (i.e. when AXIOM is being used by the target service to parse the 
> request XML and the request includes unprocessed attachment(s) or a fault 
> occurs before fully reading the request):
> I/O dispatcher 12: System may be unstable: IOReactor encountered a runtime 
> exception : null
> java.lang.NullPointerException
>   at 
> org.apache.synapse.transport.nhttp.ClientHandler.outputReady(ClientHandler.java:353)
>   at 
> org.apache.http.impl.nio.DefaultNHttpClientConnection.produceOutput(DefaultNHttpClientConnection.java:170)
>   at 
> org.apache.http.impl.nio.DefaultClientIOEventDispatch.outputReady(DefaultClientIOEventDispatch.java:105)
>   at 
> org.apache.http.impl.nio.reactor.BaseIOReactor.writable(BaseIOReactor.java:114)
>   at 
> org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:198)
>   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)
>   at java.lang.Thread.run(Unknown Source)
> The actual cause is the ConnectionPool 'cleanConnectionReferences()' method, 
> which clears the REQUEST_SOURCE_BUFFER upon completion of the response HTTP 
> decoding, rather than on completion of both the request AND response 
> processing.

-- 
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-344) Race condition on connection reuse causes 'Request already submitted' exception

[Jake Lambert (JIRA)]

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

Jake Lambert commented on SYNAPSE-344:
--

I'm able to reproduce the problem with the head of the Synapse 1.2 trunk (beta 
1, svn rev 663252).Both this bug and related SYNAPSE-341 use the same test 
case as the fixed SYNAPSE-321bug (proxy service, concurrency, larger messages 
with attachments, targetting Axis2 service) - these are just further problems 
I'm finding.

> Race condition on connection reuse causes 'Request already submitted' 
> exception
> ---
>
> Key: SYNAPSE-344
> URL: https://issues.apache.org/jira/browse/SYNAPSE-344
> Project: Synapse
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 1.1.1
> Environment: All environments
>Reporter: Jake Lambert
>Priority: Critical
>
> When using a proxy service and HTTP-NIO with a moderate number of concurrent 
> requests some requests fail with the following error:
> HttpServerWorker-25: Unexpected HTTP protocol error: Request already submitted
> org.apache.http.HttpException: Request already submitted
>   at 
> org.apache.http.impl.nio.DefaultNHttpClientConnection.submitRequest(DefaultNHttpClientConnection.java:203)
>   at 
> org.apache.synapse.transport.nhttp.ClientHandler.submitRequest(ClientHandler.java:142)
>   at 
> org.apache.synapse.transport.nhttp.HttpCoreNIOSender.sendAsyncRequest(HttpCoreNIOSender.java:340)
>   at 
> org.apache.synapse.transport.nhttp.HttpCoreNIOSender.invoke(HttpCoreNIOSender.java:256)
> ...
> This can occur in a situation similar to that in SYNAPSE-341 (remote WS 
> returns its response before the request is fully written).  It's due to a 
> race condition when reusing a connection between a client I/O dispatcher 
> thread calling NHttpClientConnection.resetOutput() when the request writing 
> is complete and an HttpServerWorker thread calling 
> NHttpClientConnection.submitRequest() on the same pooled connection after it 
> has been released when the response reading is complete.

-- 
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-344) Race condition on connection reuse causes 'Request already submitted' exception

[Jake Lambert (JIRA)]

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

Jake Lambert updated SYNAPSE-344:
-

Description: 
When using a proxy service and HTTP-NIO with a moderate number of concurrent 
requests some requests fail with the following error:

HttpServerWorker-25: Unexpected HTTP protocol error: Request already submitted
org.apache.http.HttpException: Request already submitted
at 
org.apache.http.impl.nio.DefaultNHttpClientConnection.submitRequest(DefaultNHttpClientConnection.java:203)
at 
org.apache.synapse.transport.nhttp.ClientHandler.submitRequest(ClientHandler.java:142)
at 
org.apache.synapse.transport.nhttp.HttpCoreNIOSender.sendAsyncRequest(HttpCoreNIOSender.java:340)
at 
org.apache.synapse.transport.nhttp.HttpCoreNIOSender.invoke(HttpCoreNIOSender.java:256)
...

This can occur in a situation similar to that in SYNAPSE-341 (remote WS returns 
its response before the request is fully written).  It's due to a race 
condition when reusing a connection between a client I/O dispatcher thread 
calling NHttpClientConnection.resetOutput() when the request writing is 
complete and an HttpServerWorker thread calling 
NHttpClientConnection.submitRequest() on the same pooled connection after it 
has been released when the response reading is complete.

  was:
When using a proxy service and HTTP-NIO with a moderate number of concurrent 
requests some requests fail with the following error:

HttpServerWorker-25: Unexpected HTTP protocol error: Request already submitted
org.apache.http.HttpException: Request already submitted
at 
org.apache.http.impl.nio.DefaultNHttpClientConnection.submitRequest(DefaultNHttpClientConnection.java:203)
at 
org.apache.synapse.transport.nhttp.ClientHandler.submitRequest(ClientHandler.java:142)
at 
org.apache.synapse.transport.nhttp.HttpCoreNIOSender.sendAsyncRequest(HttpCoreNIOSender.java:340)
at 
org.apache.synapse.transport.nhttp.HttpCoreNIOSender.invoke(HttpCoreNIOSender.java:256)
at 
com.alcatel.grizzly.mw.transport.WSGHttpTransportSender.invoke(WSGHttpTransportSender.java:171)
at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:448)
at 
org.apache.synapse.core.axis2.DynamicAxisOperation$DynamicOperationClient.send(DynamicAxisOperation.java:190)
at 
org.apache.synapse.core.axis2.DynamicAxisOperation$DynamicOperationClient.executeImpl(DynamicAxisOperation.java:174)
at 
org.apache.axis2.client.OperationClient.execute(OperationClient.java:163)
at 
com.alcatel.grizzly.synapse.custom.WsgFlexibleMEPClient.send(WsgFlexibleMEPClient.java:284)
at 
com.alcatel.grizzly.synapse.custom.WsgSynapseEnvironment.send(WsgSynapseEnvironment.java:34)
at 
org.apache.synapse.endpoints.AddressEndpoint.send(AddressEndpoint.java:195)
at 
com.alcatel.grizzly.synapse.custom.WsgAddressEndpoint.send(WsgAddressEndpoint.java:68)
at 
org.apache.synapse.mediators.builtin.SendMediator.mediate(SendMediator.java:157)
at 
org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:58)
at 
org.apache.synapse.mediators.base.SequenceMediator.mediate(SequenceMediator.java:125)
at 
org.apache.synapse.core.axis2.ProxyServiceMessageReceiver.receive(ProxyServiceMessageReceiver.java:158)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:176)
at 
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275)
at 
org.apache.synapse.transport.nhttp.ServerWorker.processPost(ServerWorker.java:238)
at 
org.apache.synapse.transport.nhttp.ServerWorker.run(ServerWorker.java:194)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown 
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

This can occur in a situation similar to that in SYNAPSE-341 (remote WS returns 
its response before the request is fully written).  It's due to a race 
condition when reusing a connection between a client I/O dispatcher thread 
calling NHttpClientConnection.resetOutput() when the request writing is 
complete and an HttpServerWorker thread calling 
NHttpClientConnection.submitRequest() on the same pooled connection after it 
has been released when the response reading is complete.


> Race condition on connection reuse causes 'Request already submitted' 
> exception
> ---
>
> Key: SYNAPSE-344
> URL: https://issues.apache.org/jira/browse/SYNAPSE-344
> Project: Synapse
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 1.1.1
> Environment: All environments
>Reporter: Jake Lambert
>Prior

[jira] Commented: (SYNAPSE-344) Race condition on connection reuse causes 'Request already submitted' exception

[Asankha C. Perera (JIRA)]

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

Asankha C. Perera commented on SYNAPSE-344:
---

Jake

Can you test this against the latest codebase set to be released shortly.. 
steps and any material to recreate would always be good to have

asankha

> Race condition on connection reuse causes 'Request already submitted' 
> exception
> ---
>
> Key: SYNAPSE-344
> URL: https://issues.apache.org/jira/browse/SYNAPSE-344
> Project: Synapse
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 1.1.1
> Environment: All environments
>Reporter: Jake Lambert
>Priority: Critical
>
> When using a proxy service and HTTP-NIO with a moderate number of concurrent 
> requests some requests fail with the following error:
> HttpServerWorker-25: Unexpected HTTP protocol error: Request already submitted
> org.apache.http.HttpException: Request already submitted
>   at 
> org.apache.http.impl.nio.DefaultNHttpClientConnection.submitRequest(DefaultNHttpClientConnection.java:203)
>   at 
> org.apache.synapse.transport.nhttp.ClientHandler.submitRequest(ClientHandler.java:142)
>   at 
> org.apache.synapse.transport.nhttp.HttpCoreNIOSender.sendAsyncRequest(HttpCoreNIOSender.java:340)
>   at 
> org.apache.synapse.transport.nhttp.HttpCoreNIOSender.invoke(HttpCoreNIOSender.java:256)
>   at 
> com.alcatel.grizzly.mw.transport.WSGHttpTransportSender.invoke(WSGHttpTransportSender.java:171)
>   at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:448)
>   at 
> org.apache.synapse.core.axis2.DynamicAxisOperation$DynamicOperationClient.send(DynamicAxisOperation.java:190)
>   at 
> org.apache.synapse.core.axis2.DynamicAxisOperation$DynamicOperationClient.executeImpl(DynamicAxisOperation.java:174)
>   at 
> org.apache.axis2.client.OperationClient.execute(OperationClient.java:163)
>   at 
> com.alcatel.grizzly.synapse.custom.WsgFlexibleMEPClient.send(WsgFlexibleMEPClient.java:284)
>   at 
> com.alcatel.grizzly.synapse.custom.WsgSynapseEnvironment.send(WsgSynapseEnvironment.java:34)
>   at 
> org.apache.synapse.endpoints.AddressEndpoint.send(AddressEndpoint.java:195)
>   at 
> com.alcatel.grizzly.synapse.custom.WsgAddressEndpoint.send(WsgAddressEndpoint.java:68)
>   at 
> org.apache.synapse.mediators.builtin.SendMediator.mediate(SendMediator.java:157)
>   at 
> org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:58)
>   at 
> org.apache.synapse.mediators.base.SequenceMediator.mediate(SequenceMediator.java:125)
>   at 
> org.apache.synapse.core.axis2.ProxyServiceMessageReceiver.receive(ProxyServiceMessageReceiver.java:158)
>   at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:176)
>   at 
> org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275)
>   at 
> org.apache.synapse.transport.nhttp.ServerWorker.processPost(ServerWorker.java:238)
>   at 
> org.apache.synapse.transport.nhttp.ServerWorker.run(ServerWorker.java:194)
>   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown 
> Source)
>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>   at java.lang.Thread.run(Unknown Source)
> This can occur in a situation similar to that in SYNAPSE-341 (remote WS 
> returns its response before the request is fully written).  It's due to a 
> race condition when reusing a connection between a client I/O dispatcher 
> thread calling NHttpClientConnection.resetOutput() when the request writing 
> is complete and an HttpServerWorker thread calling 
> NHttpClientConnection.submitRequest() on the same pooled connection after it 
> has been released when the response reading is complete.

-- 
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-344) Race condition on connection reuse causes 'Request already submitted' exception

[Jake Lambert (JIRA)]

Race condition on connection reuse causes 'Request already submitted' exception
---

 Key: SYNAPSE-344
 URL: https://issues.apache.org/jira/browse/SYNAPSE-344
 Project: Synapse
  Issue Type: Bug
  Components: Transports
Affects Versions: 1.1.1
 Environment: All environments
Reporter: Jake Lambert
Priority: Critical


When using a proxy service and HTTP-NIO with a moderate number of concurrent 
requests some requests fail with the following error:

HttpServerWorker-25: Unexpected HTTP protocol error: Request already submitted
org.apache.http.HttpException: Request already submitted
at 
org.apache.http.impl.nio.DefaultNHttpClientConnection.submitRequest(DefaultNHttpClientConnection.java:203)
at 
org.apache.synapse.transport.nhttp.ClientHandler.submitRequest(ClientHandler.java:142)
at 
org.apache.synapse.transport.nhttp.HttpCoreNIOSender.sendAsyncRequest(HttpCoreNIOSender.java:340)
at 
org.apache.synapse.transport.nhttp.HttpCoreNIOSender.invoke(HttpCoreNIOSender.java:256)
at 
com.alcatel.grizzly.mw.transport.WSGHttpTransportSender.invoke(WSGHttpTransportSender.java:171)
at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:448)
at 
org.apache.synapse.core.axis2.DynamicAxisOperation$DynamicOperationClient.send(DynamicAxisOperation.java:190)
at 
org.apache.synapse.core.axis2.DynamicAxisOperation$DynamicOperationClient.executeImpl(DynamicAxisOperation.java:174)
at 
org.apache.axis2.client.OperationClient.execute(OperationClient.java:163)
at 
com.alcatel.grizzly.synapse.custom.WsgFlexibleMEPClient.send(WsgFlexibleMEPClient.java:284)
at 
com.alcatel.grizzly.synapse.custom.WsgSynapseEnvironment.send(WsgSynapseEnvironment.java:34)
at 
org.apache.synapse.endpoints.AddressEndpoint.send(AddressEndpoint.java:195)
at 
com.alcatel.grizzly.synapse.custom.WsgAddressEndpoint.send(WsgAddressEndpoint.java:68)
at 
org.apache.synapse.mediators.builtin.SendMediator.mediate(SendMediator.java:157)
at 
org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:58)
at 
org.apache.synapse.mediators.base.SequenceMediator.mediate(SequenceMediator.java:125)
at 
org.apache.synapse.core.axis2.ProxyServiceMessageReceiver.receive(ProxyServiceMessageReceiver.java:158)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:176)
at 
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275)
at 
org.apache.synapse.transport.nhttp.ServerWorker.processPost(ServerWorker.java:238)
at 
org.apache.synapse.transport.nhttp.ServerWorker.run(ServerWorker.java:194)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown 
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

This can occur in a situation similar to that in SYNAPSE-341 (remote WS returns 
its response before the request is fully written).  It's due to a race 
condition when reusing a connection between a client I/O dispatcher thread 
calling NHttpClientConnection.resetOutput() when the request writing is 
complete and an HttpServerWorker thread calling 
NHttpClientConnection.submitRequest() on the same pooled connection after it 
has been released when the response reading is complete.

-- 
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-341) System unstable when HTTP response returned before request fully written

[Jake Lambert (JIRA)]

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

Jake Lambert commented on SYNAPSE-341:
--

No: see attached file for proxy service's client-side request and response.

> System unstable when HTTP response returned before request fully written
> 
>
> Key: SYNAPSE-341
> URL: https://issues.apache.org/jira/browse/SYNAPSE-341
> Project: Synapse
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 1.2-beta1
> Environment: All environments
>Reporter: Jake Lambert
>Assignee: Asankha C. Perera
>Priority: Critical
> Fix For: 1.3
>
> Attachments: ClientSideReqResp.txt
>
>
> When using a proxy service and HTTP-NIO the following error is repeatedly 
> generated when a remote WS returns its response before the request is fully 
> written (i.e. when AXIOM is being used by the target service to parse the 
> request XML and the request includes unprocessed attachment(s) or a fault 
> occurs before fully reading the request):
> I/O dispatcher 12: System may be unstable: IOReactor encountered a runtime 
> exception : null
> java.lang.NullPointerException
>   at 
> org.apache.synapse.transport.nhttp.ClientHandler.outputReady(ClientHandler.java:353)
>   at 
> org.apache.http.impl.nio.DefaultNHttpClientConnection.produceOutput(DefaultNHttpClientConnection.java:170)
>   at 
> org.apache.http.impl.nio.DefaultClientIOEventDispatch.outputReady(DefaultClientIOEventDispatch.java:105)
>   at 
> org.apache.http.impl.nio.reactor.BaseIOReactor.writable(BaseIOReactor.java:114)
>   at 
> org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:198)
>   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)
>   at java.lang.Thread.run(Unknown Source)
> The actual cause is the ConnectionPool 'cleanConnectionReferences()' method, 
> which clears the REQUEST_SOURCE_BUFFER upon completion of the response HTTP 
> decoding, rather than on completion of both the request AND response 
> processing.

-- 
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-341) System unstable when HTTP response returned before request fully written

[Jake Lambert (JIRA)]

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

Jake Lambert updated SYNAPSE-341:
-

Attachment: ClientSideReqResp.txt

> System unstable when HTTP response returned before request fully written
> 
>
> Key: SYNAPSE-341
> URL: https://issues.apache.org/jira/browse/SYNAPSE-341
> Project: Synapse
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 1.2-beta1
> Environment: All environments
>Reporter: Jake Lambert
>Assignee: Asankha C. Perera
>Priority: Critical
> Fix For: 1.3
>
> Attachments: ClientSideReqResp.txt
>
>
> When using a proxy service and HTTP-NIO the following error is repeatedly 
> generated when a remote WS returns its response before the request is fully 
> written (i.e. when AXIOM is being used by the target service to parse the 
> request XML and the request includes unprocessed attachment(s) or a fault 
> occurs before fully reading the request):
> I/O dispatcher 12: System may be unstable: IOReactor encountered a runtime 
> exception : null
> java.lang.NullPointerException
>   at 
> org.apache.synapse.transport.nhttp.ClientHandler.outputReady(ClientHandler.java:353)
>   at 
> org.apache.http.impl.nio.DefaultNHttpClientConnection.produceOutput(DefaultNHttpClientConnection.java:170)
>   at 
> org.apache.http.impl.nio.DefaultClientIOEventDispatch.outputReady(DefaultClientIOEventDispatch.java:105)
>   at 
> org.apache.http.impl.nio.reactor.BaseIOReactor.writable(BaseIOReactor.java:114)
>   at 
> org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:198)
>   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)
>   at java.lang.Thread.run(Unknown Source)
> The actual cause is the ConnectionPool 'cleanConnectionReferences()' method, 
> which clears the REQUEST_SOURCE_BUFFER upon completion of the response HTTP 
> decoding, rather than on completion of both the request AND response 
> processing.

-- 
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-343) Propose a way to handle messages that are received after the first message is processed through the onComplete method of the Aggregate mediator

[Evanthika Amarasiri (JIRA)]

Propose a way to handle messages that are received after the first message is 
processed through the onComplete method of the Aggregate mediator
---

 Key: SYNAPSE-343
 URL: https://issues.apache.org/jira/browse/SYNAPSE-343
 Project: Synapse
  Issue Type: Improvement
Affects Versions: 1.2-beta1
 Environment: Ubuntu7.10, JDK1.5.0_14
Reporter: Evanthika Amarasiri
Assignee: Ruwan Linton
Priority: Minor


Once the first message is being processed by the onComplete method of the 
Aggregate mediator there should be some other way to handle the rest of the 
messages that flows through following the first message

-- 
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: [VOTE] Release Synapse-1.2

[Ruwan Linton]

With thousand apologies I call this vote off and will cut this again after
figuring solving the problem described in the above mail, soon.

Thansks,
Rwuan

On Wed, Jun 4, 2008 at 3:01 PM, Evanthika Amarasiri <[EMAIL PROTECTED]>
wrote:

> Hi,
>
> I came across an issue when deploying the SecureStockQuote Service and then
> later found out that I cannot proceed with the security scenarios in this
> release due to a wrong jar being included in the release.
>
> Thanks,
> Evanthika
>
>
> Ruwan Linton wrote:
>
>> Hi Devs,
>>
>> This is a call for votes to release Synapse-1.2.
>>
>> Please review the signed artifacts:
>> http://people.apache.org/~ruwan/synapse/1.2/dist/<
>> http://people.apache.org/%7Eruwan/synapse/1.2/dist/>
>>
>> The m2 repository is available at:
>> http://people.apache.org/~ruwan/synapse/1.2/maven-repo/<
>> http://people.apache.org/%7Eruwan/synapse/1.2/maven-repo/>
>>
>> SVN Info:
>> revision is 663011 on
>> https://svn.apache.org/repos/asf/synapse/branches/1.2
>>
>> Here's my +1 to declaring the above dist as Synapse-1.2.
>>
>> Thanks,
>> Ruwan
>>
>> --
>> Ruwan Linton
>> http://www.wso2.org - "Oxygenating the Web Services Platform"
>>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
Ruwan Linton
http://www.wso2.org - "Oxygenating the Web Services Platform"

Re: [VOTE] Release Synapse-1.2

[Evanthika Amarasiri]

Hi,

I came across an issue when deploying the SecureStockQuote Service and 
then later found out that I cannot proceed with the security scenarios 
in this release due to a wrong jar being included in the release.


Thanks,
Evanthika


Ruwan Linton wrote:

Hi Devs,

This is a call for votes to release Synapse-1.2.

Please review the signed artifacts:
http://people.apache.org/~ruwan/synapse/1.2/dist/ 



The m2 repository is available at:
http://people.apache.org/~ruwan/synapse/1.2/maven-repo/ 



SVN Info:
revision is 663011 on
https://svn.apache.org/repos/asf/synapse/branches/1.2

Here's my +1 to declaring the above dist as Synapse-1.2.

Thanks,
Ruwan

--
Ruwan Linton
http://www.wso2.org - "Oxygenating the Web Services Platform" 



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

[VOTE] Release Synapse-1.2

[Ruwan Linton]

Hi Devs,

This is a call for votes to release Synapse-1.2.

Please review the signed artifacts:
http://people.apache.org/~ruwan/synapse/1.2/dist/

The m2 repository is available at:
http://people.apache.org/~ruwan/synapse/1.2/maven-repo/

SVN Info:
revision is 663011 on
https://svn.apache.org/repos/asf/synapse/branches/1.2

Here's my +1 to declaring the above dist as Synapse-1.2.

Thanks,
Ruwan

-- 
Ruwan Linton
http://www.wso2.org - "Oxygenating the Web Services Platform"

synapse JMSListener fails if services.xml doesn't specify transport.jms.Destination

[Suran Jayathilaka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

hi,

When testing the JMS transport with a QPid broker, I found this problem.
When I use the JMS transport in Axis2 (1.4), if a destination isn't 
given as the paramater "transport.jms.Destination" in the services.xml, 
it would create a Queue by the service name and work correctly. When 
this parameter is avaialable also the Axis2 JMS transport works without 
errors.


But when I switched to the JMS transport from the 
synapse-transports-.jar, if the above named parameter isn't 
included in the service descriptor, the JMSListener  fails saying

[ERROR] The service cannot be found for the endpoint reference (EPR)
org.apache.axis2.AxisFault: The service cannot be found for the endpoint 
reference (EPR)
~at 
org.apache.axis2.engine.DispatchPhase.checkPostConditions(DispatchPhase.java:64)

~at org.apache.axis2.engine.Phase.invoke(Phase.java:333)
~at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:264)
~at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:163)
~at 
org.apache.synapse.transport.base.AbstractTransportListener.handleIncomingMessage(AbstractTransportListener.java:256)
~at 
org.apache.synapse.transport.jms.JMSMessageReceiver$Worker.run(JMSMessageReceiver.java:218)
~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)

And as soon as I add the "transport.jms.Destination" param to the 
services.xml, the the synapse JMSListener would also work.


Shouldn't the transport be able to work with the auto created Queue 
without needing the parameter explicitly?
I tested this scenario with both synapse-transports-1.1.1.jar and 
synapse-transports-1.2-beta1.jar with similar results.

Please let me know if I might be doing something incorrectly.

The services.xml is
- 
targetNamespace="http://axis2qpid.wso2.org";>

~
~Stock Quote Service Over AMQP
~
~
~http://www.w3.org/2004/08/wsdl/in-only";
~ 
class="org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver"/>

~http://www.w3.org/2004/08/wsdl/in-out";
~ 
class="org.apache.axis2.rpc.receivers.RPCMessageReceiver"/>

~
~name="ServiceClass">org.wso2.example.axis2qpid.service.QpidStockQuoteService

~directQueue

- ---

directQueue refers to a destination  binding in a jndi properties file.
- 
#initial context factory
#java.naming.factory.initial 
=org.apache.qpid.jndi.PropertiesFileInitialContextFactory

# register some connection factories
# connectionfactory.[jndiname] = [ConnectionURL]
connectionfactory.qpidConnectionfactory=amqp://guest:[EMAIL 
PROTECTED]/test?brokerlist='tcp://localhost:5672'
# Register an AMQP destination in JNDI
# destination.[jndiName] = [BindingURL]
destination.directQueue=direct://amq.direct//QpidStockQuoteService
- ---

Thanks.
Suran


- --
U. Suran Jayathilaka
WSO2, Inc. - http://www.wso2.com

http://suranjay.blogspot.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIRkG2Xkt94l6LfXURAhEDAJ49i4qZNupb0sUbZwXYAmJzJSSeYgCgg1qu
EP+J3NcsTP3HFa4lcl6UQo4=
=BEQz
-END PGP SIGNATURE-


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