Server Side Events getting error

I know this isn’t a javascript group, but I’m wondering if there is
something specific to Lucee that is causing this issue (and if you
know about SSE’s and can provide why this isn’t working, so much the
better).

So I have the following code in the javascript of the page.

and on the server side, I have this…

data: Hello World!\n\n

I copied this from a few websites around the web and as I can see it,
logically, this should work. However, when I run it, I get an error.
It opens up correctly, but I get an error and close.

The error is multi-layered and I am boggled by what I should be
looking for 6 layers deep.

If someone can please point me to where I am going wrong, it would be
very appreciated. It loads ok and it keeps refreshing (when I remove
the “source.close()”)… I just don’t see anything on the screen. It’s
fully blank (source shows the javascript and the div unfilled).

If thats all you have in the cfm, then you’re not keeping the connection
open…

You’d want to throw a cfflush in there

And then enter some soryOn Sat, Feb 11, 2017 at 12:14 PM Phillip Vector <@Phillip_Vector> wrote:

I know this isn’t a javascript group, but I’m wondering if there is
something specific to Lucee that is causing this issue (and if you
know about SSE’s and can provide why this isn’t working, so much the
better).

So I have the following code in the javascript of the page.

and on the server side, I have this…

data: Hello World!\n\n

I copied this from a few websites around the web and as I can see it,
logically, this should work. However, when I run it, I get an error.
It opens up correctly, but I get an error and close.

The error is multi-layered and I am boggled by what I should be
looking for 6 layers deep.

If someone can please point me to where I am going wrong, it would be
very appreciated. It loads ok and it keeps refreshing (when I remove
the “source.close()”)… I just don’t see anything on the screen. It’s
fully blank (source shows the javascript and the div unfilled).


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CANmAeAxTKPChZ9pCnDT0t1WGB0N%3D2a%2BXO97d4QGx_tMh_BdLEA%40mail.gmail.com
.
For more options, visit https://groups.google.com/d/optout.

Trying again…grr ipad

If thats all you have in the cfm, then you’re not keeping the connection
open…

You’d want to throw a cfflush in there

And then enter some sort of busywait loop or sleep cycle to retrieve more
server messages from your producer and output them with a cfflush following
to your consumer.(javascript). Possibly with : comments every 10-15 seconds
to keep any agressive firewalls happy.

Plus you’ll run into the requesttimeout. So you’ll want to increase that
w/ cfsetting.

Any reason you’re doing this instead of leveraging something like
rabbitmq+STOMP?
-GOn Sat, Feb 11, 2017 at 12:14 PM Phillip Vector <@Phillip_Vector> wrote:

I know this isn’t a javascript group, but I’m wondering if there is
something specific to Lucee that is causing this issue (and if you
know about SSE’s and can provide why this isn’t working, so much the
better).

So I have the following code in the javascript of the page.

and on the server side, I have this…

data: Hello World!\n\n

I copied this from a few websites around the web and as I can see it,
logically, this should work. However, when I run it, I get an error.
It opens up correctly, but I get an error and close.

The error is multi-layered and I am boggled by what I should be
looking for 6 layers deep.

If someone can please point me to where I am going wrong, it would be
very appreciated. It loads ok and it keeps refreshing (when I remove
the “source.close()”)… I just don’t see anything on the screen. It’s
fully blank (source shows the javascript and the div unfilled).


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CANmAeAxTKPChZ9pCnDT0t1WGB0N%3D2a%2BXO97d4QGx_tMh_BdLEA%40mail.gmail.com
.
For more options, visit https://groups.google.com/d/optout.

I tried that and trying to move away from it.

I have around 20-40 players logged into the chat at once. Even at 10
seconds, it basically DDOSs my server.On Sun, Feb 12, 2017 at 6:26 PM, Joseph Gooch <@Joseph_Gooch> wrote:

If you just want it to rerun the page every 3 seconds, why not put a
jQuery.ajax call in a Javascript setInterval? :slight_smile:

-G

On Sun, Feb 12, 2017 at 11:58 AM, Phillip Vector <@Phillip_Vector> wrote:

I put in the close to see what the error was. It only triggers if the call
returns an error.

So it isn’t rerunning the page every 3 seconds? Damm. I may have to work
out Node.js and connect.io then.

On Feb 12, 2017 05:36, “Joseph Gooch” <@Joseph_Gooch> wrote:

I’ve never used SSE’s so I’m flying a little blind here… but:
https://www.html5rocks.com/en/tutorials/eventsource/basics/
That example doesn’t have .close

Code here:

https://github.com/html5rocks/www.html5rocks.com/tree/master/content/tutorials/eventsource/basics/static/demo

The Javascript around line 227:

https://github.com/html5rocks/www.html5rocks.com/blob/master/content/tutorials/eventsource/basics/static/demo/sse.html

No close.

I do not believe you want the source.close(). If you do that, the
browser will not reconnect. (You’re closing the stream)

So that’s the client side. :slight_smile:

Now if you look at the server side…

https://github.com/html5rocks/www.html5rocks.com/blob/master/content/tutorials/eventsource/basics/static/demo/sse.php

Check out the busy loop. With flushing.

The whole point of a SSE stream would be to have a long running
connection, during which you could periodically send updated data packets as
they happen… From ACF or Lucee’s perspective - that’s one single cfm call.
So you’d need to do the busy waiting yourself. The browser reconnects
automatically/maybe with a 3 sec delay - that’s just to work around servers
that are used to a transactional HTTP connection that closes, or aggressive
firewalls with short connection timeouts, or transitory network issues.

It’s possible you have an extension, or you’re using a feature of Lucee
I’m not aware of… But just going by how CF works - Lucee’s not going to
know your data has changed. There’s no way Lucee could poll your CFM and
know that the content changed, and then issue an update… Lucee would have
to know that request connection would need to stay open, and it would have
to poll your backend datasource, not your filesystem, and ultimately, the
cfm is generating dynamic output - so it would have to RUN the cfm before it
knew there was a change. The logic to know there’s a change (i.e. new
message) and send it would have to be in your wait loop.

If you’re really just sending, say, all the new messages received for
that session since the last poll - at that point you might as well use XHR.
If you don’t have a long running request, the client is polling anyway.

http://socket.io goes through the chat room pretty thoroughly - they use
websockets, which introduces other challenges. (or long polling - which is
similar to what SSE is doing)

-G

On Sun, Feb 12, 2017 at 1:52 AM, Phillip Vector <@Phillip_Vector> wrote:

You’d want to throw a cfflush in there

Tried that. No luck. Though I will try again.

And then enter some sort of busywait loop or sleep cycle to retrieve
more server messages from your producer and output them with a cfflush
following to your consumer.(javascript). Possibly with : comments every
10-15 seconds to keep any agressive firewalls happy.

It was my understanding that I didn’t need to keep rechecking as the
server pings the file and (I thought) that if the output changes, it
pushes the changes to the client. If I remove the .close(), it keeps
checking every 3 seconds or so.

Plus you’ll run into the requesttimeout. So you’ll want to increase
that w/ cfsetting.

nods Ok. I’ll keep that in mind.

Any reason you’re doing this instead of leveraging something like
rabbitmq+STOMP?

Because my javascript sucks and this seemed like the easiest thing to
implement (HA!) for a set of chat rooms I’m trying to change from the
clients pinging the server every 10 seconds and this seemed like a
viable option. I’m currently trying to get into connect.io and
node.js, but I’m feeling lost and confused and such as my knowledge of
javascript is limited to basic jQuery stuff.

On Sat, Feb 11, 2017 at 6:49 PM, Joseph Gooch <@Joseph_Gooch> wrote:

Trying again…grr ipad

If thats all you have in the cfm, then you’re not keeping the
connection
open…

You’d want to throw a cfflush in there

And then enter some sort of busywait loop or sleep cycle to retrieve
more
server messages from your producer and output them with a cfflush
following
to your consumer.(javascript). Possibly with : comments every 10-15
seconds
to keep any agressive firewalls happy.

