For this first blog on using the Quartz Scheduler and how to solve some live issues that will be encountered, I want to concentrate on a tricky error that I encountered while trying to implement a Persistent JobStore implementation of the Quartz Scheduler for my prototype. Here are the details of environment being used for the prototype

Quartz Scheduler 1.8.3, JDK 1.6.0_23, PostgreSQL 9.0.1

Now I know that Quartz Scheduler 2.1 is the latest stable version but due to project constraints, I had to use version 1.8.3 for my prototype. Ironically, I first learnt the Quartz Scheduling package using version 2.1! However, the issue that I was faced with is also present in basically any version of Quartz Scheduler. Alright, enough of foreplay, let’s get down to the dirty bit!
For some background,in brief, Quartz Scheduler allows jobs to be stored either in memory (RAMJobStore) or in persistent storage (JobStoreTX, JobStoreCMT). The problem with RAMJobStore is that once the JVM is shut down, all the jobs and triggers that were present in the RAMJobStore instance are lost. This is obviously not ideal for a real production quality implementation of scheduling. Of the other two types of storage, JobStoreTX is basically used to persist jobs and associated triggers (plus a bunch of other stuff that the Quartz Scheduler requires for proper functioning) in database tables (12 tables for version 1.8.3, 12 for the 2.1 version). JobstoreCMT does the same. The main difference is that JobStoreTX is ideal for stand-alone applications which handle their own database transactions whereas JobStoreCMT (as the CMT in the name suggests) is meant for applications deployed in Application Containers (such as JBoss, WebLogic et al) so that database transactions are handled by the Container itself. For my project, however, I was constrained to use the Apache Tomcat Server (6.0.24) so I had to make do with JobStoreTX. For more information, refer to the official documentation on Quartz site.
So onto the problem which a lot of people might face but be flummoxed by, since the error message is not exactly intuitive. My prototype code is shown below. First off, the code that loads the scheduler and schedules the Job:

package com.z0ltan.scheduling.prototype.jobstoretx;

import java.text.ParseException;
import java.util.Calendar;
import java.util.Date;
import java.util.GregorianCalendar;

import org.apache.log4j.Logger;
import org.quartz.CronExpression;
import org.quartz.CronTrigger;
import org.quartz.JobDetail;
import org.quartz.Scheduler;
import org.quartz.SchedulerException;
import org.quartz.SchedulerMetaData;
import org.quartz.impl.StdSchedulerFactory;

import com.z0ltan.scheduling.prototype.jobstoretx.job.StatefulLogTimeJob;

public class JobStoreTXTestScheduler {
	private static final Logger logger = Logger
			.getLogger(JobStoreTXTestScheduler.class);

	public static void main(String[] args) {
		JobStoreTXTestScheduler jsts = new JobStoreTXTestScheduler();
		Scheduler scheduler = null;

		try {
			scheduler = jsts.getScheduler();

			logger.info("Starting scheduler");
			scheduler.start();
			logger.info("Scheduler started at " + new Date());

			logger.info("Scheduling jobs");
			jsts.scheduleJob(scheduler, "StatefulLogTimeJob",
					"StatefulLogTimeJobGroup", StatefulLogTimeJob.class, 5);

			try {
				Thread.sleep(24 * 60 * 1000);
			} catch (InterruptedException ex) {

			}

		} catch (SchedulerException ex) {
			logger.error(ex.getLocalizedMessage());
		} finally {
			try {
				if (scheduler != null && !scheduler.isShutdown()) {
					scheduler.shutdown(true); // Wait for all running jobs
												// to be
												// completed
				}
			} catch (SchedulerException exc) {
				logger.error(exc.getLocalizedMessage());
			}
		}

	}

	private Scheduler getScheduler() throws SchedulerException {
		Scheduler scheduler = null;
		StdSchedulerFactory factory = new StdSchedulerFactory();
		factory.initialize("com/z0ltan/prototype/properties/jobstoretxscheduler.properties");

		scheduler = factory.getScheduler();

		// Log Scheduler Metadata
		SchedulerMetaData metadata = scheduler.getMetaData();
		logger.info("\tScheduler Name = " + metadata.getSchedulerName());
		logger.info("\tScheduler ID = " + metadata.getSchedulerInstanceId());
		logger.info("\tThreadPool class = " + metadata.getThreadPoolClass());
		logger.info("\tThreadPool size = " + metadata.getThreadPoolSize());
		logger.info("\tJobStore class = " + metadata.getJobStoreClass());

		return scheduler;
	}

