Realtime Client Server Framework for the JVM, supporting WebSockets with Cross-Browser Fallbacks

Last update: Jan 3, 2023

Overview

Welcome to Atmosphere: The Event Driven Framework supporting WebSocket and HTTP

The Atmosphere Framework contains client and server side components for building Asynchronous Web Applications. Atmosphere transparently supports WebSockets, Server Sent Events (SSE), Long-Polling, HTTP Streaming (Forever frame) and JSONP.

The Atmosphere Framework Stack consists of:

The Atmosphere Framework Stack works on all Servlet based servers, Spring Boot and frameworks like Netty, Play! Framework and Vert.x. We support a variety of extensions like Apache Kafka, Hazelcast, RabbitMQ, Redis and many more.

Atmosphere's Java/Scala/Android Client is called wAsync.

Main development branch is atmosphere-2.6.x Only pull request for that branch will be accepted.

Commercial support

Commercial Support is available via Async-IO.org

To use Atmosphere, add the following dependency:

     <dependency>
         <groupId>org.atmosphere</groupId>
         <artifactId>atmosphere-{atmosphere-module}</artifactId>
         <version>2.6.4</version>
      </dependency>

atmosphere-module can be: runtime (main module), jersey, spring, kafka, guice, redis, hazelcast, jms, rabbitmq, jgroups etc. Our official releases are available from Maven Central download.

Tutorial

Get started using this step by step tutorial.

Official Documentation

Easiest way to learn Atmosphere is by trying a sample.

Our Wiki contains several tutorials for getting started as well as FAQ. You can also browse the framework's Javadoc for Server Components, and atmosphere.js for Client Components.

Quick Start

The Atmosphere Framework ships with many examples describing how to implement WebSockets, Server-Sent Events, Long-Polling, HTTP Streaming and JSONP client applications. Take a look at this page to pick the best sample to start with.

Jump directly inside the code: WebSockets, Server-Sent Events (SSE), Long-Polling, JSONP and HTTP Streaming!

Take a look at the PubSub Client-Server or the infamous Chat Client-Server to realize how simple Atmosphere is!

Top

If you are interested, subscribe to our mailing list for more info!.

Top Z

Atmosphere and JDK Versions

Atmosphere 2.5.x requires JDK 8 or 11. Atmosphere 2.4.x requires JDK 1.7 or newer

Versions

2.6.x release: 2.6.4 2.6.1 2.6.0