Plus you’ll run into the requesttimeout. So you’ll want to increase
that w/
cfsetting.

Any reason you’re doing this instead of leveraging something like
rabbitmq+STOMP?
-G

On Sat, Feb 11, 2017 at 12:14 PM Phillip Vector <@Phillip_Vector> wrote:

I know this isn’t a javascript group, but I’m wondering if there is
something specific to Lucee that is causing this issue (and if you
know about SSE’s and can provide why this isn’t working, so much the
better).

So I have the following code in the javascript of the page.

and on the server side, I have this…

data: Hello World!\n\n

I copied this from a few websites around the web and as I can see it,
logically, this should work. However, when I run it, I get an error.
It opens up correctly, but I get an error and close.

The error is multi-layered and I am boggled by what I should be
looking for 6 layers deep.

If someone can please point me to where I am going wrong, it would be
very appreciated. It loads ok and it keeps refreshing (when I remove
the “source.close()”)… I just don’t see anything on the screen.
It’s
fully blank (source shows the javascript and the div unfilled).


You received this message because you are subscribed to the Google
Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it,
send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/CANmAeAxTKPChZ9pCnDT0t1WGB0N%3D2a%2BXO97d4QGx_tMh_BdLEA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google
Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/CAKY58c5Z1OWKVFZs1%3De%3Do1S10J8fg-N71ZUMRPZ3xkrJcDcydQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google
Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CANmAeAyMzkq16_zYv5fWajUEwTgYR0iTCu4xwr9O1og%2BDSuc%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAKY58c7wYenDfBVbEetO4Ousm%3DBvbJVvfjxmOUj%3D%3D3P9H_M7rA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CANmAeAzNdB0vv9PCGw63PX%3DPgCOxS1ZY5q8poFNr7T161icbZw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAKY58c4pPqN8KcUaiFTvK-PZtJzp_HcN-5RZ_HxPX_%2BB2%3Diqew%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

Thank you for the advise. :slight_smile: This is enough I think to get me moving
in the right direction. :)On Sun, Feb 12, 2017 at 7:35 PM, Joseph Gooch <@Joseph_Gooch> wrote:

Here’s a really basic example.
https://github.com/goochjj/ChatApp

Clone, box server start, and browse to /chat/index.cfm

Each tab is a different “client” guid.
Type something in the text area and hit send, and you’ll see it back on your
screen, and every other tab too.

Open the chrome dev tools, and you’ll see a long-running request to
messages.cfm that never dies. (hopefully) It just sends data as it’s
available.

sendmsg is a simple ajax call to send a new message.

I’m using in-memory java LinkedBlockingQueues to do the concurrency,
intelligent locking between requests, etc.
https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/LinkedBlockingQueue.html

This also means the messages only exist in memory, and only on a single
server instance.

Ultimately what you’re doing lends itself to a messaging structure. (Several
queues of one to many broadcasting) The javascript pattern here is also
based on messaging and queueing…

In this case there’s no polling. .take() waits until there’s a message. I
don’t have to implement that logic. Internally it’s probably a java
semaphore or condition object. I’m using a structure to track room
“members”, and looping over queues to inject messages. So sendmsg has the
broadcast semantics. Queues are essentially one per client. No polling
because Java’s handling it internally.

Using a backend like a database means you’re going to have to poll
somewhere. It might be in lucee, it might be having the browser poll the
server… You should determine what your server can’t handle. 40req/3sec
doesn’t sound all that onerous. Unless every request is pulling the entire
table, maybe you need to refine your queries.

If the problem is pulling from the database, or network RTT, then moving the
polling server-side may help that, but you’re still going to have a loop
something like

Loop forever {
query mysql for new messages for my client
Got some? Cool. Output to client (cfoutput, pkt like I did) for as many as
there are
Sleep for some reasonable amount of time
}

(Because, AFAIK, MySQL doesn’t have something similar to MSSQL’s Service
Broker to do message queueing, and things like WAITFOR CONVERSATION)

At least looping server side means you have the control server side to make
sure the polling is on your terms. And still there’s going to be some sort
of requesttimeout to contend with, at which point, yes, the browser should
reconnect to the stream.

Inherent in this too is remembering the last message the client saw… so you
may need to retrieve state before the loop, update state throughout the
loop… so you don’t rebroadcast messages they’ve already seen.

Or when you first generate the page, you don’t use the eventsource… you
render what they should see, and from that point use the event source for
near-realtime delivery. (It’ll never be truly realtime with polling) There
are tons of options.

One option would be to use an actual messaging platform. Jabber/GChat or
roll your own messaging with RabbitMQ or similar. Socket.io on the client
side, STOMP on Rabbit, manage your channels, good to go. Which is more like
what I’d do - use the right technology for the right problem.

https://github.com/lmajano/messaging-polyglot
with
https://github.com/goochjj/docker-rabbitmq-ssl-stomp

Would be suitable to start playing.

-G

On Sun, Feb 12, 2017 at 9:55 PM, Phillip Vector <@Phillip_Vector> wrote:

I am storing incoming messages in a MySQL database with a “RoomID”
code set. When someone is in the “Chat” function, it queries the
database using a where for the roomID the player is in and gives a
list of messages they can see. I then replace a div area with the list
of messages after formating.

On Sun, Feb 12, 2017 at 6:32 PM, Joseph Gooch <@Joseph_Gooch> wrote:

How are you storing and distributing the messages? How do you organize
them
in chat rooms and determine who needs to receive what message?

-G

On Sun, Feb 12, 2017 at 9:30 PM, Phillip Vector <@Phillip_Vector> wrote:

I tried that and trying to move away from it.

I have around 20-40 players logged into the chat at once. Even at 10
seconds, it basically DDOSs my server.

On Sun, Feb 12, 2017 at 6:26 PM, Joseph Gooch <@Joseph_Gooch> wrote:

If you just want it to rerun the page every 3 seconds, why not put a
jQuery.ajax call in a Javascript setInterval? :slight_smile:

-G

On Sun, Feb 12, 2017 at 11:58 AM, Phillip Vector <@Phillip_Vector> wrote:

I put in the close to see what the error was. It only triggers if
the
call
returns an error.

So it isn’t rerunning the page every 3 seconds? Damm. I may have to
work
out Node.js and connect.io then.

On Feb 12, 2017 05:36, “Joseph Gooch” <@Joseph_Gooch> wrote:

I’ve never used SSE’s so I’m flying a little blind here… but:
https://www.html5rocks.com/en/tutorials/eventsource/basics/
That example doesn’t have .close

Code here:

https://github.com/html5rocks/www.html5rocks.com/tree/master/content/tutorials/eventsource/basics/static/demo

The Javascript around line 227:

https://github.com/html5rocks/www.html5rocks.com/blob/master/content/tutorials/eventsource/basics/static/demo/sse.html

No close.

I do not believe you want the source.close(). If you do that, the
browser will not reconnect. (You’re closing the stream)

So that’s the client side. :slight_smile:

Now if you look at the server side…

https://github.com/html5rocks/www.html5rocks.com/blob/master/content/tutorials/eventsource/basics/static/demo/sse.php

Check out the busy loop. With flushing.

The whole point of a SSE stream would be to have a long running
connection, during which you could periodically send updated data
packets as
they happen… From ACF or Lucee’s perspective - that’s one single
cfm
call.
So you’d need to do the busy waiting yourself. The browser
reconnects
automatically/maybe with a 3 sec delay - that’s just to work around
servers
that are used to a transactional HTTP connection that closes, or
aggressive
firewalls with short connection timeouts, or transitory network
issues.

It’s possible you have an extension, or you’re using a feature of
Lucee
I’m not aware of… But just going by how CF works - Lucee’s not
going
to
know your data has changed. There’s no way Lucee could poll your
CFM
and
know that the content changed, and then issue an update… Lucee
would
have
to know that request connection would need to stay open, and it
would
have
to poll your backend datasource, not your filesystem, and
ultimately,
the
cfm is generating dynamic output - so it would have to RUN the cfm
before it
knew there was a change. The logic to know there’s a change (i.e.
new
message) and send it would have to be in your wait loop.