	private void scheduleJob(Scheduler scheduler, String jobName,
			String jobGroup, Class jobClass, int noOfOccurrences) {
		JobDetail job = new JobDetail(jobName, jobGroup, jobClass);
		job.getJobDataMap().put("ITER_COUNT", "1");
		job.getJobDataMap().put("NO_OF_OCCURRENCES",
				Integer.toString(noOfOccurrences));
		job.setDurability(true);

		int dayOfMonth = 30;
		GregorianCalendar cal = new GregorianCalendar();
		int year = cal.get(Calendar.YEAR);
		CronTrigger trigger1 = null;

		try {
			String cronExpressionString = "0 30 15 " + dayOfMonth + " * ?";
			CronExpression cron = new CronExpression(cronExpressionString);

			CronTrigger trigger = new CronTrigger();
			trigger.setName(jobName + "-Trigger");
			trigger.setGroup(jobGroup + "-TriggerGroup");
			trigger.setCronExpression(cron);
			trigger.setStartTime(new Date());
			trigger.setVolatility(false);
			scheduler.scheduleJob(job, trigger);
			logger.info("Job " + jobName + " scheduled successfully");
			logger.info(trigger.getNextFireTime().toString());

			// Register additional triggers for special cases
			// In the case of monthly recurrence pattern, if the day of month
			// selected is 29, 30 or 31 special care has to be taken
			switch (dayOfMonth) {
			case 29:
				if (!cal.isLeapYear(year)) {
					trigger1 = new CronTrigger();
					trigger1.setName(jobName + "-Trigger1");
					trigger1.setGroup(jobGroup + "-TriggerGroup");
					CronExpression cron1 = new CronExpression("0 30 15 L FEB ?");
					trigger1.setCronExpression(cron1);
					trigger1.setStartTime(new Date());
					trigger1.setJobName(jobName);
					trigger1.setJobGroup(jobGroup);
					trigger1.setVolatility(false);
					scheduler.scheduleJob(trigger1);
				}
				break;

			case 30:
				trigger1 = new CronTrigger();
				trigger1.setName(jobName + "-Trigger1");
				trigger1.setGroup(jobGroup + "-TriggerGroup");
				trigger1.setCronExpression("0 30 15 L FEB ?");
				trigger1.setStartTime(new Date());
				trigger1.setJobName(jobName);
				trigger1.setJobGroup(jobGroup);
				trigger1.setVolatility(false);
				scheduler.scheduleJob(trigger1);
				break;

			case 31:
				trigger1 = new CronTrigger();
				trigger1.setName(jobName + "-Trigger1");
				trigger1.setGroup(jobGroup + "-TriggerGroup");
				trigger1.setCronExpression("0 30 15 L FEB,SEP,APR,JUN,NOV ?");
				trigger1.setStartTime(new Date());
				trigger1.setJobName(jobName);
				trigger1.setJobGroup(jobGroup);
				scheduler.scheduleJob(trigger1);// This is how we add additional
												// triggers to an existing job
			}
		} catch (ParseException ex) {
			logger.error("Failed to schedule Job " + jobName
					+ " because of errors in the Cron Expression");
			return;
		} catch (SchedulerException exc) {
			logger.error("Failed to schedule Job " + jobName);
		}
	}
}

And the corresponding Quartz properties file to customize the scheduler:

#Scheduler
org.quartz.scheduler.instanceName = JOBSTORETX_SCHEDULER
org.quartz.scheduler.instanceID = AUTO

#ThreadPool
org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool
org.quartz.threadPool.threadCount = 24
org.quartz.threadPool.threadPriority = 5

#JobStore
org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreTX
org.quartz.jobStore.driverDelegateClass = org.quartz.impl.jdbcjobstore.PostgreSQLDelegate
org.quartz.jobStore.useProperties = false #PostgreSQL 9.0
org.quartz.jobStore.dataSource = myDS
org.quartz.jobStore.tablePrefix = QRTZ_
org.quartz.jobStore.misfireThreshold = 120000
org.quartz.jobStore.maxMisfiresToHandleAtATime = 20
org.quartz.jobStore.dontSetAutoCommitFalse = false
org.quartz.jobStore.selectWithLockSQL = SELECT * from {0}LOCKS where LOCK_NAME=? FOR UPDATE
org.quartz.jobStore.txIsolationLevelSerializable = true

