>
> boolean readInput = true;
> while (readInput) {
> readInput =StringUtils.isNotBlank(in.readLine());
> }
>
There's absolutely nothing wrong with that line in the overall design of
the reader. The whole purpose of the component
>
> I'd like to know if a user is 'authorized' to login to a service once they
> have a session (JSessionID), or are they only authorized after the TGT
> cookie has been set?
>
We modified the login flow a while back to check the service against the
ServiceRegistry in the first few steps of the
We have seen these on the order of
~1500/minute for anywhere from a few minutes to a few hours in duration.
In my experience ticket floods are always caused by misconfigured
applications. In one extreme case we got ~42K in a ~60s period. We never
zeroed in on the exact cause, but we do see
Lately we have been seeing ST Validations failing because the ticket is
expired. We are thinking of changing the timeout to either 15 or 20 seconds.
The first thing that occurs to me is latency in ticket replication among
all the peers in your cluster. That's sort of orthogonal to your
Yes, I have some nice splunk dashboards for CAS I can share if there is
interest.
If you have a dashboard/query that can follow all service accesses in a
single SSO session, then I would be very interested.
M
--
You are currently subscribed to cas-user@lists.jasig.org as:
FWIW, the underlying Inspektr's component that CAS uses for its slf4j
audit events destination is extensible, and one could always plugin their
own output formatting implementation to suit their needs:
Sure, and we have extended it locally for our deployment. I think it's fair
to consider,
Nothing that follows every service access-- I think that will require some
unusual joins.
I got a working query that wasn't too bad:
index=mwcas sourcetype=mwcas-audit | rex (?tgtTGT-[A-Za-z0-9_-]+) |
rex (?servicehttps://[A-Za-z0-9._/-]+) | transaction tgt maxspan=10h
keepevicted=true |
The root problem:
44B4 .||||= CAS_Client::_readURL('
https://10.0.12.81:8443/serviceValidate?service=http%3A%2F%2Flocalhost%2Fdemo%2Fta%2Fcas5%2Fticket=ST-13-W3OmeHczcuhJOGeiwaeO-cas.poliupg.ac.id',
NULL, NULL, NULL) [Client.php:3118]
44B4 .|||||=
The primary reason I did not like the memcached implementation was that it
is not truly fault-tolerant. As I understand it, any given key is hashed
and stored on one of the available memcached nodes. A client that needs it
performs the same hash, and tries to retrieve it from the same node. I
Would the idp multifactor mechanisms be usable for CAS clients?
Yes, though it may be better to discuss further on the related shib-users
thread.
I don't
particularly like the memcached backend, which looks like the only
current option (other than a database) to cluster idp 3.
I'd be
I was just wondering if anybody here is familiar with both and might be
able to provide some pros/cons of consolidating CAS into the idp vs
continuing to maintain a separate CAS deployment?
I'm very familiar with both from a development and deployment perspective.
Much of the growth of Jasig
We've been running a load-balanced CAS cluster of two nodes for a number of
years now.
Clustering is supported provided you have session affinity during the login
process. If anyone has achieved truly stateless clustering, it would
include session replication among cluster nodes (among other
Personally, we just set up our three-node CAS4 instance with Hazelcast and
front-ended it with our Barracuda (no special config required.)
I'm fairly certain the back end ticket store is irrelevant here. The poster
appears to be discussing fully stateless clustering, which involves special
I'm only considering shared sessions because that seems to be what's
recommended
in the CAS wiki.
I don't feel like the CAS wiki ever had any good high-level discussion of
HA. In any case the new-ish CAS4 documentation has a HA page that spells
out session affinity as a requirement for
I do have a secure mechanism to encrypt my service ticket with the public
key and then decrypt it later using the private-key.
At that point you've created your own SSO protocol and you're more or less
on your own as to the security outcomes. If you need security assertions
that are valid
At times we get we get WARN notifications with HTTP 400 status code...
That's by design and intended to be simply a warning; you can respond in
whatever fashion you think prudent or necessary. I would imagine that if it
starts to happen regularly, you would take that as a sign to increase your
https://wiki.jasig.org/display/CAS/Shawn+CAS+and+SAML
First, that document is very old. May still be relevant, but just as likely
not.
I was under the impression that when using SAML you initiate a SSO with a
so called authnRequest.
https://wiki.jasig.org/display/CASUM/SAML+1.1 provides
Same as object I'm coming from 3.4.3 and looking for and advice if is
better to go straight to 4.0.1 or maybe stop at 3.5.3
There will be more configuration work to upgrade from 3.x to 4.x, but it's
work you'll have to do eventually since the 3.5.x branch is in
maintenance-only mode. My
This seems to be a new requirement for cas server 4.0. I suppose it could
be the new version of java (1.7) causing the requirement.
Not Java per se but the LDAP integration library. CAS 4.0 uses the ldaptive
library for LDAP integration, and it has strict hostname verification
enabled by
I would like to use Method 1 (Active Directory authentication using
sAMAAccountName) if possible without using two-step authentication using a
service account to obtain the user DN.
Yes.
Is this possible without having all users in the same LDAP tree?
It should be possible. Can you
With Prod 3.4.12 and MFA, don’t get the successful login page. I get “page
not found” in the browser.
Turn the org.jasig.casup to DEBUG and post (sanitized) logs corresponding
to the 404 error you mentioned.
The error goes away if I take one of the 2 CAS servers offline.
Did you ever solve
Is it me or does this log say that the PASSWORD_MUST_CHANGE error is not
getting processed with the
authenticationExceptionHandler.handle(currentEvent.attributes.error,
messageContext) properly.
Not sure. Did you get any output from the TRACE logger I recommended
enabling?
M
--
You are
2015-02-24 14:20:57,866 DEBUG
[org.jasig.cas.authentication.support.DefaultAccountStateHandler] -
Handling PASSWORD_MUST_CHANGE
An AccountPasswordMustChangeException was thrown here. Something in the
view layer is supposed to catch that and route the user appropriately.
My 3.5.2 CAS server is not following redirects on logout.
Do you have some evidence to share? Not much changed on HttpClient between
3.4.12 and 3.5.2 [1], other than adding the followServiceRedirects flag
which previously defaulted to true. Turn up org.jasig.cas.util to DEBUG and
see if you get
Re: SilkRoad Life Suite
In light of current events around the _other_ Silk Road, that seems like a
very unfortunate product name. I hadn't even heard of it, much less have
any experience. Maybe someone else does.
M
--
You are currently subscribed to cas-user@lists.jasig.org as:
They have noticed that their log files are filled with the above exception
and have asked me to help them resolve this.
Are they using the SAML 1.1 protocol perchance, say to get attributes? The
CAS client enforces the SAML assertion validity window, which is a unique
feature of SAML. Clock
You know what you don't do for a minor weakness? Publish a CVE with a
title including allows remote attackers to bypass LDAP authentication via
crafted wildcards.
Paul, I get your frustration and I can sympathize. The CVE appeared to come
at us from outside the project, and its eminent
It seems like it would be more efficient if I could just have CAS return
the attributes that it is able to retrieve using the
LdapAuthenticationHandler.
That is indeed desirable and entirely possible using
LdapAuthenticationHandler and a static person directory attribute resolver.
The key is
It is definitely not specifying the return attributes.
That jibes with the CAS logs. The following is the log entry for the search
operation for return attributes following user bind:
2015-01-14 10:03:31,357 DEBUG [org.ldaptive.SearchOperation] - execute
If I use the manager account that is used to search the directory or the
credentials of the use who is logging in with ldapsearch, as long as I
explicitly request the memberOf attribute it gets returned.
Ok, then my hypothesis is apparently wrong. Requesting the additional
attributes at
Yes, after every chage I do:
mvn clean package
./bin/shutdown.sh
rm -r webapps/cas/ work/ logs/*
cp target/cas.war
./bin/startup.sh
That should work, but you might also try clearing out the unpacked war
files under (IIRC) $CATALINA_HOME/temp. I have a habit of clearing out
those
Here is the link to the xml:
http://pastebin.com/N20RzJgG
The file looks ok on visual inspection and passes XML validation using
tools. That makes me think that the whitespace issue that Curtis mentioned
is perhaps the cause. It's possible the whitespace got fixed between
pastebin and the
INFO: Deploying web application directory /var/lib/tomcat7/webapps/ROOT
2015-01-07 11:04:42,372 ERROR
[org.springframework.web.context.ContextLoader] - Context initialization
failed
org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException:
Line
72 in XML document from
Good Afternoon from the cold, dark north as we near winter solstice.
Yikes! It's hard to imagine only a few hours of light per day.
How much overhead does adding the audit trail logging add?
It logs to a file on a background worker thread, so hardly any. You can
choose other backends, but
it should not be able to fill the heap memory of the SSO server which
would argue that there is some bug in the CAS SAML code that is being
excercised by the repeated logins.
You attached a profiler screenshot near the beginning of the thread that
showed a large number of
Second, the massive number of STs are being created on only one server
(we can tell by the host name in the logged ST) but the OTHER SERVER is
where the memory is growing out of bounds.
I'm still working through this thread, but I wanted to point out that the
other is hurting likely because
we have some custom bean properties, but depending on the environment have
different values, e.g.
!-- Test environment --
property name=baseUrl value=https://test.wyona.com//
!-- Production environment --
property name=baseUrl value=https://www.wyona.com//
The Spring profile machinery is
bean id=passwordEncoder
class=org.jasig.cas.authentication.handler.DefaultPasswordEncoder
p:characterEncoding=UTF-8
c:encodingAlgorithm=BCryptPasswordEncoder/
BCryptPassword is not a valid JCE digest algorithm name. You must use one
of the values described in the
For the the second time both of our SSO servers running under Tomcat ran
out of heap memory last night.
Did CAS emit any errors to the application log file, cas.log, prior to OOM?
Please post anything you have. You can configure the JVM to perform a heap
dump prior to exiting, which you
Do those setting go in CATALINA_OPTS or JAVA_OPTS in the setenv.sh file?
The Tomcat documentation recommends CATALINA_OPTS, which is what I do.
M http://www.ja-sig.org/wiki/display/JSG/cas-user
--
You are currently subscribed to cas-user@lists.jasig.org as:
arch...@mail-archive.com
To
We are looking to deploy an HA architecture for CAS. We will have a load
balancer with a server on two different campuses.
I believe the following documentation will be helpful:
http://jasig.github.io/cas/4.0.0/planning/High-Availability-Guide.html
The Recommended Architecture diagram is
We've looked at
https://server/cas/status but can't tell if the memory usage there
includes an ehcache ticket registry or if that is excluded.
The MemoryMonitor simply looks at overall JVM memory usage. While
ehcache may, depending on configuration, use off-heap memory
allocations that are
Can anybody shed some light on this, please? Any thoughts on where to look?
It's a known issue and there's little remedy. Searching the list
archives you'll find that deadlocks are most commonplace on MSSQL.
We've tried several fixes to reduce the likelihood of deadlocks, but
nothing short of
I saw the JIRA from a couple years ago that got marked as resolved after you
merged a patch.
Can you cite the Jira issue? There have been a couple IIRC.
Is there anything I can provide that would make it worthwhile to reopen it?
Possibly. There's a deadlock generator script that I used to
java.lang.RuntimeException: javax.net.ssl.SSLHandshakeException: Received
fatal alert: handshake_failure
org.jasig.cas.client.util.CommonUtils.getResponseFromServer(CommonUtils.java:341)
org.jasig.cas.client.util.CommonUtils.getResponseFromServer(CommonUtils.java:305)
Please perform an SSL
I believe this additional step is for anti-phishing. It is for the site to
verify its authenticity to the user, not for the user to verify their
authenticity to the site.
FWIW, that is my understanding as well.
M
--
You are currently subscribed to cas-user@lists.jasig.org as:
I'm a little confused about the authorization, which I read CAS isn't
supposed to do.
CAS doesn't provide any support for centralized authorization policy,
but it can provide data to applications that support
application-specific authorization policy. We use the term attribute
release in the
I don't understand your answer
The answer is nuanced, sorry.
Can Central Authentication Service (CAS) do authorization and use LDAP ?
CAS cannot do centralized authorization. It can support authorization
at each service by providing data from a system of record (e.g. LDAP).
CAS has a number
I would like authorization with LDAP by CAS Server of applications web
(services)
Please read the following section of the CAS 4 user manual:
http://jasig.github.io/cas/4.0.0/integration/Attribute-Release.html
That provides a high-level overview of how CAS participates and
facilitates
What are members of this community currently using, looking into, or
developing for MFA via Duo?
We quickly prototyped two MFA solutions on top of 3.5.2, one for
Google Authenticator and another for YubiKey. Almost all the
customization was at the WebFlow layer. Assuming you approach a
solution
For a high-availability cluster, just follow the instructions here:
http://www.howtoforge.com/how-to-install-repcached-memcached-replication-for-high-availability-over-2-nodes-on-ubuntu-11.04
I attempted to provide a thoughtful explanation in the CAS 4
documentation why memcached replication
SSL/TLS is mandate. Along with that I need to client-side password encryption
also.
I encourage you to reconsider. I realize that may be difficult if the
requirements are dictated by a third party, but it's worth repeating
that this is most likely a bad idea. In particular the key management
How do we enable client side password encryption and then server side
decryption in CAS. Any suggestions/hint will be really helpful.
Can you clarify what you mean by password encryption? Encryption of
credentials used in configuration files (i.e. ldap/database password)?
M
--
You are
I think he refers to the client side (the browser) encrypting the password,
shipping that through to the server, and the server decrypting it.
It's hard to imagine what additional security that would provide in
addition to SSL/TLS transport security that encrypts the entire form
payload
Is it possible to drive the user to a page in order to choose form or
X509 auth instead of trying to force X509 in a very first step?
Yes. We do a variant of this to provide a high-security login form
that posts to an alternate port on submit; the alt port is configured
for optional client SSL.
Can anyone give me one good reason to keep that check box?
I'm pretty sure you've given us a good executive summary for removing it. :)
In any case, while your experience sounds particularly bad, we've had
some headaches supporting extended flows while maintaining proper
function of the warn
Nope, all that does is cause the attributes to have empty values in them:
Ok, I did a little code review and have a suggestion. The trigger to
resolve attributes from a principal resolver is the definition of a
PrincipalResolver component in the value side of
I always get the TARGET parameter in the url until the
user authenticates. How can I remove this TARGET parameter?
TARGET == ticket for the SAML feature in CAS, so it's naturally
present until you authenticate. That's to say you can't and shouldn't
remove it.
M
--
You are currently
I tried dropping back to just a stub attributeRepository bean:
bean id=attributeRepository
class=org.jasig.services.persondir.support.StubPersonAttributeDao
p:backingMap-ref=attrRepoBackingMap /
util:map id=attrRepoBackingMap
entry key=uid value=user /
https://github.com/Jasig/java-cas-client/pull/81
Wrong base branch. Let's try again:
https://github.com/Jasig/java-cas-client/pull/82
M
--
You are currently subscribed to cas-user@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
In short, is there some way to dump the
principal after authentication, or some other way to tell if the
attributes have been properly stored.
PolicyBasedAuthenticationManager logs the resolved principal at DEBUG:
logger.info(Authenticated {} with credentials {}., principal,
MA I built one-off patches [of Java CAS Client 3.2 and 3.1] for my
institution, but we will consider providing official patches for those lines
if there is interest.
I'm happy to provide patches, but I need someone to step up to do the
release process.
M
--
You are currently subscribed to
bean id=x509Handler
class=org.jasig.cas.adaptors.x509.authentication.handler.support.X509CredentialsAuthenticationHandler
property name=trustedIssuerDnPattern value=CN=*/
property name=maxPathLength value=3 /
property name=checkKeyUsage value=false /
Yes, it would ease patching. I'm finding getting a uPortal 4.0 release
squared away jumping from a Java CAS Client 3.2 version to 3.3.2 to be
substantially unpleasant.
Ok. Here's the catch. Some of the integration modules,
cas-client-integration-atlassian comes to mind, have dependencies in
This apparently happens because we don't believe we have access to the
TARGET to validate:
https://github.com/Jasig/cas/blob/master/cas-server-support-saml/src/main/java/org/jasig/cas/support/saml/authentication/principal/SamlService.java#L96
Thanks for investigating. Agree that appears wrong
However, for #2, I have a hard time seeing how the server would allow you to
request a ticket for A and then use it for B.
Both attacks are really the same with different origins. While it's
not appropriate to provide an attack sequence here, I encourage you to
continue thinking about this
the scope of attacks like scenario 1 above.
The following servlet filter may provide additional defense at the CAS
server against some forms of this attack:
https://github.com/Jasig/cas-server-security-filter/tree/cas-server-security-filter-1.0.0
Best,
Marvin Addison
CAS Developer
[1] http
I actually stumbled across similar behavior last week. In my case the CAS
Server issued a ticket for service:
https://mydomain.com/path
And the successfully validated the ticket against service:
http://mydomain.com/path
That's unlikely related to the client security vulnerability. We would
Does this affect ALL versions of the Java client prior to 3.3.2?
I did code review of the latest 3.2 and 3.1 versions and they were
both vulnerable. I built one-off patches for my institution, but we
will consider providing official patches for those lines if there is
interest.
Also, is there
2014-08-11 14:48:53,829 INFO
[org.jasig.cas.CentralAuthenticationServiceImpl] - Granted service ticket
[ST-1-ZVJ45whjWQCXrJQVHVmd-abbott] for service
[https://ckillingsworth2.missouristate.edu/testcasapp] for user [chk790]
Can you post the corresponding log entry that reads something like the
We have our Shibboleth IDP using CAS as the only login handler resulting in
CAS being the manager of the SSO session and Shibboleth being simply a
pasthrough for SAML. Since the Shibboleth IDP does not maintain an SSO
session it should redirect to CAS for each auth request to get a new
I only want the IDP to get a new ST at each auth, which is what is not
happening.
You should provide some evidence to that effect. A browser request
trace would show the important interactions.
I think the key here - pointed out by Tom - is that the CAS client is
maintaining a session
Does anyone know if there are instructions for integrating the password
manager into an existing cas install?
Not sure what you're asking about. CAS 4 ships with support for
password expiration workflows, but has no facilities for password
management. In other words it can help inform the
sory more information about the error :
2014-07-30 14:39:55,547 ERROR
[org.jasig.cas.ticket.registry.MemCacheTicketRegistry] - Failed fetching
TGT-2-HayENMIZIswzmGw3kYaNChMHjpUQPcOjKTmdM6TBh4Tb25qfWz-cas2
java.lang.RuntimeException: Exception waiting for value
You specified the following
but i got connectivity between my cas srv and my memcached serveur .
Good. Turn up logging for the following category to debug:
org.jasig.cas.ticket.registry
Repeat your authentication attempt and post the resulting logs. If you
don't see additional details, there is a problem with your
Ah, the root cause:
Caused by: com.esotericsoftware.kryo.SerializationException: Unable to
deserialize object of type: org.jasig.cas.ticket.TicketGrantingTicketImpl
This may be a bug
Caused by: com.esotericsoftware.kryo.SerializationException: Unable to
deserialize object of type:
I'll look at the documentation again to try and work out the best/simplest
approach.
Can you briefly describe how you store the salt in your database?
There's a quasi-standard for LDAP directories, SSHA, but nothing
equivalent that I'm aware of in the database world. The challenge for
the CAS
Are those doing this generally taking CAS SSO, fronting it with a Shib IdP,
then integrating with ADFS as a relying-party, that SharePoint uses for
authentication ?
We considered this path but aborted. In short, we needed close
collaboration with the Microsoft folks at our institution and
what is the correct way to display the last authentication time to the
user before it is updated in LDAP?
Custom Spring Webflow action that executes after authentication
success. For example, replace sendTicketGrantingTicket action in the
following state with your custom action:
action-state
Has anyone had 2 CAS servers with a load balancer? We are looking for a 24/7
solution and also for our DR plan.
We have been running multiple servers in active-active mode for years
now. I'm also aware of folks using active-failover setups with
specialized LB hardware to do some pretty
My colleague, the ldaptive lead developer, mentioned that the error
string returned from AD looks a little odd:
message=javax.naming.AuthenticationException: [LDAP: error code 49 -
80090308: LdapErr: DSID-0C0903AA, comment: AcceptSecurityContext error, data
775, v1772\00], controls=null]
What
we did apply an update to our F5 load balancer on 6/15, bringing it up to
15.1.
Redirect loops are commonly caused by SSL handshake failures that are
handled poorly in the client. Did a cert change as part of the
upgrade? You'll have more luck troubleshooting the problem at the
client
Thanks for the pointers. The issue is that the PeopleAdmin CAS client
attempts to handshake using SSLv3
Shame on them. TSLv1, which has its own issues, has been recommended
over SSLv3 for several years.
I’m attempting to get them to update their side, but, I’m not holding my
breath on
I’ve beefed up my servlet session timeout to 7200 (... 5 full days).
That amount of beef may lead to coronary problems.
when they submit the login form, the form
just resets and clears the username/password field instead of authenticating
them and redirecting. Thoughts?
The behavior you
I set the web.xml session-timeout to -1 (infinite)...
This morning our CAS instance was down due to an OutOfMemoryException
(OOME)
OOM would be the expected behavior for setting an infinite session
timeout. You have effectively instructed the servlet container to
never reclaim memory for
We are currently looking to host our CAS server off-site Does
anyone have any suggestions for hosting providers?
I encourage you to check out http://www.casinthecloud.com/. I don't
have any experience with the service, but the creator is a trusted
community member.
M
--
You are
I think the
underlying problem in the code is that @Transaction annotations were
placed at the wrong layer, on the methods in class
CentralAuthenticationServiceImpl.
+1
Your analysis and solution are probably the best evidence we have for
that claim. I recall having made a similar suggestion
We put them on CASImpl because technically that is where the transaction
would occur (a single method on that class could call multiple
ticketregistry methods)
Correct, but clearly that approach has some undesirable side effects.
The only registry that would benefit from @Transactional on the
the recommended architecture at
http://jasig.github.io/cas/4.0.0/planning/High-Availability-Guide.html seems
to indicate that session replication is not necessary
That's correct. Unless you have some very strict and ambitious
requirements for your HA solution, session replication is not
I am looking for recommendations from the CAS community on the best
practices you have found for LDAP and MySQL redundancy.
The CAS4 documentation has a thoughtful section on high availability
that should be your starting point:
The stack trace indicates that some Spring AOP proxy is intercepting the
I see that createTicketGrantingTicket() has an @Transactional annotation
applied to
it. Could this be causing the spurious calls to autocommit and commit?
Yes, I think that's it. I would recommend trying to restrict
1. What is the CASTGC cookie? What role does it play when logging in?
2. When is the CASTGC cookie generated?
3. What happens if the CASTGC cookie isn't present when the user signs in?
I believe the following section of the CAS protocol document answers
all the above:
1) I have 2 authentication handlers that are used concurrently, one which
uses a DB query and the other a LDAP query...
Is this an appropriate use of the postAuthenticate
method, or am I twisting this extensibility point in a way it isn’t
intended?
Sounds like a creative use though I
I tried to use a PrincipalResolver originally, but it seemed inefficient.
Not the first time someone has made that argument.
ldap.authn.searchFilter=(|(sAMAccountName={user})(proxyAddresses=smtp:{user}))
so I can't make too many assumptions based on their credentials. This means
I would
So when I got the point of 'enriching' the principal with some
additional metadata I was surprised to see that that resolver got the
same credentials as the authentication handler.
That's the contract: given an authenticated credential, determine a principal.
I have to re-run the code that I
So, all our ticketRegistry.xml has in it is below. Should we just comment
out everything under !-- Quartz --?
Yes, upon setting up an external job to clean up orphaned tickets in a
more efficient manner.
M
--
You are currently subscribed to cas-user@lists.jasig.org as:
2014-04-17 19:51:52,279 ERROR [org.hibernate.util.JDBCExceptionReporter] -
DB2 SQL Error: SQLCODE=-911, SQLSTATE=40001, SQLERRMC=68, DRIVER=3.50.152
2014-04-17 19:51:52,279 ERROR
[org.hibernate.event.def.AbstractFlushingEventListener] - Could not
synchronize database state with
Message-
From: Marvin Addison [mailto:marvin.addi...@gmail.com]
Sent: Tuesday, April 22, 2014 9:09 AM
To: cas-user@lists.jasig.org
Subject: Re: [cas-user] TGT table not getting cleaned up
2014-04-17 19:51:52,279 ERROR
[org.hibernate.util.JDBCExceptionReporter] - DB2 SQL Error:
SQLCODE
How would I go about removing the Java/Quartz job?
Please review the first Spring configuration example on the following page:
https://wiki.jasig.org/display/CASUM/JpaTicketRegistry
The comments in the sample are fairly detailed and the cleaner job is
fairly obvious.
M
--
You are currently
DELETE
FROM TICKETGRANTINGTICKET
WHERE ID=?
The ticket cleanup task is known to be poorly optimized. Note that
it's issuing a per-ticket delete _after_ loading all tickets into
memory. That's likely unworkable for the number of tickets you
mentioned (4M).
If you're having trouble simply
1 - 100 of 1565 matches
Mail list logo
