[JBoss JIRA] (SECURITY-876) Web initiated logout doesn't clear authenticated identity in EJB
by Arjan t (JIRA)
[ https://issues.jboss.org/browse/SECURITY-876?page=com.atlassian.jira.plug... ]
Arjan t commented on SECURITY-876:
----------------------------------
After some more experimenting with this, the following handler seems to do the trick as a workaround, but it's a bit nasty to require this of course. It now uses the hardcoded "other" domain.
{code:java}
public final class AuthEventHandler implements HttpHandler {
private static final Logger log = Logger.getLogger(AuthEventHandler.class);
private final HttpHandler next;
public AuthEventHandler(final HttpHandler next) {
this.next = next;
}
@Override
public void handleRequest(HttpServerExchange exchange) throws Exception {
exchange.getSecurityContext().registerNotificationReceiver(new SecurityNotificationReceiver(exchange));
next.handleRequest(exchange);
}
private static class SecurityNotificationReceiver implements NotificationReceiver {
private final HttpServerExchange exchange;
public SecurityNotificationReceiver(HttpServerExchange exchange) {
this.exchange = exchange;
}
@Override
public void handleNotification(final SecurityNotification notification) {
switch (notification.getEventType()) {
case LOGGED_OUT:
try {
// For for when calling request#logout, the authenticated identity is still available for the
// EJB context
// Clear old one
SecurityContextAssociation.clearSecurityContext();
SecurityRolesAssociation.setSecurityRoles(null);
// Set a new one in case re-authentication is done within the same thread
SecurityContext securityContext = SecurityContextFactory.createSecurityContext("other");
if (exchange != null) {
exchange.putAttachment(SECURITY_CONTEXT_ATTACHMENT, securityContext);
}
SecurityContextAssociation.setSecurityContext(securityContext);
} catch (Exception e) {
log.error("Could not clear EJB security context", e);
}
break;
default:
break;
}
}
}
}
{code}
> Web initiated logout doesn't clear authenticated identity in EJB
> ----------------------------------------------------------------
>
> Key: SECURITY-876
> URL: https://issues.jboss.org/browse/SECURITY-876
> Project: PicketBox
> Issue Type: Bug
> Reporter: Arjan t
> Assignee: Stefan Guilhen
> Labels: authentication, ejb, jaspi, jaspic, security, security-context
>
> After having authenticated via JASPIC, calling {{HttpServletRequest#logout}} and then requesting the caller/user principal (all within the same request), WildFly 8.2 will correctly clear out the principal for the web context, but will NOT clear out the principal for the EJB context.
> Cross-checking with the RI (GlassFish 4.0/4.1) reveals that there the EJB context is indeed cleared out.
> As a workaround, calling the following code after logout (e.g. in an Undertow event handler for SecurityNotifications) will clear the EJB context, but this code should of course not be needed to be called by user apps:
> {code:java}
> SecurityContextAssociation.clearSecurityContext();
> SecurityRolesAssociation.setSecurityRoles(null);
> {code}
> A reproducer for this issue is available at: https://github.com/arjantijms/javaee7-samples/blob/master/jaspic/ejb-prop...
> For WildFly 8.2 this will print:
> {noformat}
> web username: test
> EJB username: test
> web username after logout: null
> EJB username after logout: test
> {noformat}
> For GlassFish 4.0/4.1 this will print:
> {noformat}
> web username: test
> EJB username: test
> web username after logout: null
> EJB username after logout: ANONYMOUS
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4214) Update Maven to latest version 3.2.5
by Carlo de Wolf (JIRA)
[ https://issues.jboss.org/browse/WFLY-4214?page=com.atlassian.jira.plugin.... ]
Carlo de Wolf updated WFLY-4214:
--------------------------------
Summary: Update Maven to latest version 3.2.5 (was: Update Maven to latest version 2.3.5)
> Update Maven to latest version 3.2.5
> ------------------------------------
>
> Key: WFLY-4214
> URL: https://issues.jboss.org/browse/WFLY-4214
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Build System
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
> Fix For: 9.0.0.Beta1
>
>
> {code}
> [tom@TOM-PC jboss-as](WFLY-4175)(11:08:43) $ ./tools/download-maven.sh
> % Total % Received % Xferd Average Speed Time Time Time Current
> Dload Upload Total Spent Left Speed
> 100 258 100 258 0 0 973 0 --:--:-- --:--:-- --:--:-- 973
> Archive: maven.zip
> End-of-central-directory signature not found. Either this file is not
> a zipfile, or it constitutes one disk of a multi-part archive. In the
> latter case the central directory and zipfile comment will be found on
> the last disk(s) of this archive.
> unzip: cannot find zipfile directory in maven.zip,
> and cannot find maven.zip.zip, period.
> mv: cannot stat `apache-maven*': No such file or directory
> {code}
> http://www.apache.org/dist/maven/maven-3/3.2.3/binaries/apache-maven-3.2.... is gone, it is now 3.2.5.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4421) Failing EJBClientClusterConfigurationTestCase.testServerToServerClusterFormation on windows
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4421?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar edited comment on WFLY-4421 at 3/12/15 6:25 AM:
------------------------------------------------------------
according to https://github.com/belaban/JGroups/wiki/FAQ we should probably add sys proper for selecting tcp stack
was (Author: ctomc):
according to https://github.com/belaban/JGroups/wiki/FAQ we should probably for tcp stack
> Failing EJBClientClusterConfigurationTestCase.testServerToServerClusterFormation on windows
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-4421
> URL: https://issues.jboss.org/browse/WFLY-4421
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 9.0.0.Alpha1
> Environment: Windows builds on brontes
> Reporter: Tomaz Cerar
> Assignee: Paul Ferraro
> Priority: Critical
>
> this is in logs:
> {noformat}
> 23:59:49,456 SEVERE [org.jgroups.protocols.UDP] (MSC service thread 1-2) failed setting ip_ttl: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at org.jgroups.protocols.UDP.setTimeToLive(UDP.java:339)
> at org.jgroups.protocols.UDP.createSockets(UDP.java:368)
> at org.jgroups.protocols.UDP.start(UDP.java:270)
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965)
> at org.jgroups.JChannel.startStack(JChannel.java:891)
> at org.jgroups.JChannel._preConnect(JChannel.java:553)
> at org.jgroups.JChannel.connect(JChannel.java:288)
> at org.jgroups.JChannel.connect(JChannel.java:279)
> at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:87)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.IOException: Method not implemented!
> at java.net.DualStackPlainDatagramSocketImpl.setTimeToLive(DualStackPlainDatagramSocketImpl.java:236)
> ... 18 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JGRP-1907) ENCRYPT: asymmetric encryption fails on merge
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1907?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1907:
-----------------------------------------------
Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1187193|https://bugzilla.redhat.com/show_bug.cgi?id=1187193] from ON_QA to VERIFIED
> ENCRYPT: asymmetric encryption fails on merge
> ---------------------------------------------
>
> Key: JGRP-1907
> URL: https://issues.jboss.org/browse/JGRP-1907
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.2
>
> Attachments: encrypt.xml, EncryptKeyStore.xml
>
>
> {{ENCRYPT}} fails to communicate after a network split and subsequent merge with asymmetric encryption. This works with symmetric encryption.
> To reproduce:
> * Members A and B
> * Add {{<DISCARD use_gui="true"/>}} on top of {{UDP}}
> * Form cluster {{(A,B)}}
> * Create a network split: {{(A)}} and {{(B)}}
> * Remove the network split
> * Observe that with both symmetric and asymmetric encryption, the merge forms cluster {{(A,B)}}
> * However, with asymmetric encryption, {{ENCRYPT}} fails to process any messages and rejects all messages, whereas with symmetric encryption, this works.
> * Symmetric encryption: {{EncryptKeyStore.xml}}
> * Asymmetric encryption: {{encrypt.xml}}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-2455) Cannot configure the list of recovery modules due to ArjunaRecoveryManagerService hardcoding them
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-2455?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on WFLY-2455:
-------------------------------------
HornetQ is registered for recovery. We will tackle this as an enhancement.
> Cannot configure the list of recovery modules due to ArjunaRecoveryManagerService hardcoding them
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-2455
> URL: https://issues.jboss.org/browse/WFLY-2455
> Project: WildFly
> Issue Type: Enhancement
> Components: Transactions
> Affects Versions: 8.0.0.Beta1
> Reporter: Koen Janssens
> Assignee: Amos Feng
>
> Using a custom jbossts-properties.xml file defined via the com.arjuna.ats.arjuna.common.propertiesFile systemsetting, i can register a custom recovery manager for arjuna.
> However, the ArjunaRecoveryManagerService class overwrite the recovery configuration mentioned in my jbossts-properties.xml file with a hardcoded list of recovery modules.
> This makes me wonder if/how the hornetq recovery (org.hornetq.jms.server.recovery.HornetQXAResourceRecover) gets registered in wildfly..
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JGRP-1920) FC: Flag NO_FC is not applied on RPC calls/responses
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1920?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1920:
--------------------------------
Can you give more details ? Looking at {{MessageDispatcher.cast()}}, the flags of {{RequestOptions}} are actually copied into the request message:
{noformat}
protected <T> GroupRequest<T> cast(final Collection<Address> dests, Message msg, RequestOptions options,
boolean block_for_results, FutureListener<RspList<T>> listener) throws Exception {
if(options != null) {
msg.setFlag(options.getFlags()).setTransientFlag(options.getTransientFlags());
if(options.getScope() > 0)
msg.setScope(options.getScope());
}
...
{noformat}
Also, in {{RequestCorrelator.sendReply()}}, the flags of the request message are copied into the response message:
{noformat}
Message rsp=req.makeReply().setFlag(req.getFlags()).clearFlag(Message.Flag.RSVP, Message.Flag.SCOPED);
{noformat}
> FC: Flag NO_FC is not applied on RPC calls/responses
> ----------------------------------------------------
>
> Key: JGRP-1920
> URL: https://issues.jboss.org/browse/JGRP-1920
> Project: JGroups
> Issue Type: Bug
> Reporter: Karim AMMOUS
> Assignee: Bela Ban
> Fix For: 3.6.3
>
>
> When we set Flag.NO_FC on an RPC call through "RequestOptions", we expect that both request and response will be not rate limited.
> Currently, both request and response could be slow down by flow control protocols.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JGRP-1910) MERGE3: Do not lose any members from view during a series of merges
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/JGRP-1910?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on JGRP-1910:
-----------------------------------
The ultimate goal is to 'not lose any members from view during a series of merges', as JIRA title suggests, unless you get suspection from FD protocol. So, if the messages can be lost/delayed, any algorithm that would base the view on a subset of responses from the nodes (because we don't want to block for all responses and implement guaranteed delivery) can lose some nodes in the new merge view. If a view that is sent to a node is automatically installed there, you can't avoid the situation with two concurrent merge views installed one after another, each missing particular members.
Therefore, the node has to reject some views, and I've suggested the criteria above.
> MERGE3: Do not lose any members from view during a series of merges
> -------------------------------------------------------------------
>
> Key: JGRP-1910
> URL: https://issues.jboss.org/browse/JGRP-1910
> Project: JGroups
> Issue Type: Bug
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.6.3
>
> Attachments: SplitMergeFailFastTest.java, SplitMergeTest.java
>
>
> When connection between nodes is re-established, MERGE3 should merge the cluster together. This often does not involve a single MergeView but a series of such events. The problematic property of this protocol is that some of those views can lack certain members, though these are reachable.
> This causes problem in Infinispan since the cache cannot be fully rebalanced before another merge arrives, and all owners of certain segment can be gradually removed (and added again) to the view, while this is not detected as partition but crashed nodes -> losing all owners means data loss.
> Removing members from view should be the role of FDx protocols, not MERGEx.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JGRP-1910) MERGE3: Do not lose any members from view during a series of merges
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1910?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1910:
--------------------------------
Oops, the above algorithm doesn't work, e.g. in {{OverlappingMergeTest.testMergeWithDifferentPartitions()}}:
{noformat}
A: {A,C,B}
B: {A,C,B}
C: {A,C,B}
D: {B,A,C,D}
{noformat}
With the new algorithm, potential merge leaders are A and B. If we now sort \[A,B\] and B happens to be first, B will be the merge leader and A won't do anything. However, *B will neither ever become coordinator nor leave, so the merge will never get started !*
We therefore have to revert the new algorithm; merge leaders are always picked from actual senders of view-ids (that are view creators). In the above example, only A would be selected as potential merge leader.
> MERGE3: Do not lose any members from view during a series of merges
> -------------------------------------------------------------------
>
> Key: JGRP-1910
> URL: https://issues.jboss.org/browse/JGRP-1910
> Project: JGroups
> Issue Type: Bug
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.6.3
>
> Attachments: SplitMergeFailFastTest.java, SplitMergeTest.java
>
>
> When connection between nodes is re-established, MERGE3 should merge the cluster together. This often does not involve a single MergeView but a series of such events. The problematic property of this protocol is that some of those views can lack certain members, though these are reachable.
> This causes problem in Infinispan since the cache cannot be fully rebalanced before another merge arrives, and all owners of certain segment can be gradually removed (and added again) to the view, while this is not detected as partition but crashed nodes -> losing all owners means data loss.
> Removing members from view should be the role of FDx protocols, not MERGEx.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4413) Network connection leak in asynchronous servlet
by jeremy_lv lv (JIRA)
[ https://issues.jboss.org/browse/WFLY-4413?page=com.atlassian.jira.plugin.... ]
jeremy_lv lv commented on WFLY-4413:
------------------------------------
Hi, [~swd847]:
{quote}
I just tried this out and the connection hangs around for 30s until the default async timeout is hit, then it goes away as expected. I tested against both 8.2.0.Final and the most recent upstream and the behaviour was the same.
The behaviour is basically the expected behaviour, because nothing catches the IOException thrown on flush the request basically hangs around doing nothing until the async timeout is hit. I could potentially forcibly kill the underling connection if a write fails, but either way the request object will be hanging around until the timeout.
{quote}
As you said, if we haven't add ctx.complete after invoking ctx.getResponse().getOutputStream().flush(), the connection hangs around for 30s until the default async timeout is hit, then it goes away as expected.
However, if we add ctx.complete after invoking ctx.getResponse().getOutputStream().flush(), the IOException will thrown during invoking the ctx.complete.
Here's the stacktrace as follows:
{panel:title=Stacktrace|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#FFFFCE}
Exception in thread "default task-35" java.lang.RuntimeException: java.io.IOException: Broken pipe
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:527)
at io.undertow.servlet.spec.AsyncContextImpl$3.run(AsyncContextImpl.java:295)
at io.undertow.servlet.spec.AsyncContextImpl$6.run(AsyncContextImpl.java:433)
at io.undertow.servlet.spec.AsyncContextImpl$TaskDispatchRunnable.run(AsyncContextImpl.java:518)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
Caused by: java.io.IOException: Broken pipe
at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:94)
at sun.nio.ch.IOUtil.write(IOUtil.java:65)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:466)
at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150)
at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:531)
at io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:256)
at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:100)
at org.xnio.channels.Channels.flushBlocking(Channels.java:63)
at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:625)
at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:451)
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:525)
{panel}
Finally, the current socket connection in JVM will keep in alive because of the above thrown exception. We did investigate the above stacktrace and found the IOException will thrown by HttpResponseConduit.write before close the socket connection in JVM. in the other words, there's no operation in undertow to close the socket connection in JVM if the IOException were thrown by HttpResponseConduit.write.
Thanks.
> Network connection leak in asynchronous servlet
> -----------------------------------------------
>
> Key: WFLY-4413
> URL: https://issues.jboss.org/browse/WFLY-4413
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Environment: Linux
> Reporter: jeremy_lv lv
> Assignee: Stuart Douglas
> Priority: Blocker
> Labels: undertow
>
> {panel:title=Phenomenon|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#FFFFCE}
> When the connection is suddenly terminated during the period we access the asynchronous servlet application, the connection will be leaked. However, the connection won't be leak when we access the synchronous servlet application.
> {panel}
> *Some of the stacktrace are as follows:*
> {panel:title=Stacktrace|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#FFFFCE}
> 14:34:23,751 ERROR [io.undertow.request] (default task-22) Blocking request fail
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpSer
> at io.undertow.servlet.spec.AsyncContextImpl$3.run(AsyncContextImpl.java
> at io.undertow.servlet.spec.AsyncContextImpl$6.run(AsyncContextImpl.java
> at io.undertow.servlet.spec.AsyncContextImpl$TaskDispatchRunnable.run(As
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.io.IOException: Connection reset by peer
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method) [rt.jar:1.7.0_25]
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) [rt.jar:1
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:94) [rt.jar:1.7.0
> at sun.nio.ch.IOUtil.write(IOUtil.java:51) [rt.jar:1.7.0_25]
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:466) [rt.ja
> at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150)
> at io.undertow.server.protocol.http.HttpResponseConduit.processWrite(Htt
> at io.undertow.server.protocol.http.HttpResponseConduit.flush(HttpRespon
> at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.flush(Abstr
> at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkCha
> at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStre
> at org.xnio.channels.Channels.flushBlocking(Channels.java:63)
> at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputS
> at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpSer
> ... 6 more
> {panel}
> *Here's the test war code you can used to reproduce this phenomenon:*
> {code:title=AsyncDemoServlet.java|borderStyle=solid}
> import java.io.IOException;
> import javax.servlet.AsyncContext;
> import javax.servlet.ServletException;
> import javax.servlet.annotation.WebServlet;
> import javax.servlet.http.HttpServlet;
> import javax.servlet.http.HttpServletRequest;
> import javax.servlet.http.HttpServletResponse;
> @WebServlet(urlPatterns="/asyncDemoServlet",asyncSupported=true)
> public class AsyncDemoServlet extends HttpServlet {
> private static final long serialVersionUID = 1L;
> protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
> response.setContentType("text/html;charset=UTF-8");
> //Execute the business logic in sub-thread.
> AsyncContext ctx = request.startAsync();
> new Thread(new Executor(ctx)).start();
> }
> protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
> doGet(request, response);
> }
> public class Executor implements Runnable {
> private AsyncContext ctx = null;
> public Executor(AsyncContext ctx){
> this.ctx = ctx;
> }
> public void run(){
> try {
> ctx.getResponse().getOutputStream().write("aaa".getBytes());
> //wait for 5 seconds to simulate the business logic.
> Thread.sleep(5000);
> ctx.getResponse().getOutputStream().flush();
> ctx.complete();
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months