#DataSource
org.quartz.dataSource.myDS.driver = org.postgresql.Driver
org.quartz.dataSource.myDS.URL = jdbc:postgresql://localhost:2377/mydatasource
org.quartz.dataSource.myDS.user =evapa_system
org.quartz.dataSource.myDS.password =password
org.quartz.dataSource.myDS.maxConnections = 25

As can be seen in the properties file above, I have used the JobStoreTX class for persistence and pointed it to a DataSource with the URL jdbc:postgresql://localhost:2377/mydatasource. All seems about right at this stage. The code for the job that I am using is shown below for completion:

package com.z0ltan.scheduling.prototype.test.job.stateful;

import java.util.Date;
import java.util.logging.Logger;

import org.quartz.JobDetail;
import org.quartz.JobExecutionContext;
import org.quartz.JobExecutionException;
import org.quartz.Scheduler;
import org.quartz.SchedulerException;
import org.quartz.StatefulJob;
import org.quartz.Trigger;

public class StatefulLogTimeJob implements StatefulJob {
	private static final Logger logger = Logger.getLogger("StatefulLogTimeJob");

	public void execute(JobExecutionContext context)
			throws JobExecutionException {
		JobDetail jobDetail = context.getJobDetail();
		Trigger trigger = context.getTrigger();

		String jobName = jobDetail.getName();
		String triggerName = trigger.getName();
		String triggerGroup = trigger.getGroup();
		int iterCount = jobDetail.getJobDataMap().getInt("ITER_COUNT");
		int noOfOccurrences = jobDetail.getJobDataMap().getInt(
				"NO_OF_OCCURRENCES");

		if (iterCount >= (noOfOccurrences + 1)) { // Since the first iteration
													// starts from 1 and not 0
			logger.info("Job "
					+ jobName
					+ " has been stopped since it has reached the maximum no. of executions.");
			logger.info("Removing trigger for " + jobName
					+ " from the Scheduler");

			Scheduler scheduler = context.getScheduler();

			if (scheduler != null) {
				try {
					scheduler.unscheduleJob(triggerName, triggerGroup);
				} catch (SchedulerException ex) {
					throw new JobExecutionException(ex, false); // do not
																// restart job
				}
			}
			return;
		}

		logger.info("Starting execution of Job " + jobName + " Iteration "
				+ iterCount);
		logger.info("\tCurrent Time = " + new Date());
		logger.info("Finished execution of Job " + jobName + " Iteration "
				+ iterCount);
		jobDetail.getJobDataMap().put("ITER_COUNT", (iterCount + 1));
	}
}

I start the scheduler and it hums along nicely. The job and the trigger are getting stored in the tables and I can see them in pgAdminIII. Then when I try to add the second trigger to the already scheduled job, as done in the line of code shown below,

scheduler.scheduleJob(trigger1);

The whole scheduler comes crashing with the following exception message:

org.quartz.JobPersistenceException: Couldn’t store trigger ‘StatefulLogTimeJob-Trigger1′ for ‘StatefulLogTimeJob’ job:invalid stream header: BB656430 [See nested exception: java.io.StreamCorruptedException: invalid stream header: BB656430]

What I did then is attach the source code for the Quartz JAR file (quartz-1.8.3.jar) and start debugging the whole code flow. As could be seen in the properties file, the scheduler is configured to use the PostgreSQLDelegate class that comes bundled with Quartz as the delegate class to handle database transactions peculiar to PostgreSQL. As I was debugging, I found out the issue occurs when the scheduler tries to add the additional trigger because the scheduler is unable to retrieve the job details from the database! It was a simple Serialization issue. Still, I was stuck with no resolution in hand. I tried the StdJDBCDelegate class but no luck there either. At last I realized that perhaps the issue was with the PostgreSQL server itself. And boy was I right! A little intuitive poking around the PostgreSQL documentation for the bytea datatype (the datatype used for binary strings or blobs in common parlance) revealed a gory picture – the documentation blatantly claimed that PostgreSQL 9.0 had changed the default behavior of the bytea datatype to hex format, which earlier versions of PostgreSQL do not support (they use the ‘escape format’ instead). This was still alright but the clincher is that they allow hex or escape formats while inserting into the database but return only hex by default while retrieving from the same table! Whoa, Nelly. So I jumped up and checked the project settings in Eclipse:

