Hi Ilya,
The patch has been applied to the night build 3.6.519, the data has been
migrated with se_exp using complete export-import. The issue has not appear
again for a week already. I'll keep monitoring Sedna.
However, it seems there is another issue with that night build:
LOG 27/10/2014
Ilya,
As far as I remember. It is almost the latest dev sources built with
relWithDebInfo. Internal data structures should be compatible.
Ivan
On Wed, Oct 15, 2014 at 2:08 AM, Ilya Taranov epsi...@socio.msu.ru wrote:
I'm not sure, latest build will fix the problem.
It's definitely some
I'm not sure, latest build will fix the problem.
It's definitely some client-to-app communication problem.
If I make a git patch for you with additional debug info, will you be able
to apply it (assuming, the data file version will be the same)? What build
do you currently use?
On Sat, Oct 11,
Hi Ilya,
I've analyzed logs for other issue occurrences and it has appeared more
complicated.
First, could you please clarify about Session is ready statement, when
exactly is it dumped to the log file? I'm wondering because when the
database is hanging, those log entries still appear at some
Sorry, copied the wrong link for the connection pool documentation. Here is
the correct one:
http://www.cfoster.net/pdf/sedna/xmldb/documentation.pdf#page=10
Besides, I use the following values for the connection pool parameters in
the suspected application:
conn-max-active=50
conn-max-wait=3
Hi, from the top of my head...
1. Queries are evaluated in a lazy fashion. Which means, that before client
asks to fetch the next row, nothing is evaluated.
So select() is a socket read, which is waiting for client to make a
decision on whether to commit (or end RO transaction) or ask for next
Hi Ilya,
Your suggestion seems to be correct. After I've restarted three Java
applications that had connections to Sedna, the database has resumed
processing operations. Here is the event.log where Sedna has hanged between
12:35:03 and 13:06:05:
