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).
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).
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?
-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:
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
–
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
Thank you for the advise. 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:
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.
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?
-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:
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
–
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
–
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
–
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
–
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
–
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
–
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
–
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
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
–
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
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).
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.
with
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?
-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:
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
–
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
–
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
–
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
–
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
–
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
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?
-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:
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
–
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
–
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
–
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
–
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
–
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
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. 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:
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. JDK 20 Documentation - Home
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.
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?
-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:
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
–
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
–
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
–
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
–
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
–
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
–
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
–
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