Et voila! There was the issue – the project was configured to use an older version of PostgreSQL JDBC driver (postgresql-8.4-701.jdbc4) whereas the correct version would be postgresql-9.0-802.jdbc4 (or above as I found out by experimentation). So how was the rest of the project code working fine till now? Simple – none of the tables actually persisted Serializable objects. However, for Quartz, since a job is represented by the JobDetail class which itself has a Serializable component – JobDataMap the Quartz job retrieval code would always fail since it was trying to deserialize the binary stream retrieved from the qrtz_job_details table into a JobDataMap object. This exquisitely explains the weird error message shown before. Whew! So the fix was ultimately as simple as updating the PostgreSQL JDBC database driver to the correct version!
In conclusion, it is imperative to ensure that any updates on existing projects (in this case, the project had been updated to use PostgreSQL 9.0.1 from PostgreSQL 8.4) should also have updates for all ancillary and related libraries, environment properties and other software dependencies. Also, PostgreSQL sucks. Heh.

Consider for instance that the user that the specific PostgreSQL instance that the software package installed is ‘username‘ with password ‘password‘. The database that the software package created had this user as the owner and required the same credentials for the application to access this database. Now, the PostgreSQL installer does not give an option to configure additional users (aside from the default ‘postgres’ account) during installation. This was a source of confusion since after installation, there was no option from pgAdminIII to configure any new users! We tried to create a new entry in the pgpass.conf file by opening it via pgAdminIII and adding a new entry with ‘username’ and ‘password’ as the credentials. This, of course, did not work. This was fine but the irksome bit was that the error message was quite misleading, as can be seen below:

So I did a bit of research into the PostgreSQL documentation and found that I could add a new user only via a tool called ‘createuser.exe‘ (on Windows). The documentation did not specify that clearly and only mentioned ‘CREATEUSER’ as a command with some options that could be used to assign different privileges to the new role. My first thought was that this could be achieved on the psql.exe command shell but that was a total dud! Quite expectedly so indeed. It was only when I checked the contents of the bin folder that I discovered the ‘createuser.exe‘ tool! Long story short, here’s how you add a new user with superuser privileges to your PostgreSQL server (note: this was checked on PostgreSQL 9.0.1-1 but this should work with at least as far back as PostgreSQL 8.3):

with the options explained as follows:

-d informs PostgreSQL to allow the new user to be able to create new databases
-s informs PostgreSQL to assign superuser privileges to the new user
-P intimates PostgreSQL that the new user should have a password, which will be supplied by the user

The following options are for the PostgreSQL server itself:

-h provides the hostname of the PostgreSQL server
-U provides the username of the PostgreSQL server (default user ‘postgres’ is used here)
-p supplies the port on which the PostgreSQL server is listening
-W intimates PostgreSQL that it must use the supplied password (for the default user ‘postgres’ to connect to the server)

Et voila! The database is now installed beautifully and works like a charm:

And the properties of the server (and correspondingly the database within it) also shows the new user as the owner of the server instance:

The takeaway from this exercise is that the PostgreSQL documentation sucks but given enough time, patience and mental acuity, we can yet tame this free and solid quality beast.

How very germane of VLC!
(I am using VLC player 0.9.8a Grishenko).

Even though the discussion in the bug history argues about ‘compatibility’ issues being the main concern dissuading the Eclipse team from shifting to UTF-8 as the default, most of us would still like to work in UTF-8. Changing to UTF-8 encoding is simple in Eclipse but is extremely buggy and the random unpredictable behavior can be really irksome. In most cases, one or more of the following changes should suffice. If you are still getting an error while changing the encoding scheme, the best bet would be to close the workspace and restart the IDE! Seriously, no kidding.

I am using Eclipse Galileo as the base IDE but these steps should work on most version of Eclipse with minor differences (by the way, I am using the JAVA EE version).

For all the various options mentioned below, the first step is to traverse to the settings page as

Windows -> Preferences

1. Changing the entire workspace’s encoding scheme:

2. Changing the Text Editor’s encoding scheme (also works for the Java editor):

3. Changing the CSS editor’s encoding scheme:

4. Changing the HTML editor’s encoding scheme:

5. Changing the JSP editor’s encoding scheme:

And there you go! Now you can start coding in your favorite encoding scheme!

I guess I need to make out some time to update my previous blogs now. It’s well worth it.

1. Obtain the URL of the document as served out by Tomcat server.

2. Use this URL as the DataSource for the JavaMail API.

3. Munge the URL for the file name and insert the URL as a link in the message body and, finally

4. Attach the document (if below the user-configured attachment limit) to the mail and e-mail it to the recipients.