If you’re really just sending, say, all the new messages received
for
that session since the last poll - at that point you might as well
use
XHR.
If you don’t have a long running request, the client is polling
anyway.

http://socket.io goes through the chat room pretty thoroughly -
they
use
websockets, which introduces other challenges. (or long polling -
which is
similar to what SSE is doing)

-G

On Sun, Feb 12, 2017 at 1:52 AM, Phillip Vector <@Phillip_Vector> wrote:

You’d want to throw a cfflush in there

Tried that. No luck. Though I will try again.

And then enter some sort of busywait loop or sleep cycle to
retrieve
more server messages from your producer and output them with a
cfflush
following to your consumer.(javascript). Possibly with :
comments
every
10-15 seconds to keep any agressive firewalls happy.

It was my understanding that I didn’t need to keep rechecking as
the
server pings the file and (I thought) that if the output changes,
it
pushes the changes to the client. If I remove the .close(), it
keeps
checking every 3 seconds or so.

Plus you’ll run into the requesttimeout. So you’ll want to
increase
that w/ cfsetting.

nods Ok. I’ll keep that in mind.

Any reason you’re doing this instead of leveraging something like
rabbitmq+STOMP?

Because my javascript sucks and this seemed like the easiest thing
to
implement (HA!) for a set of chat rooms I’m trying to change from
the
clients pinging the server every 10 seconds and this seemed like a
viable option. I’m currently trying to get into connect.io and
node.js, but I’m feeling lost and confused and such as my
knowledge
of
javascript is limited to basic jQuery stuff.

On Sat, Feb 11, 2017 at 6:49 PM, Joseph Gooch <@Joseph_Gooch> wrote:

Trying again…grr ipad

If thats all you have in the cfm, then you’re not keeping the
connection
open…

You’d want to throw a cfflush in there

And then enter some sort of busywait loop or sleep cycle to
retrieve
more
server messages from your producer and output them with a
cfflush
following
to your consumer.(javascript). Possibly with : comments every
10-15
seconds
to keep any agressive firewalls happy.

Plus you’ll run into the requesttimeout. So you’ll want to
increase
that w/
cfsetting.

Any reason you’re doing this instead of leveraging something
like
rabbitmq+STOMP?
-G

On Sat, Feb 11, 2017 at 12:14 PM Phillip Vector <@Phillip_Vector> wrote:

I know this isn’t a javascript group, but I’m wondering if
there
is
something specific to Lucee that is causing this issue (and if
you
know about SSE’s and can provide why this isn’t working, so
much
the
better).

So I have the following code in the javascript of the page.

and on the server side, I have this…

data: Hello World!\n\n

I copied this from a few websites around the web and as I can
see
it,
logically, this should work. However, when I run it, I get an
error.
It opens up correctly, but I get an error and close.

The error is multi-layered and I am boggled by what I should be
looking for 6 layers deep.

If someone can please point me to where I am going wrong, it
would
be
very appreciated. It loads ok and it keeps refreshing (when I
remove
the “source.close()”)… I just don’t see anything on the
screen.
It’s
fully blank (source shows the javascript and the div unfilled).


You received this message because you are subscribed to the
Google
Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from
it,
send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/CANmAeAxTKPChZ9pCnDT0t1WGB0N%3D2a%2BXO97d4QGx_tMh_BdLEA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the
Google
Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from
it,
send
an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/CAKY58c5Z1OWKVFZs1%3De%3Do1S10J8fg-N71ZUMRPZ3xkrJcDcydQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google
Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it,
send
an email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/CANmAeAyMzkq16_zYv5fWajUEwTgYR0iTCu4xwr9O1og%2BDSuc%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google
Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it,
send
an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/CAKY58c7wYenDfBVbEetO4Ousm%3DBvbJVvfjxmOUj%3D%3D3P9H_M7rA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google
Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it,
send
an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/CANmAeAzNdB0vv9PCGw63PX%3DPgCOxS1ZY5q8poFNr7T161icbZw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google
Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it,
send
an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/CAKY58c4pPqN8KcUaiFTvK-PZtJzp_HcN-5RZ_HxPX_%2BB2%3Diqew%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google
Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/CANmAeAwBgAxNnfL2pR13GxC4M%3D6MtYF%2BdFovKKBqwHZXvKRNrg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google
Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/CAKY58c7qWBnY%3D3Fc6XSrvjOeabVRxEAqC5eRHjqFh%2BPzDObR_w%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CANmAeAxcMQG0Ot8%3DuQU6LaWAqf3120M6ecNTnUuxqWLRZXn_Rw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAKY58c68gjOjqer43PT610FXXaoDJT%3De9ux4ReW2k7YS2%2B7M5Q%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

How are you storing and distributing the messages? How do you organize
them in chat rooms and determine who needs to receive what message?

-GOn Sun, Feb 12, 2017 at 9:30 PM, Phillip Vector <@Phillip_Vector> wrote:

I tried that and trying to move away from it.

I have around 20-40 players logged into the chat at once. Even at 10
seconds, it basically DDOSs my server.

On Sun, Feb 12, 2017 at 6:26 PM, Joseph Gooch <@Joseph_Gooch> wrote:

If you just want it to rerun the page every 3 seconds, why not put a
jQuery.ajax call in a Javascript setInterval? :slight_smile:

-G

On Sun, Feb 12, 2017 at 11:58 AM, Phillip Vector < @Phillip_Vector> wrote:

I put in the close to see what the error was. It only triggers if the
call

returns an error.

So it isn’t rerunning the page every 3 seconds? Damm. I may have to work
out Node.js and connect.io then.

On Feb 12, 2017 05:36, “Joseph Gooch” <@Joseph_Gooch> wrote:

I’ve never used SSE’s so I’m flying a little blind here… but:
https://www.html5rocks.com/en/tutorials/eventsource/basics/
That example doesn’t have .close

Code here:

https://github.com/html5rocks/www.html5rocks.com/tree/
master/content/tutorials/eventsource/basics/static/demo

The Javascript around line 227:

https://github.com/html5rocks/www.html5rocks.com/blob/
master/content/tutorials/eventsource/basics/static/demo/sse.html

No close.

I do not believe you want the source.close(). If you do that, the
browser will not reconnect. (You’re closing the stream)

So that’s the client side. :slight_smile:

Now if you look at the server side…

https://github.com/html5rocks/www.html5rocks.com/blob/
master/content/tutorials/eventsource/basics/static/demo/sse.php

Check out the busy loop. With flushing.

The whole point of a SSE stream would be to have a long running
connection, during which you could periodically send updated data
packets as

they happen… From ACF or Lucee’s perspective - that’s one single cfm
call.

So you’d need to do the busy waiting yourself. The browser reconnects
automatically/maybe with a 3 sec delay - that’s just to work around
servers

that are used to a transactional HTTP connection that closes, or
aggressive

firewalls with short connection timeouts, or transitory network issues.

It’s possible you have an extension, or you’re using a feature of Lucee
I’m not aware of… But just going by how CF works - Lucee’s not going
to

know your data has changed. There’s no way Lucee could poll your CFM
and

know that the content changed, and then issue an update… Lucee would
have

to know that request connection would need to stay open, and it would
have

to poll your backend datasource, not your filesystem, and ultimately,
the

cfm is generating dynamic output - so it would have to RUN the cfm
before it

knew there was a change. The logic to know there’s a change (i.e. new
message) and send it would have to be in your wait loop.

If you’re really just sending, say, all the new messages received for
that session since the last poll - at that point you might as well use
XHR.

If you don’t have a long running request, the client is polling anyway.

http://socket.io goes through the chat room pretty thoroughly - they
use

websockets, which introduces other challenges. (or long polling -
which is

similar to what SSE is doing)

-G

On Sun, Feb 12, 2017 at 1:52 AM, Phillip Vector <@Phillip_Vector> wrote:

You’d want to throw a cfflush in there

