Just wondering what the common solution is for this. We have two web servers that are load balanced and a separate server that holds our images. Our current process is that a user uploads an image directly to the web server (which ever they are connected to) and we enter a job into our DB. Another process checks for image jobs every few mins and copies the image from the web server up to the image server.
The delay from when a user uploads to when its visible is not ideal. We could tighten the loop on how often we check for image jobs but ideally I would like to have user uploaded images to go directly to the image server rather than copying twice. How should this be done? Is there anything in spring to deal with this ? Seems like how most would deal with a CDN i would think?
I want to limit the time it takes for an image that a user uploads is available on our site...
Just give the webapp direct access to the imageserver so that it can instantly save the image on the image server. I don't see how that forms a problem.
You could insert the image on upload into your db. When the image is requested and it is not in the filesystem, you then can deliver it from db and at the same time sync it to the filesystem. If you don't want to hold all images in the db, you then could also delete it from there in the same step.
Related
I am currently working with Fragments, one of my fragments is "User Profile" where the signed in user can edit and view their own profile. One of the requirements for this university project is that the user needs to be able to upload a profile picture and it should be allocated to their user profile and saved on the server (I am currently using Lampp on linux). I have the following questions:
When a user uploads an image using the Volley library (Android) does it first need to save the relative/absolute path of the image to the MySQL database, and then use this information to get the image in JSON format back onto the device, where it shall be cached?
I read online that the Volley library can cache images and videos on the device, which would help data consumption so the user doesn't need to download the image(s) every time they login again. But what if the user logs into the application from say an IOS device and uploads an image there and then they come back to the Android device and logs in there - the app needs to update their user profile.
My thinking was every time a new Image is uploaded to the server the time it was uploaded would be added to a Date/Time slot in the DB, then this time is stored is the SQlite DB and the MySQL DB, every time they open the application it makes a request to the MySQL DB requesting this time field and if no images have been added then the SQLite time and the one just pulled from the MySQL database will be the same so no need to download any images - I thought this would be a simple way of checking without using a lot of data? or is there a better option someone could suggest.
However, the problem with my above suggestion is say for example there are 5 images cached on the device, but a 6th one was added from another device, when we go back to the original device how do we only download the new image? and not all of the other 5 also which are already in the cache?
I think you need to store in db not path to image file, but URI that you pass into Volley. And then, when you want to show image pass saved URI in Volley and it will decide show cached image or upload from internet.
Good thoughts. I think in your case you can just show data cached in dp, and then additionally fetch data from server, and it was changed cache it and show new results. Also you can implements long polling, or sockets, or GCM to set up connection with server and fetch new updated data immediatelly (in real cases not immediatelly but faster then "go to app -> check from request if there was changes in server side").
And of course, please have a look to firebase tutorials to think about implementing on your server side this thing and provide more interesting and covenient connection with immediate update of your local cached data. additional link to video tutroial
I have a image placed in a jsp. I have the image kid.jpg downloaded and kept in /resources/images folder. The below is the code snippet.
<li style="background-image: url('resources/images/kid.jpg');">
Now my web app is up and running. How to give end user to change that image/ upload a different image in that place. The same with the text in a div.
I am not getting the data from database and adding to the div dynamically.
Is database communication only way in such cases or any other way? I see many web sites contents are changing day by day. Are they modifying the webpages and replacing the existing files/ are they getting the data from database?
Please suggest how to achieve such scenarios.
Thanks
If There is no database on server and you want to allow all users ( unregistered ) to change a specific image, then what you can do is :- store the image file name in cookie, and on server check every time for that cookie, and if does not exists and render the same output with default image, other wise use that cookie's file_name image , and then on client side you can provide a facality to users to select images from particulers images that reside on server, and when user select some image so save that file name in cookie :) , Sorry for spelling mistakes, It's just a overview of solution of your problem :)
I'm porting an old Java project to GAE. It has some servlets, which generate html pages with static images in them. In the original project these images are stored on the filesystem next to the servlets.
I'm trying to use GCS in the first place, I've uploaded my files and gave permissions on public read. In this case I can reach the files with their public link, I can embed these links into the HTML output. But I have a feeling that this isn't the right solution. The load time seems quite slow, like the images don't "travel internally", and I have to provide permission for every single image.
So my question is, how to get an "internal" URL for a file located on GCS in your GAE application?
I've found some Java examples, but in my case I don't think I need the image object in the source, I just need an URL to pass it on to the HTML source.
As far as I know I could just simple deploy the images with the source as resources, but there are quite many of them.
If there are other soultions, like Datastore, I'm open for that too, but I thought GCS would be the easiest.
Google Cloud Storage is as fast an option for loading images as any other. A browser reads a link and asks the server (in this case GCS) to deliver an image. There is no "internal" URL that can work faster - the speed reflects the bandwidth/distance between GCS and the browser which asked for an image.
You can speed it up by using a CDN, where your image is stored on local servers throughout the world. It only makes sense if you serve content to a very large number of users, and it is a critical part of how fast a page loads.
Another way to speed up page load time is to use image sprites instead of images. This way you cut the number of requests from a browser to a server (i.e. GCS). If you images do not change frequently, and most pages need the same "collection" of images (i.e. not shown dynamically), this is a very good solution.
I'm looking for some critique on my approach for storing the state of a bitmap editor for Android and iPhone mobile phones. Even a "Looks fine to me!" response would be great!
In the application, the current user document contains several bitmap layers (each maybe 1024 by 768 pixels) that can each be painted on. The basic requirements for the application are:
I need to be able to save and restore the document state.
When the user quits the application or gets a phone call, I need to be able to save the document state quickly (within about 2 seconds).
If the application crashes, I need to be able to restore the document state (it's OK if the user loses maybe 30 seconds of work though).
For 1, I cannot find any open file formats that support layers. I was going to go with the following file structure for storing my document:
document_folder/
layer1.png
layer2.png
...
metadata.xml
The layers are just stored as .png files and the .xml file contains data such as which layers are currently visible. The document folder can either be opened as is by the application or the folder can be stored in a .zip file. This seems like a nice simple format for other applications to work with too.
In addition to .png files, I will also allow layers to be saved in a custom .raw file format which contain unprocessed raw pixel data from bitmaps. I can save these very quickly on the phone (<0.5s) whereas .png files take a second or two.
My plan for quick-saving the document was, on start-up, to create a folder called /autosave, and save .raw versions of all the layers there. After a few editing commands on one layer, I would then update the .raw file for that layer in a background thread. For robustness when saving, I would save the layer as e.g. layer1_tmp.raw and when I've confirmed the file has been fully written, replace layer1.raw with this file.
Should the application crash during use, I would just reopen the /autosave folder. When the application is closed or the user gets a phone call, I just have to update the last modified layer to autosave. When the user wants to save, I just convert all the .raw files to .png files and then zip the folder.
What do you think? Are there any obvious flaws? Is there a simpler way? Am I reinventing the wheel somehow? Thanks.
Your idea souds good to me: save the layers in the background, as you go. Any layer that the user isn't currently editing should be queued to be saved as soon as they switch away from it to a different layer. If the app is interrupted, you just have to save the current working layer, which as you say can be done in 0.5s.
Why bother with the png format anyway? You only need it if exporting data to another machine/system, right?
I think you have a great plan there. I would probably go the same way (but that itself doesn't mean anything :-)
What I was thinking is if you could have not only a worker thread saving the file but a complete background service (with a worker thread of course, since a service itself also runs in the main thread).
This way you would have guaranteed that there is always something alive that can handle your layer deltas, regardless if the drawing activity has crashed or someone is calling you. Suddenly you don't have the same timing constraints (the write operation can take 10 seconds if it wants to, your activity is neither blocked, nor dependent of the write operation). Of course your service would then commit suicide when it has emptied its save queue (to save system resources).
What I don't know in order to further promote this idea is how much data you're writing to the raw-file? Do you write the complete 1024x768 layer every time or do you only rewrite the changed parts? I'm also unsure of how the data would actually be transmitted to the service (from the Activity). I don't know if there is a maximum size of a byte-array-extra an Intent can handle.
Hope this gives you further ideas.
Cheers!
I am preparing a J2ME application,
Which is basically data capturing utility, Which reads data from end user from form and the data will be submitted to server as the application will get connection.
I am planning to capture photo also.
Now my arch. is MIDlet will fetch data from user and will store it in RMS and as the connection is available the data will be submitted to server and it will be removed locally.
The main question is is it reliable to use RMS to store data.
My one data entry will be something like + a photo[optional]
"asdjbdabhsdfjkbahsdkfbakjsdfhasfjasdfhjasdlcjalmsdhfjasdfajksdlmcfjkanmsdfgsahjkcnfhs"
suggest me arch. changes.
I'm really struggling to understand your question.
if your asking if RMS is a reliable storage method for pictures the answer is yes.
You just have to convert your image to a byte array and save. Then when you need to make it back into an image, the Image class has a constructor for making a new Image from byte array anyway. The RMS is persistent so your data will be there if you stop the app and as a default your applications RMS should only be accessible to your application (although I think you can change this manually).
I'm currently developing a peace of software witch stores pictures, audio recordings and ID strings as well as date and time stamps on the phone it's self prior to a server upload point and I use the RMS.
I'm not actually sure if there's any other form of local storage that J2ME has access to.