All in all pretty simple, right? Wrong. The code was working smoothly until the document was either UTF-8 encoded and/or the document name contained white-spaces as well as a smorgasbord of other characters (as allowed by the Windows file system) such as the tilde character(~) or the backquote character (`) or even something such as the addition symbol (+). This caused the whole mechanism to come crashing down…and bad! This interesting development led me to a whole afternoon of researching and hacking which was quite tiring but enjoyable. I can honestly say that I learnt more about encoding and the way Java’s API’s conform (or not) to the standards, through this simple error, than I could have by devouring the RFC’s and API documentation!

So, first off, the problem description -

1. The URI specification (which is basically a superset of the URL specification) is drafted in a variety of RFC’s – RFC 2396, 3986, 5785 et al. However, most modern browsers conform to the new IRI (Internationalized Resource Identifiers) as specified by RFC 3987. This means that a whole variety of previously disallowed characters are now kosher for URI’s/URL’s/IRI’s. However, Java has failed to keep up with the trend and their IRI support is broken. See. This opens a whole can of worms.

2. In my code, the main “context path” of the URL that my module receives for a specified document is basically localized/internationalized. For instance, consider as URL of the form:

http://localhost:9999/examples/servlets/`~!@^()_-+={[ }] ‘,. test 1 サンプルファイル 999.CSV.PDF

In the URL above, the context portion is “http://localhost:9999/examples/servlets/”. So I just had to resolve the encoding problems with the file name portion (i.e., “`~!@^()_-+={[ }] ‘,. test 1 サンプルファイル 999.CSV.PDF”). In this respect, a variety of tools are purportedly provided by the JDK suite itself – URLEncoder, URI and the URL class. For instance, the following were the options that I tried, in order:

a). Use the java.net.URLEncoder class’ encode(String s, String enc) method to try and encode the complete URL. Bad idea. For the sample URL above, it returns a wholly encoded form as follows:

http%3A%2F%2Flocalhost%3A9999%2Fexamples%2Fservlets%2F%60%7E%21%40%5E%28%29_-%2B%3D%7B%5B+++%7D%5D+%27%2C.+test+1+%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB++++++999.CSV.PDF

Whoa! This cannot be parsed by either the browser or by JavaMail’s URLDataSource handler (or even by JDK’s HttpURLConnection/HttpsURLConnection classes). Trashed.

b). Okay, so now I just try and encode the filename portion (since the context path is guaranteed by contract to be properly encoded). The output?

http://localhost:9999/examples/servlets/%60%7E%21%40%5E%28%29_-%2B%3D%7B%5B+++%7D%5D+%27%2C.+test+1+%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB++++++999.CSV.PDF

Hmmm. Slightly better but still completely non-functional as before. At this point, I decided to dig into the JDK source code (using the OpenJDK Java 7 codebase). There was the problem! It was basically encoding whitespaces as ‘+’ instead of encoding it into ‘%20′ as expected. Plus a whole bunch of other characters were being ignored when they should have been encoded. At this point I was almost decided in my mind to implement my own UTF-8 encoder.

c). Upon suggestion by an acquaintance, I decided to try the java.net.URI class constructor to generate a proper URI and then invoke the toURL() method to obtain a properly encoded URL. Sounds exquisitely standards-conformant but this totally bombed when it encountered UTF-8 characters (though it handled whitespace just fine). Firefox Opera and Opera seemed to like this just fine.The URL generated was not usable by JavaMail’s URLDataSource handler (or HttpURLConnection/HttpsURLConnection classes). Plus on some e-mail clients (Gmail), the links were pretty much broken and the user would have to manually copy-and-paste the link into the browser to access the document.

The solution?

I implemented a simple UTF-8 encoder which basically encodes every non-alphanumeric character into UTF-8, shown belowpackage com.z0ltan.mail.encoder;

package com.z0ltan.mail.encoder;

import java.nio.charset.Charset;

public class MyUTFEncoder {
	private static final String HEX_CHARS = "0123456789ABCDEF";

	public static String encode(String data) {

		if (data != null) {
			StringBuffer buffer = new StringBuffer();

			byte[] dataBytes = MyUTFEncoder.getUTFBytes(data);

			for (int i = 0; i < dataBytes.length; i++) {
				char c = (char) dataBytes[i];

				if ((c >= 'a' && c <= 'z')
					|| (c >= 'A' && c <= 'Z')
					|| (c >= '0' && c <= '9')) {
					buffer.append(c);
				} else {
					buffer
					 .append('%');
					buffer
					 .append(HEX_CHARS.charAt((c & 0xF0) >> 4));
					buffer
					 .append(HEX_CHARS.charAt((c & 0x0F)));
				}
			}

			return buffer.toString();
		}
		return null;
	}