Tried that. No luck. Though I will try again.

And then enter some sort of busywait loop or sleep cycle to retrieve
more server messages from your producer and output them with a
cfflush

following to your consumer.(javascript). Possibly with : comments
every

10-15 seconds to keep any agressive firewalls happy.

It was my understanding that I didn’t need to keep rechecking as the
server pings the file and (I thought) that if the output changes, it
pushes the changes to the client. If I remove the .close(), it keeps
checking every 3 seconds or so.

Plus you’ll run into the requesttimeout. So you’ll want to increase
that w/ cfsetting.

nods Ok. I’ll keep that in mind.

Any reason you’re doing this instead of leveraging something like
rabbitmq+STOMP?

Because my javascript sucks and this seemed like the easiest thing to
implement (HA!) for a set of chat rooms I’m trying to change from the
clients pinging the server every 10 seconds and this seemed like a
viable option. I’m currently trying to get into connect.io and
node.js, but I’m feeling lost and confused and such as my knowledge of
javascript is limited to basic jQuery stuff.

On Sat, Feb 11, 2017 at 6:49 PM, Joseph Gooch < @Joseph_Gooch> wrote:

Trying again…grr ipad

If thats all you have in the cfm, then you’re not keeping the
connection
open…

You’d want to throw a cfflush in there

And then enter some sort of busywait loop or sleep cycle to retrieve
more
server messages from your producer and output them with a cfflush
following
to your consumer.(javascript). Possibly with : comments every 10-15
seconds
to keep any agressive firewalls happy.

Plus you’ll run into the requesttimeout. So you’ll want to increase
that w/
cfsetting.

Any reason you’re doing this instead of leveraging something like
rabbitmq+STOMP?
-G

On Sat, Feb 11, 2017 at 12:14 PM Phillip Vector <@Phillip_Vector> wrote:

I know this isn’t a javascript group, but I’m wondering if there is
something specific to Lucee that is causing this issue (and if you
know about SSE’s and can provide why this isn’t working, so much
the

better).

So I have the following code in the javascript of the page.

and on the server side, I have this…

data: Hello World!\n\n

I copied this from a few websites around the web and as I can see
it,

logically, this should work. However, when I run it, I get an
error.

It opens up correctly, but I get an error and close.

The error is multi-layered and I am boggled by what I should be
looking for 6 layers deep.

If someone can please point me to where I am going wrong, it would
be

very appreciated. It loads ok and it keeps refreshing (when I
remove

the “source.close()”)… I just don’t see anything on the screen.
It’s
fully blank (source shows the javascript and the div unfilled).


You received this message because you are subscribed to the Google
Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it,
send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/
CANmAeAxTKPChZ9pCnDT0t1WGB0N%3D2a%2BXO97d4QGx_tMh_BdLEA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google
Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it,
send

an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/CAKY58c5Z1OWKVFZs1%3De%
3Do1S10J8fg-N71ZUMRPZ3xkrJcDcydQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google
Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CANmAeAyMzkq16_
zYv5fWajUEwTgYR0iTCu4xwr9O1og%2BDSuc%3DQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google
Groups

“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an

email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAKY58c7wYenDfBVbEetO4Ousm%
3DBvbJVvfjxmOUj%3D%3D3P9H_M7rA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google
Groups

“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an

email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CANmAeAzNdB0vv9PCGw63PX%
3DPgCOxS1ZY5q8poFNr7T161icbZw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAKY58c4pPqN8KcUaiFTvK-PZtJzp_
HcN-5RZ_HxPX_%2BB2%3Diqew%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/
msgid/lucee/CANmAeAwBgAxNnfL2pR13GxC4M%3D6MtYF%2BdFovKKBqwHZXvKRNrg%
40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

If you just want it to rerun the page every 3 seconds, why not put a
jQuery.ajax call in a Javascript setInterval? :slight_smile:

-GOn Sun, Feb 12, 2017 at 11:58 AM, Phillip Vector <@Phillip_Vector> wrote:

I put in the close to see what the error was. It only triggers if the call
returns an error.

So it isn’t rerunning the page every 3 seconds? Damm. I may have to work
out Node.js and connect.io then.

On Feb 12, 2017 05:36, “Joseph Gooch” <@Joseph_Gooch> wrote:

I’ve never used SSE’s so I’m flying a little blind here… but:
https://www.html5rocks.com/en/tutorials/eventsource/basics/
That example doesn’t have .close

Code here:
https://github.com/html5rocks/www.html5rocks.com/tree/master
/content/tutorials/eventsource/basics/static/demo

The Javascript around line 227:
https://github.com/html5rocks/www.html5rocks.com/blob/master
/content/tutorials/eventsource/basics/static/demo/sse.html

No close.

I do not believe you want the source.close(). If you do that, the
browser will not reconnect. (You’re closing the stream)

So that’s the client side. :slight_smile:

Now if you look at the server side…
https://github.com/html5rocks/www.html5rocks.com/blob/master
/content/tutorials/eventsource/basics/static/demo/sse.php

Check out the busy loop. With flushing.

The whole point of a SSE stream would be to have a long running
connection, during which you could periodically send updated data packets
as they happen… From ACF or Lucee’s perspective - that’s one single cfm
call. So you’d need to do the busy waiting yourself. The browser
reconnects automatically/maybe with a 3 sec delay - that’s just to work
around servers that are used to a transactional HTTP connection that
closes, or aggressive firewalls with short connection timeouts, or
transitory network issues.

It’s possible you have an extension, or you’re using a feature of Lucee
I’m not aware of… But just going by how CF works - Lucee’s not going to
know your data has changed. There’s no way Lucee could poll your CFM and
know that the content changed, and then issue an update… Lucee would have
to know that request connection would need to stay open, and it would have
to poll your backend datasource, not your filesystem, and ultimately, the
cfm is generating dynamic output - so it would have to RUN the cfm before
it knew there was a change. The logic to know there’s a change (i.e. new
message) and send it would have to be in your wait loop.

If you’re really just sending, say, all the new messages received for
that session since the last poll - at that point you might as well use
XHR. If you don’t have a long running request, the client is polling
anyway.

http://socket.io goes through the chat room pretty thoroughly - they use
websockets, which introduces other challenges. (or long polling - which is
similar to what SSE is doing)

-G

On Sun, Feb 12, 2017 at 1:52 AM, Phillip Vector < @Phillip_Vector> wrote:

You’d want to throw a cfflush in there

Tried that. No luck. Though I will try again.

And then enter some sort of busywait loop or sleep cycle to retrieve
more server messages from your producer and output them with a cfflush
following to your consumer.(javascript). Possibly with : comments every
10-15 seconds to keep any agressive firewalls happy.

It was my understanding that I didn’t need to keep rechecking as the
server pings the file and (I thought) that if the output changes, it
pushes the changes to the client. If I remove the .close(), it keeps
checking every 3 seconds or so.

Plus you’ll run into the requesttimeout. So you’ll want to increase
that w/ cfsetting.

nods Ok. I’ll keep that in mind.

Any reason you’re doing this instead of leveraging something like
rabbitmq+STOMP?

Because my javascript sucks and this seemed like the easiest thing to
implement (HA!) for a set of chat rooms I’m trying to change from the
clients pinging the server every 10 seconds and this seemed like a
viable option. I’m currently trying to get into connect.io and
node.js, but I’m feeling lost and confused and such as my knowledge of
javascript is limited to basic jQuery stuff.

On Sat, Feb 11, 2017 at 6:49 PM, Joseph Gooch <@Joseph_Gooch> wrote:

Trying again…grr ipad

If thats all you have in the cfm, then you’re not keeping the
connection
open…

You’d want to throw a cfflush in there

And then enter some sort of busywait loop or sleep cycle to retrieve
more
server messages from your producer and output them with a cfflush
following
to your consumer.(javascript). Possibly with : comments every 10-15
seconds
to keep any agressive firewalls happy.

Plus you’ll run into the requesttimeout. So you’ll want to increase
that w/
cfsetting.