End Of Life Versions (go to http://async-io.org for commercial support)

2.5.x release: 2.5.14 2.5.9 2.5.5 2.5.3 2.5.2 2.5.0

2.4.x release: 2.4.32 2.4.30 2.4.29 2.4.27 2.4.26 2.4.24 2.4.23 2.4.22 2.4.19 2.4.18 2.4.17 2.4.16 2.4.13 2.4.12 2.4.11 2.4.9 2.4.8 2.4.7 2.4.6 2.4.5 2.4.4 2.4.3 2.4.2 2.4.1 2.4.0

2.3.x release: 2.3.10 2.3.8 2.3.7 2.3.6 2.3.5 2.3.4 2.3.3 2.3.2 2.3.1 2.3.0

2.2.x release: 2.2.13 2.2.10 2.2.9 2.2.8 2.2.7 2.2.6 2.2.5 2.2.4 2.2.3 2.2.2 2.2.1 2.2.0

2.1.x release: 2.1.14 2.1.12 2.1.11 2.1.10 2.1.9 2.1.8 2.1.7 2.1.6 2.1.5 2.1.4 2.1.2 2.1.1 2.1.0

2.0.x release: 2.0.12 2.0.11 2.0.10 2.0.9 2.0.8 2.0.7 2.0.6 2.0.5 2.0.4 2.0.3 [2.0.2] (http://goo.gl/44qnsU) 2.0.1

1.0 release: 1.0.21 1.0.17 1.0.16 1.0.14 1.0.13 1.0.11 1.0.10 1.0.8 1.0.6 1.0.5 1.0.4 1.0.3 1.0.2 1.0.1 1.0

Top

Build Status

Comments

Critical memory leak

I would like to report a memory leak with Atmosphere.

I'm using Atmosphere with Primefaces, version 1.1.0.beta1 (the problem occurs with 1.0.4 too).

After some minutes, the JVM will get out of memory with the following code:

import org.primefaces.push.PushContext;
import org.primefaces.push.PushContextFactory;
import org.springframework.context.annotation.Scope;

import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import javax.inject.Named;
import java.util.Timer;
import java.util.TimerTask;

@Named
@Scope("application")
public class Publisher {

    private Timer ordersTimer;

    private StringBuilder sb = new StringBuilder();

    public Publisher() {
        ordersTimer = new Timer("orders-timer", false);
        for (int i = 0; i < 100000; i++) {
            sb.append("0123456789");
        }
    }

    @PreDestroy
    public void destroy() {
        ordersTimer.cancel();
    }

    @PostConstruct
    public void init() {

        final PushContext ctx = PushContextFactory.getDefault().getPushContext();

        ordersTimer.scheduleAtFixedRate(new TimerTask() {
            @Override
            public void run() {
                try {
                    ctx.push("aChannel", sb.toString());

                } catch (Exception e) {
                    System.err.println("Error on publishing.");
                }
            }
        }, 0L, 1000L);

    }

}

I've configured Atmosphere as:

<init-param>
            <param-name>org.atmosphere.cpr.broadcasterClass</param-name>
            <param-value>org.atmosphere.util.SimpleBroadcaster</param-value>
        </init-param>
        <init-param>
            <param-name>org.atmosphere.cpr.broadcaster.shareableThreadPool</param-name>
            <param-value>true</param-value>
        </init-param>
        <init-param>
            <param-name>org.atmosphere.cpr.broadcasterLifeCyclePolicy</param-name>
            <param-value>IDLE_DESTROY</param-value>
        </init-param>
        <init-param>
            <param-name>org.atmosphere.cpr.AtmosphereInterceptor.disableDefaults</param-name>
            <param-value>true</param-value>
        </init-param>

not a bug Will not Fix

opened by averri 72

[GlassFish] Atmosphere interrupts writer thread even if it didn't complete writing data to a client

I'm running primefaces counter example on Glassfish 3.1.2.2. This guy:

"Atmosphere-AsyncWrite-9" daemon prio=10 tid=0xc7f10400 nid=0x17a1 at breakpoint[0xc4fb7000]
   java.lang.Thread.State: RUNNABLE
    at java.lang.Thread.interrupt(Thread.java:888)
    - locked <0xc899e508> (a java.lang.Object)
    at java.util.concurrent.FutureTask$Sync.innerCancel(FutureTask.java:290)
    at java.util.concurrent.FutureTask.cancel(FutureTask.java:76)
    at org.atmosphere.cpr.DefaultBroadcaster.destroy(DefaultBroadcaster.java:198)
    - locked <0xc8c46688> (a org.atmosphere.cpr.DefaultBroadcaster)
    at org.atmosphere.cpr.DefaultBroadcaster.removeAtmosphereResource(DefaultBroadcaster.java:1136)
    at org.atmosphere.cpr.DefaultBroadcaster.removeAtmosphereResource(DefaultBroadcaster.java:1109)
    at org.atmosphere.cpr.AtmosphereResourceImpl.resume(AtmosphereResourceImpl.java:289)
    - locked <0xc8c45338> (a org.atmosphere.cpr.AtmosphereResourceImpl)
    at org.atmosphere.handler.AbstractReflectorAtmosphereHandler.postStateChange(AbstractReflectorAtmosphereHandler.java:155)
    at org.atmosphere.handler.AbstractReflectorAtmosphereHandler.onStateChange(AbstractReflectorAtmosphereHandler.java:136)
    at org.atmosphere.cpr.DefaultBroadcaster.broadcast(DefaultBroadcaster.java:853)
    at org.atmosphere.cpr.DefaultBroadcaster.executeAsyncWrite(DefaultBroadcaster.java:768)
    at org.atmosphere.cpr.DefaultBroadcaster$3.run(DefaultBroadcaster.java:801)
    - locked <0xc8c45338> (a org.atmosphere.cpr.AtmosphereResourceImpl)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
    at java.util.concurrent.FutureTask.run(FutureTask.java:138)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:662)

Interrupts Glassfish thread, which writes data to a client.

2.0.0 1.0.3

opened by oleksiys 59

WebSocket session closed on tomcat 8

In an Apache Wicket 6.18 Project with atmosphere-runtime 2.2.2 integration, i switched from Tomcat 7.50 to Tomcat 8.14 container. Everything works fine, but when i go to another page (e.g. by an AjaxLink), i get the following Output:

java.lang.IllegalStateException: The WebSocket session [0] has been closed and no method (apart from close()) may be called on a closed session
    at org.apache.tomcat.websocket.WsSession.checkState(WsSession.java:675)
    at org.apache.tomcat.websocket.WsSession.doAddMessageHandler(WsSession.java:191)
    at org.apache.tomcat.websocket.WsSession.addMessageHandler(WsSession.java:171)
    at org.atmosphere.container.JSR356Endpoint.onOpen(JSR356Endpoint.java:196)
    at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.init(WsHttpUpgradeHandler.java:138)
    at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:684)
    at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:222)
    at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1566)
    at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1523)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
    at java.lang.Thread.run(Thread.java:744)