	private static byte[] getUTFBytes(String data) {
		if (data != null) {
			return data.getBytes(Charset.forName("UTF-8"));
		}
		return null;
	}
}

The code is pretty self-explanatory. The URL’s generated may not be pretty to look at but they are equally liked by the browser, Java’s URLConnection API’s, JavaMail’s URLDataSource handler as well as E-mail clients such as MS Outlook and Gmail (no more broken links, yay!).

For the representative URL shown at the beginning of this blog, the output is as follows:

http://localhost:9999/examples/servlets/%60%7E%21%40%5E%28%29%5F%2D%2B%3D%7B%5B%20%20%20%7D%5D%20%27%2C%2E%20test%201%20%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%20%20%20%20%20%20999%2ECSV%2EPDF

Yes, pretty ugly, but in most browsers that I tested it on, the browser automatically displays it in a more user-friendly format (with no encoding). The best part? This URL works well with JDK, JavaMail, e-mail clients as well as the browser! Plus, to rid it of some ugliness, I actually insert the attached document’s name without the encoding – such as `~!@^()_-+={[ }] ‘,. test 1 サンプルファイル 999.CSV.PDF. This saves the user some confusion about the veracity of the attached document (Note: The file name may still be encoded into weird forms by the e-mail client, if not properly configured but that is beyond the purview of my application).

All in all, an afternoon well spent. Slainte!

PostScript

JDK 1.6, JavaMail 1.4, Firefox 8.0.1, IE 7 and Opera 11.52, MS Outlook and Gmail client used for testing.

Now I am poring over the RFC’s to gain a wholesome understanding of the whole wonderfully twisted domain of encoding/decoding!

The problem I had was that even though the reports were actually stored on the web server’s local file system, I did not have access or permission to access the reports from the file system. All I had was the web URL of the report document. Thus I had no choice but to read the file size somehow from the URL , check it against the configured maximum SMTP attachment size and then e-mail the report. The prototype that I developed is posted at this location – http://pastebin.com/KnsUuAhG

As can be seen, I have used JavaMail for the actual e-mail dispatch. The interesting bit is in the isAttachmentSmallerThanMaxSmtpSize  method:

private static boolean isAttachmentSmallerThanMaxSmtpSize(
                        String attachmentLink) {
                boolean status = false;

                try {
                        HttpURLConnection connection = (HttpURLConnection) new URL(
                                        attachmentLink).openConnection();
                        int sizeInMB = connection.getContentLength() / (1024 * 1024);

                        if (sizeInMB > MAX_SMTP_SIZE) {
                                status = false;
                        } else {
                                status = true;
                        }

                } catch (Exception ex) {
                        status = false;
                }

                return status;
        }

where the actual file size can be obtained by simply obtaining the content length of the HTTP (or HTTPS) Connection object.

For my prototype, for HTTPS connections, I actually disabled the HTTPS certificate check by using the method described in this nifty blog: http://www.nakov.com/blog/2009/07/16/disable-certificate-validation-in-java-ssl-connections/. In actual production use, however, HTTPS URLs are handled by using the actual certificates installed with the product.

Fill in the lines of xxxxxxxxx  so that this program will print  Bingo.
PS: dont Use printf("bingo")  and return 0 

int main()
{
        int a,b;

       xxxxxxxxx          

       xxxxxxxxx  

       xxxxxxxxx  

        if ( a==b)
                printf("equal");
        else
                if ( a > b )
                        printf("greater");
                else
                        if( a < b)
                                printf("less");
                        else
                                printf("Bingo");

        return 0;
}

My solution:

int main()
{
        int a,b;

        if (a = b)
                printf("Bingo\n");
        else

        if ( a==b)
                printf("equal");
        else
                if ( a > b )
                        printf("greater");
                else
                        if( a < b)
                                printf("less");
                        else
                                printf("Bingo");

        return 0;
}

 

Bejasus!

#include 

typedef struct node {
        char* data;
        struct node* next;
}* NODE;

int main()
{

        NODE root = NULL;
        NODE tail = NULL;

        root = (NODE) malloc(sizeof(struct node));
        tail = (NODE) malloc(sizeof(struct node));

        root->data = "hello";
        tail->data = "world";

        root->next= tail;
        tail->next = NULL;

        // display the contents of the linked list
        NODE cur = root;
        for(;cur != NULL; cur= cur->next)
        {
                printf("%s ", cur->data);
        }

        free(root);
        free(tail);

        printf("\n");

        return 0;
}

And it worked. First time around. Nice!