Any reason you’re doing this instead of leveraging something like
rabbitmq+STOMP?
-G

On Sat, Feb 11, 2017 at 12:14 PM Phillip Vector < @Phillip_Vector> wrote:

I know this isn’t a javascript group, but I’m wondering if there is
something specific to Lucee that is causing this issue (and if you
know about SSE’s and can provide why this isn’t working, so much the
better).

So I have the following code in the javascript of the page.

and on the server side, I have this…

data: Hello World!\n\n

I copied this from a few websites around the web and as I can see it,
logically, this should work. However, when I run it, I get an error.
It opens up correctly, but I get an error and close.

The error is multi-layered and I am boggled by what I should be
looking for 6 layers deep.

If someone can please point me to where I am going wrong, it would be
very appreciated. It loads ok and it keeps refreshing (when I remove
the “source.close()”)… I just don’t see anything on the screen. It’s
fully blank (source shows the javascript and the div unfilled).


You received this message because you are subscribed to the Google
Groups

“Lucee” group.
To unsubscribe from this group and stop receiving emails from it,
send an

email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CANmAeAxTKPChZ9pCnDT
0t1WGB0N%3D2a%2BXO97d4QGx_tMh_BdLEA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google
Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAKY58c5Z1OWKVFZs1%3
De%3Do1S10J8fg-N71ZUMRPZ3xkrJcDcydQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google
Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/ms
gid/lucee/CANmAeAyMzkq16_zYv5fWajUEwTgYR0iTCu4xwr9O1og%2BDSu
c%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/ms
gid/lucee/CAKY58c7wYenDfBVbEetO4Ousm%3DBvbJVvfjxmOUj%3D%
3D3P9H_M7rA%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAKY58c7wYenDfBVbEetO4Ousm%3DBvbJVvfjxmOUj%3D%3D3P9H_M7rA%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/
msgid/lucee/CANmAeAzNdB0vv9PCGw63PX%3DPgCOxS1ZY5q8poFNr7T161icbZw%
40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CANmAeAzNdB0vv9PCGw63PX%3DPgCOxS1ZY5q8poFNr7T161icbZw%40mail.gmail.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

Here’s a really basic example.
https://github.com/goochjj/ChatApp

Clone, box server start, and browse to /chat/index.cfm

Each tab is a different “client” guid.
Type something in the text area and hit send, and you’ll see it back on
your screen, and every other tab too.

Open the chrome dev tools, and you’ll see a long-running request to
messages.cfm that never dies. (hopefully) It just sends data as it’s
available.

sendmsg is a simple ajax call to send a new message.

I’m using in-memory java LinkedBlockingQueues to do the concurrency,
intelligent locking between requests, etc.
https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/LinkedBlockingQueue.html

This also means the messages only exist in memory, and only on a single
server instance.

Ultimately what you’re doing lends itself to a messaging structure.
(Several queues of one to many broadcasting) The javascript pattern here
is also based on messaging and queueing…

In this case there’s no polling. .take() waits until there’s a message. I
don’t have to implement that logic. Internally it’s probably a java
semaphore or condition object. I’m using a structure to track room
“members”, and looping over queues to inject messages. So sendmsg has the
broadcast semantics. Queues are essentially one per client. No polling
because Java’s handling it internally.

Using a backend like a database means you’re going to have to poll
somewhere. It might be in lucee, it might be having the browser poll the
server… You should determine what your server can’t handle. 40req/3sec
doesn’t sound all that onerous. Unless every request is pulling the entire
table, maybe you need to refine your queries.

If the problem is pulling from the database, or network RTT, then moving
the polling server-side may help that, but you’re still going to have a
loop something like

Loop forever {
query mysql for new messages for my client
Got some? Cool. Output to client (cfoutput, pkt like I did) for as many
as there are
Sleep for some reasonable amount of time
}

(Because, AFAIK, MySQL doesn’t have something similar to MSSQL’s Service
Broker to do message queueing, and things like WAITFOR CONVERSATION)

At least looping server side means you have the control server side to make
sure the polling is on your terms. And still there’s going to be some sort
of requesttimeout to contend with, at which point, yes, the browser should
reconnect to the stream.

Inherent in this too is remembering the last message the client saw… so
you may need to retrieve state before the loop, update state throughout the
loop… so you don’t rebroadcast messages they’ve already seen.

Or when you first generate the page, you don’t use the eventsource… you
render what they should see, and from that point use the event source for
near-realtime delivery. (It’ll never be truly realtime with polling)
There are tons of options.

One option would be to use an actual messaging platform. Jabber/GChat or
roll your own messaging with RabbitMQ or similar. Socket.io on the client
side, STOMP on Rabbit, manage your channels, good to go. Which is more
like what I’d do - use the right technology for the right problem.

https://github.com/lmajano/messaging-polyglot
with
https://github.com/goochjj/docker-rabbitmq-ssl-stomp

Would be suitable to start playing.

-GOn Sun, Feb 12, 2017 at 9:55 PM, Phillip Vector <@Phillip_Vector> wrote:

I am storing incoming messages in a MySQL database with a “RoomID”
code set. When someone is in the “Chat” function, it queries the
database using a where for the roomID the player is in and gives a
list of messages they can see. I then replace a div area with the list
of messages after formating.

On Sun, Feb 12, 2017 at 6:32 PM, Joseph Gooch <@Joseph_Gooch> wrote:

How are you storing and distributing the messages? How do you organize
them
in chat rooms and determine who needs to receive what message?

-G

On Sun, Feb 12, 2017 at 9:30 PM, Phillip Vector < @Phillip_Vector> wrote:

I tried that and trying to move away from it.

I have around 20-40 players logged into the chat at once. Even at 10
seconds, it basically DDOSs my server.

On Sun, Feb 12, 2017 at 6:26 PM, Joseph Gooch <@Joseph_Gooch wrote:

If you just want it to rerun the page every 3 seconds, why not put a
jQuery.ajax call in a Javascript setInterval? :slight_smile:

-G

On Sun, Feb 12, 2017 at 11:58 AM, Phillip Vector <@Phillip_Vector> wrote:

I put in the close to see what the error was. It only triggers if the
call
returns an error.

So it isn’t rerunning the page every 3 seconds? Damm. I may have to
work
out Node.js and connect.io then.

On Feb 12, 2017 05:36, “Joseph Gooch” <@Joseph_Gooch> wrote:

I’ve never used SSE’s so I’m flying a little blind here… but:
https://www.html5rocks.com/en/tutorials/eventsource/basics/
That example doesn’t have .close

Code here:

https://github.com/html5rocks/www.html5rocks.com/tree/
master/content/tutorials/eventsource/basics/static/demo

The Javascript around line 227:

https://github.com/html5rocks/www.html5rocks.com/blob/
master/content/tutorials/eventsource/basics/static/demo/sse.html

No close.

I do not believe you want the source.close(). If you do that, the
browser will not reconnect. (You’re closing the stream)

So that’s the client side. :slight_smile:

Now if you look at the server side…

https://github.com/html5rocks/www.html5rocks.com/blob/
master/content/tutorials/eventsource/basics/static/demo/sse.php

Check out the busy loop. With flushing.

The whole point of a SSE stream would be to have a long running
connection, during which you could periodically send updated data
packets as
they happen… From ACF or Lucee’s perspective - that’s one single
cfm

call.
So you’d need to do the busy waiting yourself. The browser
reconnects

automatically/maybe with a 3 sec delay - that’s just to work around
servers
that are used to a transactional HTTP connection that closes, or
aggressive
firewalls with short connection timeouts, or transitory network
issues.

It’s possible you have an extension, or you’re using a feature of
Lucee
I’m not aware of… But just going by how CF works - Lucee’s not
going

to
know your data has changed. There’s no way Lucee could poll your
CFM

and
know that the content changed, and then issue an update… Lucee
would

have
to know that request connection would need to stay open, and it
would

have
to poll your backend datasource, not your filesystem, and
ultimately,