On a Tomcat 7.50 there are no problems. The configuration is:

web.xml:

<listener>
        <listener-class>org.atmosphere.cpr.SessionSupport</listener-class>
    </listener>

    <servlet>
        <description>Atmospherefilter</description>
        <servlet-name>Atmospherefilter</servlet-name>
        <servlet-class>org.atmosphere.cpr.AtmosphereServlet</servlet-class>
        <init-param>
            <param-name>applicationClassName</param-name>
            <param-value>de.laudert.mabi.WicketApplication</param-value>
        </init-param>
        <init-param>
            <param-name>configuration</param-name>
            <param-value>development</param-value>
        </init-param>
        <init-param>
            <param-name>filterMappingUrlPattern</param-name>
            <param-value>/*</param-value>
        </init-param>
        <init-param>
            <param-name>org.atmosphere.cpr.sessionSupport</param-name>
            <param-value>true</param-value>
        </init-param>
        <init-param>
            <param-name>org.atmosphere.cpr.removeSessionTimeout</param-name>
            <param-value>false</param-value>
        </init-param>
        <init-param>
            <param-name>org.atmosphere.websocket.WebSocketProtocol</param-name>
            <param-value>org.atmosphere.websocket.protocol.EchoProtocol</param-value>
        </init-param>
        <init-param>
            <param-name>org.atmosphere.cpr.AtmosphereInterceptor</param-name>
            <param-value>org.atmosphere.client.TrackMessageSizeInterceptor</param-value>
        </init-param>
        <init-param>
            <param-name>org.atmosphere.client.TrackMessageSizeInterceptor.delimiter</param-name>
            <param-value><![CDATA[<|msg|>]]></param-value>
        </init-param>
        <init-param>
            <param-name>org.atmosphere.cpr.broadcasterCacheClass</param-name>
            <param-value>org.atmosphere.cache.UUIDBroadcasterCache</param-value>
        </init-param>
        <load-on-startup>0</load-on-startup>
        <async-supported>true</async-supported>
    </servlet>
    <servlet-mapping>
        <servlet-name>Atmospherefilter</servlet-name>
        <url-pattern>/*</url-pattern>
    </servlet-mapping>

atmosphere.xml:

<atmosphere-handlers>
    <atmosphere-handler context-root="/*"
                        class-name="org.atmosphere.handler.ReflectorServletProcessor">
        <property name="filterClassName" value="de.laudert.mabi.DebugWicketFilter" />

    </atmosphere-handler>
</atmosphere-handlers>

Thanks in advice and kind regards

2.3.0 2.2.4

opened by matzebe 41

Unable to configure jsr356 at that stage. ServerContainer is null

Atmosphere Framework 2.4.0.1 tomcat 7 and 8

[localhost-startStop-1] WARN org.atmosphere.cpr.DefaultAsyncSupportResolver - Failed to create AsyncSupport class: class org.atmosphere.container.JSR356AsyncSupport, error: java.lang.reflect.InvocationTargetException [localhost-startStop-1] ERROR org.atmosphere.cpr.DefaultAsyncSupportResolver - Real error: Unable to configure jsr356 at that stage. ServerContainer is null java.lang.IllegalStateException: Unable to configure jsr356 at that stage. ServerContainer is null at org.atmosphere.container.JSR356AsyncSupport.(JSR356AsyncSupport.java:51) at org.atmosphere.container.JSR356AsyncSupport.(JSR356AsyncSupport.java:40) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:422) at org.atmosphere.cpr.DefaultAsyncSupportResolver.newCometSupport(DefaultAsyncSupportResolver.java:234) at org.atmosphere.cpr.DefaultAsyncSupportResolver.resolveWebSocket(DefaultAsyncSupportResolver.java:306) at org.atmosphere.cpr.DefaultAsyncSupportResolver.resolve(DefaultAsyncSupportResolver.java:292) at org.atmosphere.cpr.AtmosphereFramework.autoDetectContainer(AtmosphereFramework.java:2081) at org.atmosphere.cpr.AtmosphereFramework.init(AtmosphereFramework.java:914)

@Configuration
public class AtmosphereConfig {

     @Bean
        public AtmosphereFramework atmosphereFramework() throws ServletException, InstantiationException, IllegalAccessException {
            AtmosphereFramework atmosphereFramework = new AtmosphereFramework(false, false);
            atmosphereFramework.init(atmosphereSpringContext(), false);
            List<AtmosphereInterceptor> interceptors = new ArrayList<>();
            for (Class<? extends AtmosphereInterceptor> a : atmosphereFramework.defaultInterceptors()) {
                AtmosphereInterceptor interceptor = a.newInstance();
                interceptors.add(interceptor);
            }
            interceptors.addAll(interceptors());
            atmosphereFramework.addAtmosphereHandler("/atmosphere", atmosphereHandler(), interceptors);
            atmosphereFramework.sessionSupport(true);
            return atmosphereFramework;
        }

        @Bean
        public AtmosphereHandler atmosphereHandler() {
            return new MyAtmosphereHandler();
        }

        private List<AtmosphereInterceptor> interceptors() {
            List<AtmosphereInterceptor> atmosphereInterceptors = new ArrayList<>();
            // atmosphereInterceptors.add(new TrackMessageSizeInterceptor());
            return atmosphereInterceptors;
        }

        @Bean
        public BroadcasterFactory broadcasterFactory() throws ServletException, InstantiationException, IllegalAccessException {
            return atmosphereFramework().getAtmosphereConfig().getBroadcasterFactory();
        }

        @Bean
        public AtmosphereSpringContext atmosphereSpringContext() {
            AtmosphereSpringContext atmosphereSpringContext = new AtmosphereSpringContext();
            Map<String, String> map = new HashMap<>();
            map.put("org.atmosphere.cpr.broadcasterClass", org.atmosphere.cpr.DefaultBroadcaster.class.getName());
            map.put(AtmosphereInterceptor.class.getName(), TrackMessageSizeInterceptor.class.getName());
            //map.put(AnnotationProcessor.class.getName(), VoidAnnotationProcessor.class.getName());
            map.put("org.atmosphere.cpr.broadcasterLifeCyclePolicy", ATMOSPHERE_RESOURCE_POLICY.IDLE_DESTROY.toString());
            map.put("org.atmosphere.cpr.broadcaster.shareableThreadPool", "true");
            map.put("org.atmosphere.cpr.scanClassPath", "false");
            map.put("org.atmosphere.useNative", "false");
            atmosphereSpringContext.setConfig(map);
            return atmosphereSpringContext;
        }
}

web.xml

<servlet>
        <description>AtmosphereServlet</description>
        <servlet-name>AtmosphereServlet</servlet-name>
        <servlet-class>org.atmosphere.spring.bean.AtmosphereSpringServlet</servlet-class>
        <async-supported>true</async-supported>
        <load-on-startup>0</load-on-startup>
    </servlet>

See wiki: https://github.com/Atmosphere/atmosphere/wiki/Configuring-Atmosphere-as-a-Spring-Bean

opened by hapali 33

[Glassfish] [HTTPS] Сonnection breaks every few seconds

We are using Glassfish 3.1.2 and Atmosphere 1.0.4 in our application. It's works fine via usual HTTP. But when we trying to work via HTTPS it's working only few first seconds (at most a few tens of seconds). Then we get the following exception:

java.lang.IllegalArgumentException
    at java.nio.Buffer.position(Buffer.java:236)
    at sun.security.ssl.EngineOutputRecord.write(EngineOutputRecord.java:307)
    at sun.security.ssl.EngineOutputRecord.write(EngineOutputRecord.java:268)
    at sun.security.ssl.EngineWriter.writeRecord(EngineWriter.java:185)
    at sun.security.ssl.SSLEngineImpl.writeRecord(SSLEngineImpl.java:1284)
    at sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1254)
    at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1169)
    at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:469)
    at com.sun.grizzly.util.SSLUtils.wrap(SSLUtils.java:332)
    at com.sun.grizzly.util.SSLOutputWriter.flushChannel(SSLOutputWriter.java:89)
    at com.sun.grizzly.ssl.SSLAsyncOutputBuffer.flushChannel(SSLAsyncOutputBuffer.java:90)
    at com.sun.grizzly.http.SocketChannelOutputBuffer.flushBuffer(SocketChannelOutputBuffer.java:489)
    at com.sun.grizzly.http.SocketChannelOutputBuffer.flush(SocketChannelOutputBuffer.java:467)
    at com.sun.grizzly.http.ProcessorTask.action(ProcessorTask.java:1276)
    at com.sun.grizzly.ssl.SSLProcessorTask.action(SSLProcessorTask.java:164)
    at com.sun.grizzly.tcp.Response.action(Response.java:268)
    at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:380)
    at org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:353)
    at org.apache.catalina.connector.CoyoteWriter.flush(CoyoteWriter.java:153)
    at com.ourcompany.engine.network.TransportHandler.onRequest(TransportHandler.java:378)
    at org.atmosphere.cpr.AsynchronousProcessor.action(AsynchronousProcessor.java:256)
    at org.atmosphere.cpr.AsynchronousProcessor.suspended(AsynchronousProcessor.java:166)
    at org.atmosphere.container.GrizzlyCometSupport.service(GrizzlyCometSupport.java:119)
    at org.atmosphere.container.GlassFishWebSocketSupport.service(GlassFishWebSocketSupport.java:66)
    at org.atmosphere.cpr.AtmosphereFramework.doCometSupport(AtmosphereFramework.java:1292)
    at org.atmosphere.cpr.AtmosphereServlet.doPost(AtmosphereServlet.java:293)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
    at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1542)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
    at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
    at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
    at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
    at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:174)
    at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849)
    at com.sun.grizzly.comet.CometEngine.executeServlet(CometEngine.java:444)
    at com.sun.grizzly.comet.CometEngine.handle(CometEngine.java:308)
    at com.sun.grizzly.comet.CometAsyncFilter.doFilter(CometAsyncFilter.java:87)
    at com.sun.grizzly.arp.DefaultAsyncExecutor.invokeFilters(DefaultAsyncExecutor.java:171)
    at com.sun.grizzly.arp.DefaultAsyncExecutor.interrupt(DefaultAsyncExecutor.java:143)
    at com.sun.grizzly.arp.AsyncProcessorTask.doTask(AsyncProcessorTask.java:102)
    at com.sun.grizzly.http.TaskBase.run(TaskBase.java:193)
    at com.sun.grizzly.http.TaskBase.execute(TaskBase.java:175)
    at com.sun.grizzly.arp.DefaultAsyncHandler.handle(DefaultAsyncHandler.java:145)
    at com.sun.grizzly.arp.AsyncProtocolFilter.execute(AsyncProtocolFilter.java:210)
    at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
    at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
    at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
    at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
    at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
    at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
    at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
    at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
    at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
    at java.lang.Thread.run(Thread.java:722)

opened by freeflyer 33

[osgi[ [session] Exception running 1.0.13 on jetty 8.1.10
Hi,

i tried running vaadin.push bundle on jetty 8.1.10 using atmosphere 1.0.13.

In 1.0.13 following line of code was added to AtmosphereFramework.class

sc.getServletContext().addListener(SessionSupport.class.getName());

Running on jetty it causes an exception since servletContext is already started.

org.eclipse.jetty.servlet.ServletContextHandler$Context

@Override public void addListener(String className) { // TODO other started conditions if (!isStarting()) throw new IllegalStateException(); if (!_enabled) throw new UnsupportedOperationException(); super.addListener(className); }

I am not sure whether it is a bug from jetty or from atmosphere.

Thanks for help, Florian
1.0.14
opened by lunifera 29
[runtime] - 1.0.13-SNAPSHOT thread leak
I've tried upgrading from Atmosphere 1.0.6-SNAPSHOT to 1.0.13-SNAPSHOT (to resolve the issue mentioned here https://github.com/Atmosphere/atmosphere/issues/957) and our prod server crashed after an hour.

Checking the threads I see these are the leaking threads(thousands of them):

Atmosphere-Shared-DispatchOp Atmosphere-Shared-AsyncOp

Is this the new behavior of the latest version? or should I change the config?

these are my settings:

<init-param> <param-name>org.atmosphere.cpr.broadcaster.shareableThreadPool</param-name> <param-value>true</param-value> </init-param> <init-param> <param-name>org.atmosphere.cpr.broadcasterLifeCyclePolicy</param-name> <param-value>EMPTY_DESTROY</param-value> </init-param>
not a bug 1.0.13
opened by poi212003 29
streaming transport not working in Android 2.2/2.3 browser
I'm not sure about later versions. Tested with Android 2.3.

Probably related to: https://code.google.com/p/android/issues/detail?id=13044

I had to use long-polling, which works. However, without explicitly specifying

fallbackTransport: 'long-polling'

in jQuery Atmosphere.js usage, Atmosphere JS Client uses streaming, which doesn't work on Android browser, but works well in desktop browsers (i.e. Firefox 12).
1.0.0
opened by ceefour 27
Websocket protocol not supported (CLS=o.a.cpr.AsynchronousProcessor) is raised in Atmosphere logs while using Jetty 10.0.9
Describe the bug Using atmosphere version 2.7.6 with Jetty 10.0.9, we encountered problem as shown in the log "Websocket protocol not supported (CLS=o.a.cpr.AsynchronousProcessor)" while trying to establish websocket connection to our server. According to our quick check, it looks that the PR change https://github.com/tkohlman/atmosphere/commit/e2cb4d0a061f1b89773d3862364efedf83d23e20 prepared by tkohlman in the related case#2455 (https://github.com/Atmosphere/atmosphere/issues/2455) seems to be needed to enable atmosphere to automatically discover Jetty 10 support. Could you share why this PR is NOT merged? Can we expect the support for Jetty 10 in new version of atmosphere with websocket functionality as we had before upgrading?

Atmosphere Info

2.7.6 Java maven dependencies upgraded from 2.4.32 with Jetty 9.4 while the websocket was working fine.

Expected behavior Before our upgrade while we were using Jetty 9.4 and Atmosphere 2.4.32, the websocket functionality was working seemlessly. We expect the same after upgrading to Jetty 10.0.9 with Atmosphere new version (now we are using 2.7.6 but not working).

Screenshots If applicable, add screenshots to help explain your problem.

Systems (please complete the following information):

OS: Not applicable

Browser name and version [e.g. chrome 22]

Java version and distribution JDK 11.0.6

Serveur name and version [e.g Tomcat/Jetty/Netty]: Jetty 10.0.9

Additional context For anything else, feel free to get back to us. Thanks in advance! This issue is blocking our production upgrade now. Please help to address it as high priority if possible. Thanks in advance!
opened by nopainsnogains12 26
long-polling dropping messages on multiple messages in a burst

I have been experiencing some issues with atmosphere failing to publish messages when there is a burst of activity. I cobbled my code together from docs and examples as there was nothing quite like it in the samples. So it is quite possible I am doing something daft, but I can't see it.

I use atmosphere as part of a framework to write multi-player turn based games. Each player subscribes to a dedicated unique channel ('/livefeed/{my id}') to receive updates via long-polling. All updates are generated within the server (there are no writes from the client). All updates are point to point to specific channels (i.e. if there is an update to a game with 5 players, each player is looked up and published to). Because the server can be clustered, and different clients connected to different servers, each server does a lookup to see if the client is present on this server.

The code looks roughly like: for each player in game { get broadcasterfactory broadcasterFactory.lookup( '/livefeed/{playerid}') if(!null) use it to publish else this user is not on this server or not online at all }

What I have found is if there is a burst of messages, while the client is processing the first message (not doing much and I did an experiment where I did even less) the lookup returns null. If I put a pause/retry after 100ms loop in, the client is found on the 2nd attempt usually. Is the lookup meant to fail if the client is already processing a message? Am I completely misusing the framework?

The actual code for publishing is here (look at last function). It does not have the loop/retry I added locally but you can see the basic shape of the code. https://github.com/jtbdevelopment/core-games/blob/master/games-websocket/src/main/groovy/com/jtbdevelopment/games/websocket/AtmosphereListener.groovy (broadcasterFactory.broadcasterFactory is a call to Universe.broadcasterFactory())

The channel is registered here: https://github.com/jtbdevelopment/core-games/blob/master/games-websocket/src/main/groovy/com/jtbdevelopment/games/websocket/LiveFeedService.groovy

The client is atmosphere javascript here (again in my local version, I moved all processing inside an angular $timeout(function(){}); and no change. https://github.com/jtbdevelopment/core-games-ui/blob/master/src/core-games-ui/services/liveGameFeed.js

Thank you for any help or pointers.
2.4.0

opened by jtbdevelopment 26
Using atmosphere causes Glassfish requests to hang, only over SSL.
I think this may be similar to Issue #744, but the patched grizzly-http.jar in that issue didn't fix our issue.

On each page of our application, we create a atmosphere connection back to our server. After a few page views, random web requests hang for 30 seconds, after 30 seconds, the connection seems to complete. If we don't use https, everything works as expected, there are no 30 second pauses.

How to reproduce using the atmosphere-jquery-pubsub sample application: Using Glassfish 3.1.2.2 (Comet and WebSockets enabled), Firefox 17. To reproduce, I had to modify the atmosphere-jquery-pubsub application slightly. I had to create a connection on page load, instead of waiting for user interaction. See https://gist.github.com/4276936 Copy the jquery-pubsub-bugreport-index.html over index.html

Load the index.html page, and refresh the page 8-10 times. (It may take more, seems somewhat random, but I can usually do it in 5-8 refershes). Notice that the page load will hang, Firebug will show some random resource is being slow to load. There are no exceptions in Glassfish's server.log.

If we don't create the subscription on page load, (don't use atmosphere) - we can reload the page with out issue over SSL.

Things we've tried:

Raising the number of Threads in the http-thread pool to 200.

Raising the Acceptor Threads in the tcp transport.

The patched grizzly-http.jar from Issue #744

Disabling org.atmosphere.useNative

None of the above changes alter the behavior, after about 5-10 refreshes, the requests hang.
opened by skrall 25
Support atmosphere-spring for Jakarta 3.0 jakarta.servlet

The atmosphere-spring module is still using "javax.servlet". As the Spring framework 6.0.0-RC3 is already released to support Jakarta 3.0, when can we expect a new artifact for atmosphere-spring to support "jakarta.servlet"?.

Please note that atmosphere-runtime is already supporting Jakarta 3.0 https://github.com/Atmosphere/atmosphere/issues/2467

opened by sanushchacko 3

Provide runtime hints for Spring Boot 3 native applications

Spring Boot 3 native applications require compile time definitions of which reflection data needs to be available at runtime. Atmosphere could provide this info for its own classes by adding a RuntimeHintsRegistrar.

An example registrar I have tested basic functionality with looks like this (certainly incomplete):

public class AtmosphereHintsRegistrar implements RuntimeHintsRegistrar {

    @Override
    public void registerHints(RuntimeHints hints, ClassLoader classLoader) {
        ReflectionHints ref = hints.reflection();
        try {
            for (Class<?> c : getAtmosphereClasses()) {
                ref.registerType(c, MemberCategory.values());
            }
        } catch (Exception e) {
            throw new RuntimeException(e);
        }

    }

    private Collection<? extends Class<?>> getAtmosphereClasses() {
        Set<Class<?>> classes = new HashSet<>();
        classes.add(DefaultAtmosphereResourceFactory.class);
        classes.add(SimpleHttpProtocol.class);

        classes.addAll(AtmosphereFramework.DEFAULT_ATMOSPHERE_INTERCEPTORS);
        classes.add(AtmosphereResourceLifecycleInterceptor.class);
        classes.add(TrackMessageSizeInterceptor.class);
        classes.add(SuspendTrackerInterceptor.class);
        classes.add(DefaultBroadcasterFactory.class);
        classes.add(SimpleBroadcaster.class);
        classes.add(DefaultBroadcaster.class);
        classes.add(UUIDBroadcasterCache.class);
        classes.add(VoidAnnotationProcessor.class);
        classes.add(DefaultAtmosphereResourceSessionFactory.class);
        classes.add(JSR356AsyncSupport.class);
        classes.add(DefaultMetaBroadcaster.class);

        return classes;
    }
}

opened by Artur- 1

Compression websocket messages
Hello guys, I am trying to find a solution for compression websocket messages, if you can help, it will be very nice

atmosphere version 2.7.6

atmosphere.js 3.1.3

I want to find a way to compress messages I have in Json formats, cause they are huge, For investigating I used meteor-chat sample and spring-boot-chat-atmosphere-sample I found an issue about this with a link https://github.com/Atmosphere/atmosphere/issues/2039/ and did all thing to implement the compression, but as I understand it didn't work. For example, I tried to add some JSR356 support to web.xml in meteor-chat sample or init parameters to the ServletRegistrationBean in spring-boot-sample, changed configuration in domain.xml for payara5(glassfish5) and server.xml in tomcat9 to change settings of the ServletContainer. Tried to do the compression explicitly with the GZipOutputStream but I couldn't get the response from the server in a client side. I tried to add some headers to the response of websocket request like Sec-Websocket-Extensions: permessage-deflate, but in the end I couldn't add this header manually.

for testing except chrome browser I also use wireshark

java 1.8 from amazon

Server name Tomcat9, Payara5
opened by repbl444 8

SSE doesn't output error bodies, just spaces

Describe the bug SSE transport doesn't allow error bodies to be written, unlike other transports:

(Full source based on samples used in the curl requests is at https://gist.github.com/byteit101/63c5fe645cbfa7e2222948bd77e72d51 )

		if (r.transport() != TRANSPORT.SSE)
			return Response.status(Status.BAD_REQUEST).entity("SSE is the only thing supported").build();
		else
			return Response.status(451).entity("{my-error-body}").build();

Atmosphere Info

version 2.7.7

Expected behavior long-polling (actual, correct):

$ curl -s -i -X GET 'http://localhost:8080/chat/the/sse/error' -H 'Accept: text/event-stream,application/json'                           
HTTP/1.1 400 Bad Request
(snip)
Content-Length: 31

SSE is the only thing supported%
$

SSE (theoretical response):

$ curl -s -i -X GET 'http://localhost:8080/chat/the/sse/error?X-Atmosphere-Transport=sse' -H 'Accept: text/event-stream,application/json'
HTTP/1.1 451 
(snip)
Content-Length: 15

{my-error-body}%
$

Actual behavior SSE:

$ curl -s -i -X GET 'http://localhost:8080/chat/the/sse/error?X-Atmosphere-Transport=sse' -H 'Accept: text/event-stream,application/json'
HTTP/1.1 451 
(snip)
Content-Length: 15

               %
$

Interestingly, the length (and number of spaces) is the correct size. Note I used the terminal garbage % to show the end of line as there was no newline.

Systems (please complete the following information):

OS: linux x64
Browser name and version: N/A
Java version and distribution: OpenJDK 1.8 && 11
Server name and version: Jetty

Additional context A "normal" sse call has lots of spaces, I'm not sure if it's relevant but I noticed it:

$ curl -s -i -X GET 'http://localhost:8080/chat/the/sse/normal?X-Atmosphere-Transport=sse' -H 'Accept: text/event-stream,application/json'
HTTP/1.1 200 OK
(snip)
Transfer-Encoding: chunked

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
data:suspend

data:X

^C
$

2.7.8

opened by byteit101 0

Potential Refactoring Estimate
Summary I have identified a few classes with refactoring potential along with its estimated time to refactor, specifically AbstractJetty9AsyncSupportWithWebSocket.java. The estimated time is based on historical commits containing refactoring and the complexity of the involved classes. The class was refactored once on May 16, 2017 along with other classes in commit 9fd3d45c01b0c52d57ddfb6664eb6bb67c072410. Given the duration of the last refactoring, could it be possible to improve this class further? I am probably not qualified and experienced enough to point out the exact code needs to be refactored, given my limited knowledge of the project and codebase.

Urgency Low priority. For maintenance of code in the long run.

Hi, I am currently doing some research on Estimating Time Taken for Software Refactoring. Atmosphere is one of my case studies being a highly popular project. Would appreciate your kind feedback on the appropriateness of the estimated time to refactor. I am specifically looking at potential for refactoring, such as breaking functions that are too long into shorter functions, or to remove code duplication. Would you agree that there could be some modification to the code to make it better in the listed classes? And if so, is the estimated time appropriate to carry out the improvement? I will be grateful for any help you can provide.

AbstractJetty9AsyncSupportWithWebSocket.java - 2 hours

AbstractReflectorAtmosphereHandler.java - 2 hours

AbstractBroadcasterCache.java - 2.5 hours

Thank you.

Regards, Alvin
opened by alvintanjianjia 1
Move class JavaScriptProtocol into package cpr

Hi, @jfarcand

Issue Description

Package org.atmosphere.interceptor is a promiscuous package, and groups together miscellaneous functionalities that might be useful to different subsystems. This means the cohesion between classes in the package is low. However, since the project has grown larger, this package structure is becoming increasingly hard to navigate. We found that Class JavaScriptProtocol is not used by classes in their package org.atmosphere.interceptor. Moreover, there is a lot of dependencies between class JavaScriptProtocol and classes in the package org.atmosphere.cpr.

Location: The source file can be found at path File /modules/cpr/src/main/java/org/atmosphere/interceptor/JavaScriptProtocol.java

Refactoring suggestions

To avoid making org.atmosphere.interceptor too big and unmanageable, we suggest to move class JavaScriptProtocol into package org.atmosphere.cpr.

opened by yanyiyi-yi 4