Friday 4 March 2016

[Java] JNLP Tutorial

1. Make Java Program
It is simple JavaFX Program printing system hostname and IP.


2. Execute Java Program



3. Build jar file.
export jar named 'jafxt.jar'



4. Create keystore
create keystore named 'testKeys'


5. Assign keysotre into jar


6. Create JNLP file


7. Deploy jar, jnlp into tomcat and start tomcat up


8. Access JNLP URL using web brower and download JNLP file




9. Execute JNLP file






















If this error occurs


Set java security configuration


[ActiveMQ] Message Expiration(Time to Live) Confusion

I set message expiration time as 10000(milliseconds). and put message into 'TEST.QUEUE ' queue. It expected that the enqueue count is going up and expired after 10 seconds. Unexpectedly, but not only enqueue count is not going up but also an exception is not occur. This phenomenon can occur when ESB(ActiveMQ) Server system time is different with client system time.




JMSTimestamp is set by client. And JMSExpiration is set as JMSTimestamp + time to live time. But, ActiveMQ expire message based on server system time. For example, if Client system time is '2016-03-04 11:00:00' and server system time is '2016-03-04 11:00:00' and time to live of message is 1 minute, the message is expired after 30 seconds.


Therefore, if ActiveMQ server system time is faster than client system time and a time to live of message is smaller than difference between server system time and client system time, the message is expired before entering a queue.

[ActiveMQ] Manage Durable Subscribers

Apache ActiveMQ Manage Durable Subscribers

http://activemq.apache.org/manage-durable-subscribers.html

Durable topic subscribers that are offline for a long period of time are usually not desired in the system. The reason for that is that broker needs to keep all the messages sent to those topics for the said subscribers. And this message piling can over time exhaust broker store limits for example and lead to the overall slowdown of the system.
You can always manually unsubscribe inactive durable subscriber using management tools like JConsole or Web Console, but clearly there's more that can be done to help manage systems that use durable subscribers (perhaps coming from environments that they don't control)
Staring with version 5.6 we introduced a few improvements in this area.

Expiring messages

Some applications send message with specified time to live. If those messages are kept on the broker for the offline durable subscriber we need to remove them when they reach their expiry time. Just as we do with queues, now we check for those messages every 30 seconds by default, which can be tuned with the appropriate destination policy. For example, the following entry
<policyEntry topic=">" expireMessagesPeriod="300000"/>
will configure the broker to check for expired messages every 5 minutes.

Removing inactive subscribers

The other thing we can do is to automatically unsubscribe durable subscribers that are not active for some period of time. For that purpose we introduced two new broker properties:
property
default
description
offlineDurableSubscriberTimeout
-1
Amount of time (in milliseconds) after which we remove inactive durable subs. Default -1, means don't remove them
offlineDurableSubscriberTaskSchedule
300000
How often we check (in milliseconds)
An example configuration could look like
<broker name="localhost" offlineDurableSubscriberTimeout="86400000" offlineDurableSubscriberTaskSchedule="3600000">
which means that we check every hour and remove subscriber that has been offline for a day.