the
cfm is generating dynamic output - so it would have to RUN the cfm
before it
knew there was a change. The logic to know there’s a change (i.e.
new

message) and send it would have to be in your wait loop.

If you’re really just sending, say, all the new messages received
for

that session since the last poll - at that point you might as well
use

XHR.
If you don’t have a long running request, the client is polling
anyway.

http://socket.io goes through the chat room pretty thoroughly -
they

use
websockets, which introduces other challenges. (or long polling -
which is
similar to what SSE is doing)

-G

On Sun, Feb 12, 2017 at 1:52 AM, Phillip Vector <@Phillip_Vector> wrote:

You’d want to throw a cfflush in there

Tried that. No luck. Though I will try again.

And then enter some sort of busywait loop or sleep cycle to
retrieve

more server messages from your producer and output them with a
cfflush
following to your consumer.(javascript). Possibly with : comments
every
10-15 seconds to keep any agressive firewalls happy.

It was my understanding that I didn’t need to keep rechecking as
the

server pings the file and (I thought) that if the output changes,
it

pushes the changes to the client. If I remove the .close(), it
keeps

checking every 3 seconds or so.

Plus you’ll run into the requesttimeout. So you’ll want to
increase

that w/ cfsetting.

nods Ok. I’ll keep that in mind.

Any reason you’re doing this instead of leveraging something like
rabbitmq+STOMP?

Because my javascript sucks and this seemed like the easiest thing
to

implement (HA!) for a set of chat rooms I’m trying to change from
the

clients pinging the server every 10 seconds and this seemed like a
viable option. I’m currently trying to get into connect.io and
node.js, but I’m feeling lost and confused and such as my knowledge
of
javascript is limited to basic jQuery stuff.

On Sat, Feb 11, 2017 at 6:49 PM, Joseph Gooch <@Joseph_Gooch> wrote:

Trying again…grr ipad

If thats all you have in the cfm, then you’re not keeping the
connection
open…

You’d want to throw a cfflush in there

And then enter some sort of busywait loop or sleep cycle to
retrieve
more
server messages from your producer and output them with a cfflush
following
to your consumer.(javascript). Possibly with : comments every
10-15

seconds
to keep any agressive firewalls happy.

Plus you’ll run into the requesttimeout. So you’ll want to
increase
that w/
cfsetting.

Any reason you’re doing this instead of leveraging something like
rabbitmq+STOMP?
-G

On Sat, Feb 11, 2017 at 12:14 PM Phillip Vector <@Phillip_Vector> wrote:

I know this isn’t a javascript group, but I’m wondering if there
is
something specific to Lucee that is causing this issue (and if
you

know about SSE’s and can provide why this isn’t working, so much
the
better).

So I have the following code in the javascript of the page.

and on the server side, I have this…

data: Hello World!\n\n

I copied this from a few websites around the web and as I can
see

it,
logically, this should work. However, when I run it, I get an
error.
It opens up correctly, but I get an error and close.

The error is multi-layered and I am boggled by what I should be
looking for 6 layers deep.

If someone can please point me to where I am going wrong, it
would

be
very appreciated. It loads ok and it keeps refreshing (when I
remove
the “source.close()”)… I just don’t see anything on the
screen.

It’s
fully blank (source shows the javascript and the div unfilled).


You received this message because you are subscribed to the
Google

Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from
it,

send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/
CANmAeAxTKPChZ9pCnDT0t1WGB0N%3D2a%2BXO97d4QGx_tMh_BdLEA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the
Google

Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it,
send
an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/CAKY58c5Z1OWKVFZs1%3De%
3Do1S10J8fg-N71ZUMRPZ3xkrJcDcydQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google
Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it,
send
an email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/CANmAeAyMzkq16_
zYv5fWajUEwTgYR0iTCu4xwr9O1og%2BDSuc%3DQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google
Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it,
send

an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/CAKY58c7wYenDfBVbEetO4Ousm%
3DBvbJVvfjxmOUj%3D%3D3P9H_M7rA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google
Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it,
send

an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/CANmAeAzNdB0vv9PCGw63PX%
3DPgCOxS1ZY5q8poFNr7T161icbZw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google
Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/
CAKY58c4pPqN8KcUaiFTvK-PZtJzp_HcN-5RZ_HxPX_%2BB2%3Diqew%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google
Groups

“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an

email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CANmAeAwBgAxNnfL2pR13GxC4M%
3D6MtYF%2BdFovKKBqwHZXvKRNrg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAKY58c7qWBnY%
3D3Fc6XSrvjOeabVRxEAqC5eRHjqFh%2BPzDObR_w%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/
msgid/lucee/CANmAeAxcMQG0Ot8%3DuQU6LaWAqf3120M6ecNTnUuxqWLR
ZXn_Rw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

I am storing incoming messages in a MySQL database with a “RoomID”
code set. When someone is in the “Chat” function, it queries the
database using a where for the roomID the player is in and gives a
list of messages they can see. I then replace a div area with the list
of messages after formating.On Sun, Feb 12, 2017 at 6:32 PM, Joseph Gooch <@Joseph_Gooch> wrote:

How are you storing and distributing the messages? How do you organize them
in chat rooms and determine who needs to receive what message?

-G

On Sun, Feb 12, 2017 at 9:30 PM, Phillip Vector <@Phillip_Vector> wrote:

I tried that and trying to move away from it.

I have around 20-40 players logged into the chat at once. Even at 10
seconds, it basically DDOSs my server.

On Sun, Feb 12, 2017 at 6:26 PM, Joseph Gooch <@Joseph_Gooch> wrote:

If you just want it to rerun the page every 3 seconds, why not put a
jQuery.ajax call in a Javascript setInterval? :slight_smile:

-G

On Sun, Feb 12, 2017 at 11:58 AM, Phillip Vector <@Phillip_Vector> wrote:

I put in the close to see what the error was. It only triggers if the
call
returns an error.

So it isn’t rerunning the page every 3 seconds? Damm. I may have to
work
out Node.js and connect.io then.

On Feb 12, 2017 05:36, “Joseph Gooch” <@Joseph_Gooch> wrote:

I’ve never used SSE’s so I’m flying a little blind here… but:
https://www.html5rocks.com/en/tutorials/eventsource/basics/
That example doesn’t have .close

Code here:

https://github.com/html5rocks/www.html5rocks.com/tree/master/content/tutorials/eventsource/basics/static/demo

The Javascript around line 227:

https://github.com/html5rocks/www.html5rocks.com/blob/master/content/tutorials/eventsource/basics/static/demo/sse.html

No close.

I do not believe you want the source.close(). If you do that, the
browser will not reconnect. (You’re closing the stream)

So that’s the client side. :slight_smile:

Now if you look at the server side…

https://github.com/html5rocks/www.html5rocks.com/blob/master/content/tutorials/eventsource/basics/static/demo/sse.php

Check out the busy loop. With flushing.

The whole point of a SSE stream would be to have a long running
connection, during which you could periodically send updated data
packets as
they happen… From ACF or Lucee’s perspective - that’s one single cfm
call.
So you’d need to do the busy waiting yourself. The browser reconnects
automatically/maybe with a 3 sec delay - that’s just to work around
servers
that are used to a transactional HTTP connection that closes, or
aggressive
firewalls with short connection timeouts, or transitory network
issues.

It’s possible you have an extension, or you’re using a feature of
Lucee
I’m not aware of… But just going by how CF works - Lucee’s not going
to
know your data has changed. There’s no way Lucee could poll your CFM
and
know that the content changed, and then issue an update… Lucee would
have
to know that request connection would need to stay open, and it would
have
to poll your backend datasource, not your filesystem, and ultimately,
the
cfm is generating dynamic output - so it would have to RUN the cfm
before it
knew there was a change. The logic to know there’s a change (i.e. new
message) and send it would have to be in your wait loop.

If you’re really just sending, say, all the new messages received for
that session since the last poll - at that point you might as well use
XHR.
If you don’t have a long running request, the client is polling
anyway.

