We have a java application that has multiple threads and that connects to an active directory application to read the data. But most of time, some thread (not all) fails with exception:
"javax.naming.OperationNotSupportedException: [LDAP: error code 12 - 00000057: LdapErr: DSID-0C090753, comment: Error processing control, data 0, v1db1 ];" when getting next page of result (pagesize = 1000)
I googled and found that we should use only one context through the search. We have done the same thing, we are using the same context to get next page, but failing with the exception. Our domain controller is windows server 2008 r2. Is it related to domain controller or are we missing something here?
I got the solution as we are passing control for sorting of data on attribute CN. The sorting control while searching on DC is not supported once we disabled sorting it worked.
Related
So I am trying out a simple full stack project of my own that involves a java backend implementation of a REST API, for which I am using the org.restlet.com framework/package and jetty as the server.
Whilst I was testing my API using Postman I noticed something wierd: Every time I started the server only the first POST/PUT/DELETE HTTP Request would get an answer, while the next ones would not receive one and on the console this error message would appear:
/* Timestamp-not-important */ org.restlet.engine.adapter.ServerAdapter commit
INFO: The connection was broken. It was probably closed by the client.
Reason: Closed
The GET HTTP Requests however do not share that problem.
I said "Fair enough, probably it's postman's fault".. after all the request made it to the server and their effects were applied. However, now that I am building the front-end this problem blocks the server's response: instead of a JSON object I get an undefined (edit: actually I get 204 No Content) on the front-end and the same "INFO" on the back-end for every POST/PUT/DELETE after the first one.
I have no idea what it is or what I am doing wrong. It has to be the backend's problem, right? But what should I look for?
Nevermind, it was the stupidest thing ever. I tried to be "smart" about returning the same Representation object (with only a 'success' JSON field) on multiple occasions by making one instance on a static final field of a class. Turns out a new instance must be returned each time.
Yesterday, I created a topic and a queue on my OpenJMS server, graphically (using admin.sh). I was able to start it with openjms/bin/admin.sh and then clicking on the menus "Start OpenJMS server>Start connections, etc." and even by executing only openjms/bin/startupt.sh (instead of admin.sh).
Today, I deleted all the topic and queue (graphically, by right-cliking on "Delete" on each node Topic and Queue ).
And now, when I type openjms/bin/startup.sh, it displays this exception : http://pastebin.com/PY2wpBkv
Do you know why and how to solve this problem ?
NB : the graphical tool (so admin.sh) still works well.
In fact one must use the classes from package org.exolab.jms.administration (and not use javax.jms.Session's create<Queue||Topic> methods). Read this page : http://openjms.sourceforge.net/usersguide/admin.html
I'm using Weblogic 10.3.5. I work on a large legacy enterprise application with Struts (1.x) mapped as the default servlet.
Background
A bit of legacy convolution to start: each enterprise customer has a "subscriber ID" which their users must provide at login in addition to their username and password. Subscriber IDs are numeric and always at least four digits, usually five. If you go to mysite.com/, you are presented with a three-field login page: subscriber ID, username, and password.
Our largest enterprise customers didn't like that, so many years ago we introduced skinned login pages: go to mysite.com/12345, where 12345 is your subscriber ID. We'll prepopulate and hide the subscriber ID field, and skin the login page with the enterprise customer's logo and color scheme.
Years later, we had 100+ servlet mappings, one for each subscriber. Every new customer required a software deployment to add the servlet mapping, so our implementations team was hamstrung by the dev team's deployment schedule, which in turn was limited by our large enterprise customers' need to budget time for user acceptance testing.
To address that, we changed the URL: mysite.com/login/12345, where /login/* is mapped to a single servlet that accepts any subscriber ID. We kept the old servlet mappings around so that existing customers didn't have to change the URL, but that left two annoyances:
A few hundred lines of cruft in web.xml
As a developer or QA, it's annoying to have to know whether this is an old subscriber or a new one before you know what URL to use to log in. Try to use the old method for a new subscriber? You get a 404 page.
Here's what I did
We had a pre-existing custom 404 page, correctly defined in web.xml and behaving exactly as expected. I updated it with the following code, right at the top:
<%
if (request.getRequestURI().matches("^/[\\d]{4,}$")) {
// probably someone trying to log in with the old-style URL
response.sendRedirect(String.format("/login%s", request.getRequestURI()));
return;
}
%>
This worked like a charm, until I noticed one oddity:
Here's what's wrong
The very first time I try to visit a URL that should result in a 404 but will be redirected because it matches the regex, it doesn't redirect. With my debugger, I've determined that the reason is that request.getRequestURI() returns "/errors/404error.jsp" rather than "/12345" like I would expect, resulting in the regex not matching and our normal 404 page being served to the user.
My first thought was that something was telling the browser to redirect to the 404 page, but Chrome Dev Tools "Network" tab indicates that is not the case.
After it fails that first time, my change works every subsequent time until the application server restarts.
If I hit /login/12345 first it loads fine. Any subsequent attempt to hit /12345 will work fine, so it seems like it might have something to do with the login servlet not being fully initialized until after the first request. Weblogic is closed source, so I'm not able to dig into what's happening.
Here's my question
I know it's a pretty weird thing I'm doing; I'm open to other approaches. But the question is this: what's causing the different request URI on the first attempt, and how do I fix it? I've scoured the HttpServletRequest object in the debugger and I don't see any indication of the real request URI.
Ok so I'm making a "simple" web app using the technologies from the topic, recently I found http://www.adobe.com/devnet/flex/articles/flex_hibernate.html so I'm following it and I try to apply it to my app, the only difference being I'm working on a Mac and I'm using MAMP for the database (so no command line for me).
The thing is I'm having some trouble with retrieving/connecting to the database.
I have the remoting-config.xml, persistance.xml, a News.java class (my Entity), a NewsService.java class, a News.as class - all just like in the tutorial. I have of course this line in one of my .mxmls:
<mx:RemoteObject id="loaderService" destination="newsService" result="handleLoadResult(event)" fault="handleFault(event)" showBusyCursor="true" />
And my remoting-config.xml looks like this (well part of it):
<destination id="newsService">
<properties><source>com.gamelist.news.NewsService</source></properties>
</destination>
NewsService has a method:
public List<News> getLatestNews() {
EntityManagerFactory emf = Persistence.createEntityManagerFactory(PERSISTENCE_UNIT);
EntityManager em = emf.createEntityManager();
Query findLatestQuery = em.createNamedQuery("news.findLatest");
List<News> news = findLatestQuery.getResultList();
return news;
}
And the named query is in the News class:
#Entity
#Table(name="GLT_NEWS")
#NamedQueries({
#NamedQuery(name="news.findLatest", query="from GLT_NEWS order by new_date_added limit 5 ")
})
The handledLoadResult looks like this:
private function handleLoadResult(ev:ResultEvent):void {
newsList = ev.result as ArrayCollection;
newsRecords = newsList.length;
}
Where:
[Bindable]
private var newsList:ArrayCollection = new ArrayCollection();
But when I try to trigger:
loaderService.getLatestNews();
nothing happens, newsList is empty.
Few things I need to point out:
1) as I said I didn't install mysql manually, but I'm using MAMP (yes, the server's running), could this cause some trouble?
2) I already have a "gladm" database and I have a "GLT_NEWS" table with all the fields, is this bad?
Basically the question is how am I suppose to debug this thing so I can find the mistake I'm making? I know that loadData() is executed (did a trace()), but I have no idea what happens with loaderService.getLatestNews()...
#EDIT: ok so I see I'm getting an error in the "fault handler" which says
"Error: Client.Error.MessageSend - Channel.Connect.Failed error NetConnection.Call.Failed: HTTP: Status 404: url: 'http://localhost:8080/WebContent/messagebroker/amf' - "
#EDIT2: Ok i solved the problem, as it turns out my ContextRoot was incorrect, the funny thing is I couldn't edit it by going to Project properties->Flex Server as it was uneditable! I had to find the .flexProject file and edit it (obviously my Flex Navigator didn't show it and by accident I noticed it was being filtered).
To answer your question as to, in general, debug this monster...here is what I do.
Set break points in my Java code
Start up the Java application server with the appropriate debug JVM properties set (e.g. -Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n)
From Eclipse, I attach a remote debugger to the app server on the default port 8000. The Java Debugger will open up when a break point is hit.
Set breakpoints in my Flex application (or one of its modules).
From Eclipse (with Flash Builder) I launch a debug configuration for my Flex app. The Flex Debugger will open up when a break point is hit.
At this point I have two debuggers open and everything work great. Two other things I do:
a) extend the transaction system timeout, so it doesn't get trigger while I am sitting there think for a few minutes
b) use Charles Proxy (in reverse proxy mode) inbetween the client and server to watch the AMF traffic and view payloads, etc.
Hope this helps.
your error means you are not calling the server on the right way. Something is wrong there, the url the web.config file or other BlazeDS config files.
We are converting large PDF file using Adobe LiveCycle ConvertPDF service.
This works fine for smaller PDF files, but fails when we attempt to convert a large PDF file (around 150mb - don't ask).
It looks like Adobe sets the a transaction timeout around 14(?) minutes. As processing time for our huge PDF exceeds this time, operation is aborted.
We tried multiple PDFs, so this is not likely to be caused by corrupted input file.
Here's the output that exception produces:
com.adobe.livecycle.convertpdfservice.exception.ConvertPdfException: ALC-DSC-000-000: com.adobe.idp.dsc.DSCException: Internal error.
at com.adobe.convertpdf.docservice.ConvertPdfServiceImpl.toPS2WithSMT(ConvertPdfServiceImpl.java:117)
at com.adobe.convertpdf.docservice.ConvertPdfServiceImpl.toPS2(ConvertPdfServiceImpl.java:93)
[...]
Caused by: ALC-DSC-000-000: com.adobe.idp.dsc.DSCException: Internal error.
at com.adobe.convertpdf.docservice.ConvertPdfServiceImpl$1.doInTransaction(ConvertPdfServiceImpl.java:110)
at com.adobe.idp.dsc.transaction.impl.ejb.adapter.EjbTransactionBMTAdapterBean.doRequiresNew(EjbTransactionBMTAdapterBean.java:218)
[...]
Caused by: com.adobe.livecycle.convertpdfservice.exception.ConvertPdfException: Cannot convert PDF file to PostScript.
Exception: "Transaction timed out: Couldn't connect to Datamanager Service"
at com.adobe.convertpdf.ConvertPdfBmcWrapper.convertPdftoPs(ConvertPdfBmcWrapper.java:207)
at com.adobe.convertpdf.ConvertPdfServer.convertPdftoPs(ConvertPdfServer.java:121)
at com.adobe.convertpdf.docservice.ConvertPdfServiceImpl.toPS2InTxn(ConvertPdfServiceImpl.java:129)
[...]
So far - seems logical.
However, I can't find where the transaction length is configured. I guess if we increased the timeout to something like 30 minutes, our problem would go away.
(Also the problem would go away if we had way of invoking this operation without any transactions...)
Let's say we are simply running it like this:
ServiceClientFactory factory = com.adobe.idp.dsc.clientsdk.ServiceClientFactory.createInstance(connectionProps);
ConvertPdfServiceClient convertPDFClient = new com.adobe.livecycle.convertpdfservice.client.ConvertPdfServiceClient(factory);
// ... set-up details skipped ...
com.adobe.idp.Document result_postscript = convertPDFClient.toPS2(inPdf,options);
result_postscript.copyToFile(new File("c:/Adobe/output.ps"))
However, either we are not setting up ServiceClientFactory correctly, or maybe not reading JBoss config properly, we can't find way to make the transaction live longer. (Is the transaction time to live really the issue?)
In LiveCycle Administration Console simply go to
Home > Services > Applications and Services > Service Management > ConvertPdfService
The service timeout can be changed there.
When testing with converting pdf (generated by iText) that contains 39k pages (13 initial, each cloned 3000 times, size ~15Mb) -final output PostScript file was ~1,25Gb. Whole work took about 2 hours. But it worked, no problems.
(I guess this answer makes the question not-programming related, but hey.)