Kody Wright

Ranch Hand
+ Follow
since Mar 06, 2011
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
1
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Kody Wright

Awesome...well I'm gonna jump into this then starting with the doc you linked. Your help has been
invaluable, thanks again!
8 years ago
Hey guys, thanks for the responses.

Maneesh, you raise a good point. I would like to not have to store the messages in a DB at all,
and now that you mention it the issue could very well simply be a perceived problem since I'm trying to
adapt that tutorial. If I'm understanding you correctly, you are saying that the server
(which could really just be a set of servlets?) would receive a message then utilize GCM to
send it to all connected users. So the java server would be using a GCM API to manage the
send/receive capabilites.

The logic in my head is:

// Receive message from user over GCM

// Validate message
validate(message);

// Use GCM to send to all connected users
GcmAPi.sendToAll(message);

Is that looking about right?

Ulf, thats a good suggestion that I could very well end up using, thanks for the idea!
8 years ago
Hey all,

I'm currently researching into building a large-scale chat app for android...and an issue came up that deals with the best practices for storing/retrieving the messages sent to/from the users. After a previous post here, I discovered the GCM service offered by Google. My plan was to utilize this service as the primary method of moving messages to the different clients. I found an excellent tutorial which works for a small number of users (http://www.appsrox.com/android/tutorials/instachat/7/#1), however it seems like there will be scaling issues if I try to adapt it to handle hundreds of users connected at the same time.

In the tutorial, the server that is being used to store/retrieve messages is utilizing a database to write new messages to, then reading those messages to send over GCM and then on the the client. The chat system I'm developing is intended to serve many more clients (100's) in one chat room where all the users can be communicating at the same time. However by adapting this tutorial that means that there could potentially be many more read/writes to the DB than intended in that article. This is where the best practices question comes in...

It seems to me that having a lot of constant read/writes to a db would impact performance negatively...but if this is the case then what alternative do I have? I'm still learning more about GCM, so it's possible that there is a solution I haven't found yet.

I appreciate your time!
8 years ago
That's exactly what I needed, you've really helped me out. Thanks a lot!
8 years ago

Maneesh Godbole wrote:

Kody Wright wrote:The system I'm developing will be responsible for maintaining mass connections (hundreds per server) in the same chat session.


That somehow doesn't sound right. 100s of connections per chat client? Maybe if you tell us what you are trying to do here, we can offer some suggestions.



Sure thing.

The overall idea is to develop a chat system where many users (say a hundred or so) are interacting in the same chat session simultaneously. So it would be like a group chat, just bigger.

I know that similar systems already exist, just perhaps not for a mobile environment...which is what I would like to do. This is why an efficient server is so important. It's not 100s of connections per client, but a hundred or so clients being connected to one chat box (server).
8 years ago
I had no idea about the Google App engine/Endpoints...that's really cool stuff. Perhaps I should approach the design from the android side first then figure exactly what the server needs to do.

Just FYI, I have a very rudimentary java client that I'm using to communicate/test the server with, so I have a rough idea of what the android app needs to do. When you talk about the plain servlets/JSON, would this get rid of the thread-per-connection issue? The system I'm developing will be responsible for maintaining mass connections (hundreds per server) in the same chat session.

So far it seems that the only way to avoid this is to either have the chat read/write into an SQL database (which seems like it would be ineffecient and slow) or implement some java NIO server functions (which apparently don't work well with the Android API).
8 years ago
Hey guys!

Quick question. I'm in the process of developing a java server/android client app. The server is nearly complete...it works using a thread-per-client approach. However this will not scale very well when dealing with many clients connecting at once. This lead me to research some server-side solutions. I came across Netty, as it seems to be what I'm looking for as far as the scalability issue is concerned. Before I get too far into finishing the server I'd like to get the core down and not have to go back later to re-design it after the fact.

Netty used to not be compatible with Android, but apparently since 3.3(ish) it has been. It is now at 4.0, however I couldn't really find any resources for learning how to implement it for an android client/ java server combo. Does anyone here have any experience in this area? If not, are there any resources that are out there which could help me to better understand and use Netty for this purpose?

Thanks for your time!
8 years ago
I am developing a server to handle chat requests and facilitate communication between other clients. So far things have worked well for the most part, but there is one issue in particular that I can't seem to figure out. I know that thousands of small servers like this have been written before so there must be a best practice of some sort to deal with this issue...I can't just seem to find it!

I'm using a fixed thread pool to manage the client connection threads to my server. As long as the amount of connections stay below the thread pool limit things work fine. However as soon as one client more than the thread pool size tries to join and send a message, a null pointer exception is thrown. I finally tracked it down to why it's being thrown but can't think of how to get around it. Currently, every time a new client joins they are
added to a client list (a list of clientDevice objects). When a client sends a message, my server iterates through that list and prints out the message to each one. However, if the amount of clients in the list exceeds
the active threads in the pool, then my server tries to send a message to a thread that isn't active, thus causing the null pointer exception.

There are two possible solutions I've thought of so far:

1) Find a way to iterate through the active threads in the pool and remove the client list all together I like this idea better, but can't for the life of me find out how to do this (or if it's even possible)