http://socket.io goes through the chat room pretty thoroughly - they
use
websockets, which introduces other challenges. (or long polling -
which is
similar to what SSE is doing)

-G

On Sun, Feb 12, 2017 at 1:52 AM, Phillip Vector <@Phillip_Vector> wrote:

You’d want to throw a cfflush in there

Tried that. No luck. Though I will try again.

And then enter some sort of busywait loop or sleep cycle to retrieve
more server messages from your producer and output them with a
cfflush
following to your consumer.(javascript). Possibly with : comments
every
10-15 seconds to keep any agressive firewalls happy.

It was my understanding that I didn’t need to keep rechecking as the
server pings the file and (I thought) that if the output changes, it
pushes the changes to the client. If I remove the .close(), it keeps
checking every 3 seconds or so.

Plus you’ll run into the requesttimeout. So you’ll want to increase
that w/ cfsetting.

nods Ok. I’ll keep that in mind.

Any reason you’re doing this instead of leveraging something like
rabbitmq+STOMP?

Because my javascript sucks and this seemed like the easiest thing to
implement (HA!) for a set of chat rooms I’m trying to change from the
clients pinging the server every 10 seconds and this seemed like a
viable option. I’m currently trying to get into connect.io and
node.js, but I’m feeling lost and confused and such as my knowledge
of
javascript is limited to basic jQuery stuff.

On Sat, Feb 11, 2017 at 6:49 PM, Joseph Gooch <@Joseph_Gooch> wrote:

Trying again…grr ipad

If thats all you have in the cfm, then you’re not keeping the
connection
open…

You’d want to throw a cfflush in there

And then enter some sort of busywait loop or sleep cycle to
retrieve
more
server messages from your producer and output them with a cfflush
following
to your consumer.(javascript). Possibly with : comments every 10-15
seconds
to keep any agressive firewalls happy.

Plus you’ll run into the requesttimeout. So you’ll want to
increase
that w/
cfsetting.

Any reason you’re doing this instead of leveraging something like
rabbitmq+STOMP?
-G

On Sat, Feb 11, 2017 at 12:14 PM Phillip Vector <@Phillip_Vector> wrote:

I know this isn’t a javascript group, but I’m wondering if there
is
something specific to Lucee that is causing this issue (and if you
know about SSE’s and can provide why this isn’t working, so much
the
better).

So I have the following code in the javascript of the page.

and on the server side, I have this…

data: Hello World!\n\n

I copied this from a few websites around the web and as I can see
it,
logically, this should work. However, when I run it, I get an
error.
It opens up correctly, but I get an error and close.

The error is multi-layered and I am boggled by what I should be
looking for 6 layers deep.

If someone can please point me to where I am going wrong, it would
be
very appreciated. It loads ok and it keeps refreshing (when I
remove
the “source.close()”)… I just don’t see anything on the screen.
It’s
fully blank (source shows the javascript and the div unfilled).


You received this message because you are subscribed to the Google
Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it,
send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/CANmAeAxTKPChZ9pCnDT0t1WGB0N%3D2a%2BXO97d4QGx_tMh_BdLEA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google
Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it,
send
an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/CAKY58c5Z1OWKVFZs1%3De%3Do1S10J8fg-N71ZUMRPZ3xkrJcDcydQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google
Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it,
send
an email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/CANmAeAyMzkq16_zYv5fWajUEwTgYR0iTCu4xwr9O1og%2BDSuc%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google
Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/CAKY58c7wYenDfBVbEetO4Ousm%3DBvbJVvfjxmOUj%3D%3D3P9H_M7rA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google
Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/CANmAeAzNdB0vv9PCGw63PX%3DPgCOxS1ZY5q8poFNr7T161icbZw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google
Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/CAKY58c4pPqN8KcUaiFTvK-PZtJzp_HcN-5RZ_HxPX_%2BB2%3Diqew%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CANmAeAwBgAxNnfL2pR13GxC4M%3D6MtYF%2BdFovKKBqwHZXvKRNrg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAKY58c7qWBnY%3D3Fc6XSrvjOeabVRxEAqC5eRHjqFh%2BPzDObR_w%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

Also it’s entirely possible you need both tech - MySQL for message history,
rendering the client at load, ability to search through history by keyword,
receipt of messages while not connected, scrollback buffers to see past
messages, etc. SSE/Websockets/Messaging Queues for realtime delivery of
new messages. (i.e. sendmsg would populate both the DB and the messaging
queues)

Depends on whether your chat is more like IRC (no history or search, only
realtime message delivery, history at the client level only) or Slack
(history, searching, offline delivery, and realtime messages)

-GOn Sun, Feb 12, 2017 at 10:41 PM, Phillip Vector <@Phillip_Vector> wrote:

Thank you for the advise. :slight_smile: This is enough I think to get me moving
in the right direction. :slight_smile:

On Sun, Feb 12, 2017 at 7:35 PM, Joseph Gooch <@Joseph_Gooch> wrote:

Here’s a really basic example.
https://github.com/goochjj/ChatApp

Clone, box server start, and browse to /chat/index.cfm

Each tab is a different “client” guid.
Type something in the text area and hit send, and you’ll see it back on
your
screen, and every other tab too.

Open the chrome dev tools, and you’ll see a long-running request to
messages.cfm that never dies. (hopefully) It just sends data as it’s
available.

sendmsg is a simple ajax call to send a new message.

I’m using in-memory java LinkedBlockingQueues to do the concurrency,
intelligent locking between requests, etc.
https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/
LinkedBlockingQueue.html

This also means the messages only exist in memory, and only on a single
server instance.

Ultimately what you’re doing lends itself to a messaging structure.
(Several
queues of one to many broadcasting) The javascript pattern here is also
based on messaging and queueing…

In this case there’s no polling. .take() waits until there’s a
message. I
don’t have to implement that logic. Internally it’s probably a java
semaphore or condition object. I’m using a structure to track room
“members”, and looping over queues to inject messages. So sendmsg has the
broadcast semantics. Queues are essentially one per client. No polling
because Java’s handling it internally.

Using a backend like a database means you’re going to have to poll
somewhere. It might be in lucee, it might be having the browser poll the
server… You should determine what your server can’t handle. 40req/3sec
doesn’t sound all that onerous. Unless every request is pulling the
entire
table, maybe you need to refine your queries.

If the problem is pulling from the database, or network RTT, then moving
the
polling server-side may help that, but you’re still going to have a loop
something like

Loop forever {
query mysql for new messages for my client
Got some? Cool. Output to client (cfoutput, pkt like I did) for as
many as
there are
Sleep for some reasonable amount of time
}

(Because, AFAIK, MySQL doesn’t have something similar to MSSQL’s Service
Broker to do message queueing, and things like WAITFOR CONVERSATION)

At least looping server side means you have the control server side to
make
sure the polling is on your terms. And still there’s going to be some
sort
of requesttimeout to contend with, at which point, yes, the browser
should
reconnect to the stream.

Inherent in this too is remembering the last message the client saw… so
you
may need to retrieve state before the loop, update state throughout the
loop… so you don’t rebroadcast messages they’ve already seen.

Or when you first generate the page, you don’t use the eventsource… you
render what they should see, and from that point use the event source for
near-realtime delivery. (It’ll never be truly realtime with polling)
There
are tons of options.

One option would be to use an actual messaging platform. Jabber/GChat or
roll your own messaging with RabbitMQ or similar. Socket.io on the
client
side, STOMP on Rabbit, manage your channels, good to go. Which is more
like
what I’d do - use the right technology for the right problem.

https://github.com/lmajano/messaging-polyglot
with
https://github.com/goochjj/docker-rabbitmq-ssl-stomp

Would be suitable to start playing.

-G

On Sun, Feb 12, 2017 at 9:55 PM, Phillip Vector < @Phillip_Vector> wrote:

I am storing incoming messages in a MySQL database with a “RoomID”
code set. When someone is in the “Chat” function, it queries the
database using a where for the roomID the player is in and gives a
list of messages they can see. I then replace a div area with the list
of messages after formating.

