Recent changes to tickets

#11 Dependencies of jradius 1.1.3 currently cannot be resolved.

2015-10-29T13:35:35.640000Z

The soluction referred to above no longer works. Originally only artifact ipdrbase was no longer available from the Coova Maven repository. But now also the artificats jradius-core, jradius-dictionary, jradius-extended and java-getopt are no longer available at Coova.

As a workaround it is possible to extract them from the Asimba war and add them to your local Maven repository. That is not an advisable, good practice. A better solution is needed. If this workaround is to be used, it would be best to update the workaround article to reflect the needed steps..

#11 Dependencies of jradius 1.1.3 currently cannot be resolved.

2015-10-22T08:36:53.860000Z

This is a known issue of the dependency on jradius. There's a work-around to get the build to fall through (but missing some jradius-library and therefore limits its functionality)

http://sourceforge.net/p/asimba/wiki/Create%20Asimba%20WAR-file%20from%20the%20source%20repository/#asimba-am-password-radius-or-problem-with-jradiusipdrbase-200

#11 Dependencies of jradius 1.1.3 currently cannot be resolved.

2015-10-22T08:34:08.334000Z

summary: Dependencies on jradius 1.1.3 currently cannot be resolved. --> Dependencies of jradius 1.1.3 currently cannot be resolved.

Dependencies of jradius 1.1.3 currently cannot be resolved.

2015-10-22T08:33:42.478000Z

Ticket 11 has been modified: Dependencies of jradius 1.1.3 currently cannot be resolved.
Edited By: Jan Blom (jan_b)
Summary updated: u'Dependencies on jradius 1.1.3 currently cannot be resolved.' => u'Dependencies of jradius 1.1.3 currently cannot be resolved.'

Dependencies on jradius 1.1.3 currently cannot be resolved.

2015-10-22T08:33:42.478000Z

When building Asimba, it is currently not possible to build asimba-am-password-radius, because of unresolvable dependencies for jradius (maven repos no longer available). If asimba-am-password-radius is not used, the workaround is to disable it. Otherwise, the dependencies block a succesfull build.

SingleLogout blocks persisting TGT's using JGroups

2015-08-19T10:10:29.904000Z

When a TGT is persisted, it calls performPersist() which is marked as 'synchronized' operation. Inside it, though, all subscribed listeners are given a chance to react on TGT status changes. In case of removing a TGT, the SingleLogout to SP's is triggered, which is a pretty heavy operation that can even timeout when the remote end isn't responding correctly.

This blocks the Asimba server.

The resolution would be to figure out which parts of performPersist() can be synchronized (considering that the backend can be shared between multiple nodes in a cluster) and make sure that it doesn't block on external factors.

It seems that only the generation of a new unique TGTID has reasons to ask for locks, but even there it is not possible to rule out a very highly unlikely problem that two nodes generate the same random TGTID and then storing it at the same time. We should consider that collateral to running a clustered Asimba deployment.

#9 Specify order and source for node id when setting up a cluster

2015-03-30T12:57:16.647000Z

status: accepted --> closed

#9 Specify order and source for node id when setting up a cluster

2015-03-30T12:50:47.217000Z

status: open --> accepted

Specify order and source for node id when setting up a cluster

2015-03-30T12:50:26.639000Z

The order in which Asimba determines the node id for a node in a cluster should be:

A setting "asimba.node.id" through JNDI
+. A system property "asimba.node.id"
+. The system hostname

Specify order and source for node id when setting up a cluster

2015-03-30T12:50:26.639000Z

Ticket 9 has been modified: Specify order and source for node id when setting up a cluster
Edited By: Jan Blom (jan_b)
Status updated: u'open' => u'accepted'