2) Only allow clients to connect long as the amount of currently connected clients does not exceed the thread pool limit. I don't like this solution because it would negate one of the benefits of using a thread pool (the thread queue) and also it seems a little hack-ish to me

I debated between putting this in the Threads section of the forums but ultimately thought I belonged better here since I'm seeking a socket-related suggestion. If I made the wrong choice feel free to move this over to the appropriate section. : )

Can anyone help me out? Thanks for your time and thoughts. Also, I can put up some code examples tomorrow if needed.
Alright I'll be sure to give those ideas a try, thanks for the reply!
My question deals with properly using a fixed thread pool to manage the client connections to my server. I am in the process of writing a fairly simple Java chat server. It works for the most part, but as soon as the number of client connections exceeds my fixed pool thread limit things start behaving oddly.

For example, I created the fixed pool thread and set it to 2 connections. So long as only 2 clients connect everything works fine and dandy...but as soon as client 3 comes in then he is put on hold (like I expected)...however when client 2 sends a message he is disconnected (or placed into the thread pool queue, I can't tell) and client 3 now assumes his place. Client 1 is always working fine.

I intended for client 3 to be put on hold indefinitely until client 1 or client 2 disconnect...but apparently I am not understanding the fixed thread pool correctly. I currently have it set to where a clients thread will end once he sends "@STOP" to the server...this is the point where I would expect client 3 to gain access since client 2's thread is no longer being used. What exactly am I doing wrong?

Thanks for your time!

Here are the two main classes involved:

The client



The server

My question involves stopping a thread within an executor's fixed thread pool. Currently, I have
a small server which genereates a new 'client device' thread each time someone connects. The new
thread is started within the executor and everything seems to be working fine there, however when
someone disconnects I am having issues ending that thread. I'll attach the two classes involved here
so you can see what I am trying to do. Essentially I need to close and thread (so it can be used by
another client) whenenver someone disconnects...however I can't figure how to go about this.

Right now I have it set up to where a synchronized array list is keeping track of the clients
currenly connected. I realize that this may not be necessary since the fixed thread pool is also
holding all of the clients' threads, I'm just using it to keep the GUI updated. I feel like there
is some block of thread pool knowledge that I'm missing, but the API doesn't seem to list any methods
for ending a single thread within a pool, only the pool itself, which isn't what I need.

FYI: the only reason that MAX_CONNECTIONS_ALLOWED is set to 1 is for testing purposes.



Hello,

I started a thread on this forum last week about dealing with client/server connections and starting a new thread
each time a client connected. Jayesh A Lalwani helped me in solving the issue and then gave me some suggestions
about how I could improve the design, which I greatly appreciated.

After doing some research on thread pools I tried to implement them into my program and succeeded...partially. I
have a few questions regarding the appropriate use of thread pools and was hoping someone more experienced here
could help me understand them a little better.

Firstly, my RejectedExecutionException handler is not catching the error whenever I try to connect an additional
client...instead the second client will simply hang.

Secondly, if I connect two clients, the first one will connect and function correctly. The second one will accept
and send text but will not receive anything since it is waiting in the que...however if I send a message with the
second client while it is waiting then proceed to send a message with the first client suddenly both clients will
receive the messages and start functioning correctly. How can this happen?

Thirdly, how can I stop an individual thread that exists within an executor while leaving the other threads alone?

I appreciate your time and help!



Jayesh A Lalwani wrote:Do you have the client code? Is the client making a new connection everytime it sends a message? Looking at your code, it seems to me like the problem will happen when client opens a new connection for every message



You were right on, it was flawed client logic...not server. Thanks for the insightful reply!
Hello guys,

I'm currently having an issue when trying to build a server that allows for different clients to connect and
send messages to eachother.

What I'm wanting the code to do:
When a new client connects to the server (accept() call on line 73 in Server.java) a thread is spawned for
that client and handles the input/output. If a new client connects, then another thread is spawned and
the process repeats.

Here's my problem:

Whenever a new client device thread is started it should get stuck in the while(true) loop
theoretically waiting for the client to send his next message. The problem arises when the same client sends a new message...instead of the
new message being handeled by the thread that is already running for that device, another new thread is started and the old one just
sits there taking up resources but not doing anything.

I know that I've messed up my logic somewhere...I'm just not sure exactly where. I appreciate any help that a more
experienced eye may offer.

Thanks for your time!


Hello all,

I am working my way through the book "Teach Yourself Android Application Development in 24 hours", and am currently on hour 8. I've run across a slight problem that I can't seem to figure out.

I am trying to use the onCreateOptionsMenu method to display an options menu in a particular activity. I am trying to load the gameoptions.xml file, located in the "/res/menu" folder. For whatever reason, it is not recognizing that there is a file there by that name and subsequently not seeing the two items I have stored in it. I'll post the code below so you can see exactly what I'm doing.

I have restarted eclipse and tried renaming the files in an effort to fix the problem, but it still shows as an error. Could this be an eclipse problem rather than a code problem?



...and here is the xml file itself, gameoptions.xml



Thank you for your time!
9 years ago