On Sun, Feb 12, 2017 at 6:32 PM, Joseph Gooch <@Joseph_Gooch wrote:

How are you storing and distributing the messages? How do you
organize

them
in chat rooms and determine who needs to receive what message?

-G

On Sun, Feb 12, 2017 at 9:30 PM, Phillip Vector <@Phillip_Vector> wrote:

I tried that and trying to move away from it.

I have around 20-40 players logged into the chat at once. Even at 10
seconds, it basically DDOSs my server.

On Sun, Feb 12, 2017 at 6:26 PM, Joseph Gooch <@Joseph_Gooch> wrote:

If you just want it to rerun the page every 3 seconds, why not put
a

jQuery.ajax call in a Javascript setInterval? :slight_smile:

-G

On Sun, Feb 12, 2017 at 11:58 AM, Phillip Vector <@Phillip_Vector> wrote:

I put in the close to see what the error was. It only triggers if
the
call
returns an error.

So it isn’t rerunning the page every 3 seconds? Damm. I may have
to

work
out Node.js and connect.io then.

On Feb 12, 2017 05:36, “Joseph Gooch” <@Joseph_Gooch> wrote:

I’ve never used SSE’s so I’m flying a little blind here… but:
https://www.html5rocks.com/en/tutorials/eventsource/basics/
That example doesn’t have .close

Code here:

https://github.com/html5rocks/www.html5rocks.com/tree/
master/content/tutorials/eventsource/basics/static/demo

The Javascript around line 227:

https://github.com/html5rocks/www.html5rocks.com/blob/
master/content/tutorials/eventsource/basics/static/demo/sse.html

No close.

I do not believe you want the source.close(). If you do that,
the

browser will not reconnect. (You’re closing the stream)

So that’s the client side. :slight_smile:

Now if you look at the server side…

https://github.com/html5rocks/www.html5rocks.com/blob/
master/content/tutorials/eventsource/basics/static/demo/sse.php

Check out the busy loop. With flushing.

The whole point of a SSE stream would be to have a long running
connection, during which you could periodically send updated data
packets as
they happen… From ACF or Lucee’s perspective - that’s one
single

cfm
call.
So you’d need to do the busy waiting yourself. The browser
reconnects
automatically/maybe with a 3 sec delay - that’s just to work
around

servers
that are used to a transactional HTTP connection that closes, or
aggressive
firewalls with short connection timeouts, or transitory network
issues.

It’s possible you have an extension, or you’re using a feature of
Lucee
I’m not aware of… But just going by how CF works - Lucee’s not
going
to
know your data has changed. There’s no way Lucee could poll your
CFM
and
know that the content changed, and then issue an update… Lucee
would
have
to know that request connection would need to stay open, and it
would
have
to poll your backend datasource, not your filesystem, and
ultimately,
the
cfm is generating dynamic output - so it would have to RUN the
cfm

before it
knew there was a change. The logic to know there’s a change
(i.e.

new
message) and send it would have to be in your wait loop.

If you’re really just sending, say, all the new messages received
for
that session since the last poll - at that point you might as
well

use
XHR.
If you don’t have a long running request, the client is polling
anyway.

http://socket.io goes through the chat room pretty thoroughly -
they
use
websockets, which introduces other challenges. (or long polling -
which is
similar to what SSE is doing)

-G

On Sun, Feb 12, 2017 at 1:52 AM, Phillip Vector <@Phillip_Vector> wrote:

You’d want to throw a cfflush in there

Tried that. No luck. Though I will try again.

And then enter some sort of busywait loop or sleep cycle to
retrieve
more server messages from your producer and output them with a
cfflush
following to your consumer.(javascript). Possibly with :
comments
every
10-15 seconds to keep any agressive firewalls happy.

It was my understanding that I didn’t need to keep rechecking as
the
server pings the file and (I thought) that if the output
changes,

it
pushes the changes to the client. If I remove the .close(), it
keeps
checking every 3 seconds or so.

Plus you’ll run into the requesttimeout. So you’ll want to
increase
that w/ cfsetting.

nods Ok. I’ll keep that in mind.

Any reason you’re doing this instead of leveraging something
like

rabbitmq+STOMP?

Because my javascript sucks and this seemed like the easiest
thing

to
implement (HA!) for a set of chat rooms I’m trying to change
from

the
clients pinging the server every 10 seconds and this seemed
like a

viable option. I’m currently trying to get into connect.io and
node.js, but I’m feeling lost and confused and such as my
knowledge
of
javascript is limited to basic jQuery stuff.

On Sat, Feb 11, 2017 at 6:49 PM, Joseph Gooch <@Joseph_Gooch> wrote:

Trying again…grr ipad

If thats all you have in the cfm, then you’re not keeping the
connection
open…

You’d want to throw a cfflush in there

And then enter some sort of busywait loop or sleep cycle to
retrieve
more
server messages from your producer and output them with a
cfflush
following
to your consumer.(javascript). Possibly with : comments every
10-15
seconds
to keep any agressive firewalls happy.

Plus you’ll run into the requesttimeout. So you’ll want to
increase
that w/
cfsetting.

Any reason you’re doing this instead of leveraging something
like
rabbitmq+STOMP?
-G

On Sat, Feb 11, 2017 at 12:14 PM Phillip Vector <@Phillip_Vector> wrote:

I know this isn’t a javascript group, but I’m wondering if
there
is
something specific to Lucee that is causing this issue (and
if

you
know about SSE’s and can provide why this isn’t working, so
much
the
better).

So I have the following code in the javascript of the page.

and on the server side, I have this…

data: Hello World!\n\n

I copied this from a few websites around the web and as I can
see
it,
logically, this should work. However, when I run it, I get an
error.
It opens up correctly, but I get an error and close.

The error is multi-layered and I am boggled by what I should
be

looking for 6 layers deep.

If someone can please point me to where I am going wrong, it
would
be
very appreciated. It loads ok and it keeps refreshing (when I
remove
the “source.close()”)… I just don’t see anything on the
screen.
It’s
fully blank (source shows the javascript and the div
unfilled).


You received this message because you are subscribed to the
Google
Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from
it,
send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/
CANmAeAxTKPChZ9pCnDT0t1WGB0N%3D2a%2BXO97d4QGx_tMh_BdLEA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the
Google
Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from
it,
send
an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/
CAKY58c5Z1OWKVFZs1%3De%3Do1S10J8fg-N71ZUMRPZ3xkrJcDcydQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the
Google

Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from
it,

send
an email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/CANmAeAyMzkq16_
zYv5fWajUEwTgYR0iTCu4xwr9O1og%2BDSuc%3DQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the
Google

Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it,
send
an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/
CAKY58c7wYenDfBVbEetO4Ousm%3DBvbJVvfjxmOUj%3D%3D3P9H_M7rA%40mail.gmail.com
.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google
Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it,
send
an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/CANmAeAzNdB0vv9PCGw63PX%
3DPgCOxS1ZY5q8poFNr7T161icbZw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google
Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it,
send
an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/
CAKY58c4pPqN8KcUaiFTvK-PZtJzp_HcN-5RZ_HxPX_%2BB2%3Diqew%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google
Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it,
send

an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/CANmAeAwBgAxNnfL2pR13GxC4M%
3D6MtYF%2BdFovKKBqwHZXvKRNrg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google
Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/CAKY58c7qWBnY%
3D3Fc6XSrvjOeabVRxEAqC5eRHjqFh%2BPzDObR_w%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google
Groups

“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an

email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CANmAeAxcMQG0Ot8%
3DuQU6LaWAqf3120M6ecNTnUuxqWLRZXn_Rw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAKY58c68gjOjqer43PT610FXXaoDJ
T%3De9ux4ReW2k7YS2%2B7M5Q%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/
msgid/lucee/CANmAeAyRt2aDSprXAnyrKFKkNpdFtoeAwgdzFAVNVdLKTuP_Rg%40mail.
gmail.com.
For more options, visit https://groups.google.com/d/optout.